Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8262 I. Sedlacek
Updates: 5368, 5621, 6442 Ericsson
Category: Standards Track October 2017
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8262 I. Sedlacek
Updates: 5368, 5621, 6442 Ericsson
Category: Standards Track October 2017
ISSN: 2070-1721
Content-ID Header Field in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中的内容ID标头字段
Abstract
摘要
This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). This document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields.
本文档指定在会话启动协议（SIP）中使用的内容ID头字段。本文档还更新了RFC 5621，它只允许内容ID URL引用作为多部分消息正文一部分的正文部分。此更新使内容ID URL能够引用一些附加SIP头字段提供的完整消息体和元数据。
This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field.
本文档通过澄清RFC 5368和RFC 6442对SIP内容ID头字段的使用，更新了RFC 5368和RFC 6442。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8262.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8262.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Identifying a Body Part . . . . . . . . . . . . . . . . . 3
1.2. Referencing a Body Part . . . . . . . . . . . . . . . . . 3
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1. Example 1: SIP INVITE . . . . . . . . . . . . . . . . 4
1.4.2. Example 2: SIP REFER . . . . . . . . . . . . . . . . 6
1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. Backward Compatibility . . . . . . . . . . . . . . . . . 7
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Content-ID Header Field . . . . . . . . . . . . . . . . . . . 8
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. User Agent (UA) Procedures . . . . . . . . . . . . . 9
3.4.2. Proxy Procedures . . . . . . . . . . . . . . . . . . 9
3.4.3. Example: Referencing the Message-Body of a SIP
Message . . . . . . . . . . . . . . . . . . . . . . . 9
4. Update to RFC 5368 . . . . . . . . . . . . . . . . . . . . . 10
5. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 11
6. Update to RFC 6442 . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Identifying a Body Part . . . . . . . . . . . . . . . . . 3
1.2. Referencing a Body Part . . . . . . . . . . . . . . . . . 3
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1. Example 1: SIP INVITE . . . . . . . . . . . . . . . . 4
1.4.2. Example 2: SIP REFER . . . . . . . . . . . . . . . . 6
1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. Backward Compatibility . . . . . . . . . . . . . . . . . 7
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Content-ID Header Field . . . . . . . . . . . . . . . . . . . 8
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. User Agent (UA) Procedures . . . . . . . . . . . . . 9
3.4.2. Proxy Procedures . . . . . . . . . . . . . . . . . . 9
3.4.3. Example: Referencing the Message-Body of a SIP
Message . . . . . . . . . . . . . . . . . . . . . . . 9
4. Update to RFC 5368 . . . . . . . . . . . . . . . . . . . . . 10
5. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 11
6. Update to RFC 6442 . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
A SIP message consists of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body as specified in [RFC3261].
SIP消息由起始行、一个或多个标头字段、指示标头字段结尾的空行以及[RFC3261]中指定的可选消息正文组成。
The message-body can be a non-multipart message-body or a multipart message-body as specified in [RFC3261].
消息正文可以是非多部分消息正文，也可以是[RFC3261]中指定的多部分消息正文。
[RFC5621] defines generic handling of a multipart message-body in a SIP message.
[RFC5621]定义SIP消息中多部分消息正文的通用处理。
A multipart message-body contains zero, one, or several body parts encoded using the format define in [RFC2045].
多部分消息正文包含零个、一个或多个正文部分，这些正文部分使用[RFC2045]中定义的格式进行编码。
A body part in the multipart message-body is described using header fields such as Content-Disposition, Content-Encoding, and Content-Type, which provide information on the content of the body part as specified in [RFC5621]. A body part in the multipart message-body can also contain a Content-ID header field with an ID value uniquely identifying the body part as specified in [RFC2045].
多部分消息正文中的正文部分使用标题字段（如内容配置、内容编码和内容类型）进行描述，这些字段提供[RFC5621]中规定的正文部分内容的信息。多部分消息正文中的正文部分还可以包含一个内容ID头字段，该字段具有唯一标识正文部分的ID值，如[RFC2045]中所述。
A SIP header field can reference a body part using a Content-ID URL as specified in [RFC5621].
SIP头字段可以使用[RFC5621]中指定的内容ID URL引用主体部分。
The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies how to identify the body part referenced by a Content-ID URL. The Content-ID URL value is included in the Content-ID header field of the body part.
[RFC2392]中指定了内容ID URL。[RFC2392]指定如何识别由内容ID URL引用的主体部分。内容ID URL值包含在主体部分的内容ID标头字段中。
Examples of SIP header fields referencing a body part using a Content-ID URL are:
使用内容ID URL引用主体部分的SIP头字段示例如下：
o [RFC6442] specifies how a Geolocation header field references a body part using a Content-ID URL for providing location information.
o [RFC6442]指定地理位置标头字段如何使用内容ID URL引用主体部分以提供位置信息。
o [RFC5368] specifies how a Refer-To header field references a body part using a Content-ID URL to provide a list of targets.
o [RFC5368]指定引用头字段如何使用内容ID URL引用主体部分以提供目标列表。
How to uniquely identify a complete message-body of a SIP message using a Content-ID header field and how to reference a complete message-body using a Content-ID URL are not currently specified.
目前尚未指定如何使用内容ID头字段唯一标识SIP消息的完整消息体，以及如何使用内容ID URL引用完整消息体。
Note: In [RFC5621], the Content-ID URL references a specific body part only.
注意：在[RFC5621]中，内容ID URL仅引用特定的主体部分。
Some existing specifications, such as [RFC5368], contain examples that show usage of a SIP Content-ID header field referencing a complete message-body, even though such usage has never been specified. Many implementors have interpreted these examples to indicate that such usage is allowed by the corresponding specification, despite the absence of language allowing it. This document updates the normative language in the affected documents to explicitly allow such usage.
一些现有规范（如[RFC5368]）包含一些示例，这些示例显示了引用完整消息正文的SIP内容ID头字段的用法，即使从未指定过此类用法。许多实现者对这些示例进行了解释，以表明相应的规范允许这种用法，尽管没有允许这种用法的语言。本文件更新了受影响文件中的规范性语言，以明确允许此类使用。
The examples below show the consequences of the problem described above.
下面的示例显示了上述问题的后果。
If a User Agent Client (UAC) sends an INVITE request that conveys location by value (as specified in [RFC6442]) and decides not to include a Session Description Protocol (SDP) offer, then the UAC needs to include only one MIME entity in the INVITE request. This MIME entity can be, for example, of the 'application/pidf+xml' MIME type.
如果用户代理客户端（UAC）发送一个INVITE请求，该请求通过值传递位置（如[RFC6442]中所述），并决定不包含会话描述协议（SDP）提供，则UAC只需要在INVITE请求中包含一个MIME实体。例如，此MIME实体可以是“application/pidf+xml”MIME类型。
However, due to [RFC6442] requiring inclusion of a Geolocation header field referencing the body part with the location information, the UAC includes a multipart message-body with a single body part in the INVITE request, and includes the location information of 'application/pidf+xml' MIME type and an associated Content-ID header field in the body part.
但是，由于[RFC6442]需要包含一个地理位置标头字段，该字段引用带有位置信息的正文部分，UAC在INVITE请求中包含一个带有单个正文部分的多部分消息正文，并包括“application/pidf+xml”MIME类型的位置信息和正文部分中的关联内容ID头字段。
Example message (SIP INVITE):
示例消息（SIP INVITE）：
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: <cid:target123@atlanta.example.com> Geolocation-Routing: no Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: <sips:alice@atlanta.example.com> Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...
邀请SIP：bob@biloxi.example.comSIP/2.0 Via:SIPS/2.0/TLS pc33.atlanta.example.com；分支=z9hG4bK74bf9最大转发：70到：Bob<sips:bob@biloxi.example.com>发件人：Alice<sips:alice@atlanta.example.com>;tag=9fxced76sl呼叫ID:3848276298220188511@atlanta.example.com地理位置：<cid:target123@atlanta.example.com>地理定位路由：不接受：应用程序/sdp，应用程序/pidf+xml CSeq:31862邀请联系人：<sips:alice@atlanta.example.com>内容类型：多部分/混合；边界=边界1内容长度：。。。
--boundary1
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
--boundary1
Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com"
>
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>no
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com"
>
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>no
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
--boundary1--
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
--boundary1--
If a UAC sends a REFER request including a list of targets as specified in [RFC5368], then the UAC needs to include only one MIME entity in the REFER request. This MIME entity is of the 'application/resource-lists+xml' MIME type.
如果UAC发送包含[RFC5368]中指定的目标列表的REFER请求，则UAC只需要在REFER请求中包含一个MIME实体。此MIME实体属于“应用程序/资源列表+xml”MIME类型。
However, due to [RFC5368] requiring inclusion of a Refer-To header field referencing the body part containing the list of targets, the UAC includes a multipart message-body with a single body part in the REFER request and includes the list of targets of 'application/ resource-lists+xml' MIME type and an associated Content-ID header field in the body part.
但是，由于[RFC5368]需要包含引用包含目标列表的主体部分的引用标头字段，UAC在REFER请求中包含一个包含单个正文部分的多部分消息正文，并在正文部分包含“应用程序/资源列表+xml”MIME类型的目标列表和相关的内容ID头字段。
Example message (SIP REFER):
示例消息（请参阅SIP）：
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 Via: SIP/2.0/TCP client.chicago.example.com;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: "Conference 123" <sip:conf-123@example.com> From: Carol <sip:carol@chicago.example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 2 REFER Contact: <sip:carol@client.chicago.example.com> Refer-To: <cid:cn35t8jf02@example.com> Refer-Sub: false Require: multiple-refer, norefersub Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...
参考sip:conf-123@example.com;格鲁；不透明=hha9s8d-999a SIP/2.0，通过：SIP/2.0/TCP client.chicago.example.com；branch=Z9HG4BKKHJHS8ASS83最大转发：70至：“会议123”<sip:conf-123@example.com>发件人：卡罗尔carol@chicago.example.com>;tag=32331呼叫ID:d432fa84b4c76e66710 CSeq:2参考联系人：<sip:carol@client.chicago.example.com>请参阅：<cid:cn35t8jf02@example.com>Refer Sub:false Require:multiple Refer，norefersub Allow:INVITE，ACK，CANCEL，OPTIONS，BYE，Refer，SUBSCRIBE，NOTIFY Allow Events:dialog Accept:application/sdp，消息/sipfrag内容类型：多部分/混合；边界=边界1内容长度：。。。
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-ID: <cn35t8jf02@example.com>
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-ID: <cn35t8jf02@example.com>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists
xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
<list>
<entry uri="sip:bill@example.com?method=BYE"/>
<entry uri="sip:joe@example.org?method=BYE"/>
<entry uri="sip:ted@example.net?method=BYE"/>
</list>
</resource-lists>
--boundary1--
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists
xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
<list>
<entry uri="sip:bill@example.com?method=BYE"/>
<entry uri="sip:joe@example.org?method=BYE"/>
<entry uri="sip:ted@example.net?method=BYE"/>
</list>
</resource-lists>
--boundary1--
In order to solve the problems described above, this document:
为了解决上述问题，本文件：
o Specifies and registers the Content-ID header field as a SIP header field.
o 指定内容ID标头字段并将其注册为SIP标头字段。
o Specifies that, when used as a SIP header field, the Content-ID header field identifies the complete message-body and the metadata provided by some additional SIP header fields of the SIP message.
o 指定当用作SIP头字段时，内容ID头字段标识SIP消息的一些附加SIP头字段提供的完整消息正文和元数据。
o Updates [RFC5621] to enable a Content-ID URL to reference a complete message-body and the metadata provided by some additional SIP header fields.
o 更新[RFC5621]，使内容ID URL能够引用完整的消息正文和一些附加SIP头字段提供的元数据。
o Updates [RFC5368] and [RFC6442] by adding text that explicitly states that a SIP Content-ID header field can be used.
o 通过添加明确说明可以使用SIP内容ID头字段的文本来更新[RFC5368]和[RFC6442]。
If an existing specification only defines the usage of a multipart message-body to carry a single body part to be referenced by a Content-ID URL, implementations MUST NOT carry the MIME entity in a non-multipart message-body unless the specification is updated to explicitly allow it.
如果现有规范仅定义多部分消息正文的用法，以承载由内容ID URL引用的单个正文部分，则实现不得在非多部分消息正文中承载MIME实体，除非规范更新为显式允许它。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This section defines the usage of the Content-ID header field for SIP.
本节定义SIP的内容ID头字段的用法。
The ABNF [RFC5234] for the Content-ID header field is:
内容ID头字段的ABNF[RFC5234]为：
Content-ID = "Content-ID" HCOLON msg-id
Content ID=“Content ID”HCOLON msg ID
msg-id = "<" id-left "@" id-right ">"
msg-id = "<" id-left "@" id-right ">"
Note: id-left and id-right are specified in [RFC5322]. HCOLON is defined in [RFC3261].
注：左id和右id在[RFC5322]中指定。[RFC3261]中定义了HCOLON。
Note: When used in a SIP header field, the msg-id syntax has been simplified, compared to the syntax in [RFC5322], to disallow the use of comments and to adopt to the SIP usage of leading white space.
注意：与[RFC5322]中的语法相比，当在SIP头字段中使用时，msg id语法已被简化，以禁止使用注释，并适应SIP对前导空格的使用。
The value of the Content-ID header field value must be unique in the context of a given SIP message, including any embedded MIME Content-ID header field values. Note that the SIP Content-ID header field value is not expected to be unique among all SIP messages; it has no meaning outside of the message in which it is included.
内容ID头字段值的值在给定SIP消息的上下文中必须是唯一的，包括任何嵌入的MIME内容ID头字段值。注意，SIP内容ID头字段值在所有SIP消息中不应是唯一的；它在包含它的消息之外没有任何意义。
The Content-ID header field included in the header fields of a SIP message identifies the message-body of the SIP message and the metadata provided by:
SIP消息的报头字段中包括的内容ID报头字段标识SIP消息的消息体和以下提供的元数据：
o A MIME-Version header field, if included in the header fields of the SIP message.
o MIME版本标头字段（如果包含在SIP消息的标头字段中）。
o Any 'Content-' prefixed header fields (including the Content-ID header field itself) included in the header fields of the SIP message.
o SIP消息的头字段中包含的任何带有“Content-”前缀的头字段（包括内容ID头字段本身）。
The Content-ID header field can be included in any SIP message that is allowed to contain a message-body.
内容ID头字段可以包含在允许包含消息正文的任何SIP消息中。
Note: The message-body identified by the Content-ID header field can be a non-multipart message-body or a multipart message-body.
注意：由Content ID header字段标识的消息正文可以是非多部分消息正文或多部分消息正文。
A UA MAY include a Content-ID header field in any SIP message that is allowed to contain a message-body.
UA可以在允许包含消息体的任何SIP消息中包括内容ID报头字段。
A UA MUST NOT include a Content-ID header field in any SIP message that is not allowed to contain a message-body.
UA不得在任何不允许包含消息正文的SIP消息中包含内容ID头字段。
A UA MUST set the value of the Content-ID header field to a value that is unique in the context of the SIP message.
UA必须将内容ID头字段的值设置为SIP消息上下文中唯一的值。
A proxy MUST NOT add a Content-ID header field in a SIP message.
代理不得在SIP消息中添加内容ID头字段。
A proxy MUST NOT modify a Content-ID header field included in a SIP message.
代理不得修改SIP消息中包含的内容ID头字段。
A proxy MUST NOT delete a Content-ID header field from a SIP message.
代理不能从SIP消息中删除内容ID头字段。
The figure shows an example from [RFC5368], where the SIP Content-ID header field is used to reference the message-body (non-multipart) of a SIP message.
该图显示了[RFC5368]中的一个示例，其中SIP内容ID头字段用于引用SIP消息的消息体（非多部分）。
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conference 123" <sip:conf-123@example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 2 REFER
Contact: <sip:carol@client.chicago.example.com>
Refer-To: <cid:cn35t8jf02@example.com>
Refer-Sub: false
Require: multiple-refer, norefersub
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-Length: 362
Content-ID: <cn35t8jf02@example.com>
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conference 123" <sip:conf-123@example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 2 REFER
Contact: <sip:carol@client.chicago.example.com>
Refer-To: <cid:cn35t8jf02@example.com>
Refer-Sub: false
Require: multiple-refer, norefersub
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-Length: 362
Content-ID: <cn35t8jf02@example.com>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com?method=BYE" />
<entry uri="sip:joe@example.org?method=BYE" />
<entry uri="sip:ted@example.net?method=BYE" />
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com?method=BYE" />
<entry uri="sip:joe@example.org?method=BYE" />
<entry uri="sip:ted@example.net?method=BYE" />
</list>
</resource-lists>
This section updates the second paragraph in Section 7 of [RFC5368] by allowing usage of either a MIME Content-ID header field or a SIP Content-ID header field to label the body part or the message-body carrying the URI list.
本节更新了[RFC5368]第7节中的第二段，允许使用MIME内容ID头字段或SIP内容ID头字段来标记主体部分或带有URI列表的消息主体。
OLD TEXT:
旧文本：
The Refer-To header field of a REFER request with multiple REFER-Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part that carries the URI list. The REFER-Issuer SHOULD NOT include any particular URI more than once in the URI list.
具有多个引用目标的引用请求的引用头字段必须包含指向承载URI列表的主体部分的指针（即，根据RFC 2392[RFC2392]的内容ID统一资源定位器（URL））。引用颁发者不应在URI列表中多次包含任何特定URI。
NEW TEXT:
新案文：
The Refer-To header field of a REFER request with multiple REFER-Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part or message-body that carries the URI list. The REFER-Issuer SHOULD NOT include any particular URI more than once in the URI list. The REFER request can use either a MIME Content-ID header field [RFC4483] or a SIP Content-ID header field [RFC8262] to label the body part or the message-body.
具有多个引用目标的引用请求的引用标头字段必须包含指向承载URI列表的正文部分或消息正文的指针（即，根据RFC 2392[RFC2392]的内容ID统一资源定位器（URL））。引用颁发者不应在URI列表中多次包含任何特定URI。REFER请求可以使用MIME内容ID头字段[RFC4483]或SIP内容ID头字段[RFC8262]来标记正文部分或消息正文。
This section updates Section 9.1 of [RFC5621] by allowing a Content-ID URL to reference a message-body and the related metadata (Section 3.3) in addition to allowing a reference to a body part.
本节更新了[RFC5621]第9.1节，除了允许引用正文部分外，还允许内容ID URL引用消息正文和相关元数据（第3.3节）。
OLD TEXT:
旧文本：
Content-ID URLs allow creating references to body parts. A given Content-ID URL [RFC2392], which can appear in a header field or within a body part (e.g., in an SDP attribute), points to a particular body part.
内容ID URL允许创建对身体部位的引用。给定的内容ID URL[RFC2392]可以出现在标题字段或主体部分（例如，在SDP属性中）中，指向特定的主体部分。
NEW TEXT:
新案文：
Content-ID URLs allow the creation of references to body parts or message-bodies (and the header fields describing the message-bodies). A given Content-ID URL [RFC2392], which can appear in a header field or within a body part (e.g., in an SDP attribute), points to a particular body part or the message-body (and the header fields describing the message-body).
内容ID URL允许创建对正文部分或消息正文（以及描述消息正文的标题字段）的引用。给定的内容ID URL[RFC2392]可以出现在标题字段或正文部分（例如，在SDP属性中）中，指向特定正文部分或消息正文（以及描述消息正文的标题字段）。
This section updates the second paragraph in Section 3.1 of [RFC6442] by allowing usage of either a MIME Content-ID header field or a SIP Content-ID header field to label the body part or the message-body carrying the location data.
本节更新了[RFC6442]第3.1节中的第二段，允许使用MIME内容ID头字段或SIP内容ID头字段来标记正文部分或承载位置数据的消息正文。
OLD TEXT:
旧文本：
In Figure 1, Alice is both the Target and the LS that is conveying her location directly to Bob, who acts as an LR. This conveyance is point-to-point: it does not pass through any SIP-layer intermediary. A Location Object appears by-value in the initial SIP request as a MIME body, and Bob responds to that SIP request as appropriate. There is a 'Bad Location Information' response code introduced within this document to specifically inform Alice if she conveys bad location information to Bob (e.g., Bob "cannot parse the location provided", or "there is not enough location information to determine where Alice is").
在图1中，Alice既是目标，也是将她的位置直接传递给Bob的LS，Bob充当LR。此传输是点对点的：它不通过任何SIP层中介。Location对象在初始SIP请求中按值显示为MIME主体，Bob根据需要响应该SIP请求。本文件中引入了“错误位置信息”响应代码，专门通知Alice是否向Bob传达错误位置信息（例如，Bob“无法解析提供的位置”，或“没有足够的位置信息来确定Alice的位置”）。
NEW TEXT:
新案文：
In Figure 1, Alice is both the Target and the LS that is conveying her location directly to Bob, who acts as an LR. This conveyance is point-to-point: it does not pass through any SIP-layer intermediary. A Location Object appears by-value in the initial SIP request as a MIME body, and Bob responds to that SIP request as appropriate. Either a MIME Content-ID header field [RFC4483] or the SIP Content-ID header field [RFC8262] MUST be used to label the location information. There is a 'Bad Location Information' response code introduced within this document to specifically inform Alice if she conveys bad location information to Bob (e.g., Bob "cannot parse the location provided", or "there is not enough location information to determine where Alice is").
在图1中，Alice既是目标，也是将她的位置直接传递给Bob的LS，Bob充当LR。此传输是点对点的：它不通过任何SIP层中介。Location对象在初始SIP请求中按值显示为MIME主体，Bob根据需要响应该SIP请求。必须使用MIME内容ID头字段[RFC4483]或SIP内容ID头字段[RFC8262]来标记位置信息。本文件中引入了“错误位置信息”响应代码，专门通知Alice是否向Bob传达错误位置信息（例如，Bob“无法解析提供的位置”，或“没有足够的位置信息来确定Alice的位置”）。
The Content-ID header field value MUST NOT reveal sensitive user information.
内容ID标题字段值不得显示敏感用户信息。
If the message-body associated with the Content-ID header field is an encrypted body, it MUST NOT be possible to derive a key that can be used to decrypt the body from the Content-ID header field value.
如果与内容ID标头字段关联的消息正文是加密正文，则不能派生可用于从内容ID标头字段值解密正文的密钥。
This specification registers a new SIP header field according to the procedures defined in [RFC3261].
本规范根据[RFC3261]中定义的程序注册一个新的SIP头字段。
The header field described in Section 3 has been registered in the "Header Fields" sub-registry of the "Session Initiation Protocol (SIP) Parameters" registry by adding a row with these values:
通过添加具有以下值的行，第3节中描述的标题字段已在“会话启动协议（SIP）参数”注册表的“标题字段”子注册表中注册：
Header Name: Content-ID
标题名称：内容ID
compact:
契约：
Reference: RFC 8262
参考：RFC 8262
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
[RFC2045]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 2045，DOI 10.17487/RFC20451996年11月<https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, <https://www.rfc-editor.org/info/rfc2392>.
[RFC2392]Levinson，E.，“内容ID和消息ID统一资源定位器”，RFC 2392，DOI 10.17487/RFC2392，1998年8月<https://www.rfc-editor.org/info/rfc2392>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, DOI 10.17487/RFC4483, May 2006, <https://www.rfc-editor.org/info/rfc4483>.
[RFC4483]Burger，E.，Ed.“会话初始化协议（SIP）消息中的内容间接寻址机制”，RFC 4483，DOI 10.17487/RFC4483，2006年5月<https://www.rfc-editor.org/info/rfc4483>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<https://www.rfc-editor.org/info/rfc5322>.
[RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, DOI 10.17487/RFC5621, September 2009, <https://www.rfc-editor.org/info/rfc5621>.
[RFC5621]Camarillo，G.“会话启动协议（SIP）中的消息体处理”，RFC 5621，DOI 10.17487/RFC5621，2009年9月<https://www.rfc-editor.org/info/rfc5621>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., and H. Khartabil, "Referring to Multiple Resources in the Session Initiation Protocol (SIP)", RFC 5368, DOI 10.17487/RFC5368, October 2008, <https://www.rfc-editor.org/info/rfc5368>.
[RFC5368]Camarillo，G.，Niemi，A.，Isomaki，M.，Garcia Martin，M.，和H.Khartabil，“会话启动协议（SIP）中的多资源引用”，RFC 5368，DOI 10.17487/RFC5368，2008年10月<https://www.rfc-editor.org/info/rfc5368>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, DOI 10.17487/RFC6442, December 2011, <https://www.rfc-editor.org/info/rfc6442>.
[RFC6442]Polk，J.，Rosen，B.，和J.Peterson，“会话启动协议的位置传输”，RFC 6442，DOI 10.17487/RFC6442，2011年12月<https://www.rfc-editor.org/info/rfc6442>.
Authors' Addresses
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
Email: christer.holmberg@ericsson.com
Email: christer.holmberg@ericsson.com
Ivo Sedlacek Ericsson Sokolovska 79 Praha 18600 Czech Republic
Ivo Sedlacek Ericsson Sokolovska 79普拉哈18600捷克共和国
Email: ivo.sedlacek@ericsson.com
Email: ivo.sedlacek@ericsson.com