[要約] RFC 8262は、SIPで使用されるContent-IDヘッダーフィールドに関する仕様です。このRFCの目的は、SIPメッセージ内のコンテンツを一意に識別するためのContent-IDヘッダーフィールドの使用方法を定義することです。
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）のContent-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.
このドキュメントでは、Session Initiation Protocol（SIP）で使用するContent-IDヘッダーフィールドを指定します。このドキュメントはRFC 5621も更新します。これにより、Content-ID URLがマルチパートメッセージ本文の一部である本文部分を参照することのみが許可されます。この更新により、Content-ID URLは、いくつかの追加のSIPヘッダーフィールドによって提供される完全なメッセージ本文とメタデータを参照できます。
This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field.
このドキュメントでは、SIP Content-IDヘッダーフィールドの使用方法を明確にすることにより、RFC 5368およびRFC 6442を更新しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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メッセージは、開始行、1つ以上のヘッダーフィールド、ヘッダーフィールドの終わりを示す空の行、および[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]で定義されている形式を使用してエンコードされたゼロ、1つ、またはいくつかの本文部分が含まれます。
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]で指定されている本文部分のコンテンツに関する情報を提供するContent-Disposition、Content-Encoding、Content-Typeなどのヘッダーフィールドを使用して記述されます。マルチパートメッセージ本文の本文部分には、[RFC2045]で指定されているように、本文部分を一意に識別するID値を持つContent-IDヘッダーフィールドを含めることもできます。
A SIP header field can reference a body part using a Content-ID URL as specified in [RFC5621].
SIPヘッダーフィールドは、[RFC5621]で指定されているContent-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.
Content-ID URLは[RFC2392]で指定されています。 [RFC2392]は、Content-ID URLによって参照されるボディパーツを識別する方法を指定します。 Content-ID URL値は、本文部分のContent-IDヘッダーフィールドに含まれています。
Examples of SIP header fields referencing a body part using a Content-ID URL are:
Content-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]は、位置情報を提供するためにContent-ID URLを使用して、Geolocationヘッダーフィールドがボディパーツを参照する方法を指定します。
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]は、Refer-ToヘッダーフィールドがContent-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.
Content-IDヘッダーフィールドを使用してSIPメッセージの完全なメッセージ本文を一意に識別する方法、およびContent-ID URLを使用して完全なメッセージ本文を参照する方法は、現在指定されていません。
Note: In [RFC5621], the Content-ID URL references a specific body part only.
注：[RFC5621]では、Content-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 Content-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）が値（[RFC6442]で指定）によって場所を伝えるINVITE要求を送信し、セッション記述プロトコル（SDP）オファーを含めないことを決定した場合、UACはMIMEエンティティを1つだけ含める必要があります。 INVITEリクエスト。この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]には、位置情報を含むボディパーツを参照するGeolocationヘッダーフィールドを含める必要があるため、UACには、INVITEリクエストに単一のボディパーツを持つマルチパートメッセージボディが含まれ、「application / pidf + xml 'MIMEタイプと、本文部分の関連するContent-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: ...
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連絡先：<sips：alice@atlanta.example.com> Content-Type：multipart / mixed; border = boundary1 Content-Length：...
--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>
<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エンティティを1つだけ含める必要があります。このMIMEエンティティは、「application / resource-lists + 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]ターゲットのリストを含むボディパーツを参照するRefer-Toヘッダーフィールドを含める必要があるため、UACはREFERリクエストに単一のボディパーツを持つマルチパートメッセージボディを含み、ターゲットのリストを含めます'application / resource-lists + xml' MIMEタイプおよび関連する本文部分のContent-IDヘッダーフィールド。
Example message (SIP REFER):
メッセージの例（SIP REFER）：
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; 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>参照先：<cid：cn35t8jf02@example.com> Refer-Sub：false必須：複数参照、norefersub許可：INVITE、ACK、CANCEL、OPTIONS、BYE、REFER、SUBSCRIBE、NOTIFY許可イベント：ダイアログ受け入れ：application / sdp、message / sipfrag Content-Type：multipart / mixed; border = boundary1 Content-Length：...
--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--
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 Content-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 Content-IDヘッダーフィールドがSIPヘッダーフィールドとして使用される場合、完全なメッセージ本文と、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 Content-ID URLが完全なメッセージ本文と、いくつかの追加のSIPヘッダーフィールドによって提供されるメタデータを参照できるように[RFC5621]を更新しました。
o Updates [RFC5368] and [RFC6442] by adding text that explicitly states that a SIP Content-ID header field can be used.
o [RFC5368]と[RFC6442]を更新して、SIP Content-IDヘッダーフィールドを使用できることを明示的に示すテキストを追加します。
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.
既存の仕様がContent-ID URLによって参照される単一のボディパーツを運ぶマルチパートメッセージボディの使用法のみを定義している場合、仕様が更新されない限り、実装は非マルチパートメッセージボディでMIMEエンティティを運んではなりません（MUST NOT）。明示的に許可します。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section defines the usage of the Content-ID header field for SIP.
このセクションでは、SIPのContent-IDヘッダーフィールドの使用法を定義します。
The ABNF [RFC5234] for the Content-ID header field is:
Content-IDヘッダーフィールドのABNF [RFC5234]は次のとおりです。
Content-ID = "Content-ID" HCOLON msg-id
Content-ID = "Content-ID" HCOLON msg-id
msg-id = "<" id-left "@" id-right ">"
Note: id-left and id-right are specified in [RFC5322]. HCOLON is defined in [RFC3261].
注：id-leftとid-rightは[RFC5322]で指定されています。 HCOLONは[RFC3261]で定義されています。
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.
注：SIPヘッダーフィールドで使用される場合、[RFC5322]の構文と比較して、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.
Content-IDヘッダーフィールド値の値は、埋め込まれたMIME Content-IDヘッダーフィールド値を含め、特定のSIPメッセージのコンテキストで一意である必要があります。 SIP Content-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メッセージのヘッダーフィールドに含まれているContent-IDヘッダーフィールドは、SIPメッセージのメッセージ本文と、以下によって提供されるメタデータを識別します。
o A MIME-Version header field, if included in the header fields of the SIP message.
o MIME-Versionヘッダーフィールド（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-」プレフィックスヘッダーフィールド（Content-IDヘッダーフィールド自体を含む）。
The Content-ID header field can be included in any SIP message that is allowed to contain a message-body.
Content-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ヘッダーフィールドで識別されるメッセージ本文は、非マルチパートメッセージ本文またはマルチパートメッセージ本文にすることができます。
A UA MAY include a Content-ID header field in any SIP message that is allowed to contain a message-body.
UAは、メッセージ本文を含めることが許可されているSIPメッセージにContent-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メッセージにContent-IDヘッダーフィールドを含めてはなりません（MUST NOT）。
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は、Content-IDヘッダーフィールドの値を、SIPメッセージのコンテキストで一意の値に設定する必要があります。
A proxy MUST NOT add a Content-ID header field in a SIP message.
プロキシはSIPメッセージにContent-IDヘッダーフィールドを追加してはなりません（MUST NOT）。
A proxy MUST NOT modify a Content-ID header field included in a SIP message.
プロキシは、SIPメッセージに含まれるContent-IDヘッダーフィールドを変更してはなりません（MUST NOT）。
A proxy MUST NOT delete a Content-ID header field from a SIP message.
プロキシはSIPメッセージからContent-IDヘッダーフィールドを削除してはなりません（MUST NOT）。
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]の例を示しています。SIPContent-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>
<?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の2番目の段落を更新し、MIME Content-IDヘッダーフィールドまたはSIP Content-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.
複数のREFER-Targetを含むREFERリクエストのRefer-Toヘッダーフィールドには、URIを運ぶボディパーツを指すポインター（つまり、RFC 2392 [RFC2392]に基づくContent-ID Uniform Resource Locator（URL））を含める必要がありますリスト。 REFER-Issuerは、URIリストに特定のURIを複数回含めてはなりません（SHOULD NOT）。
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.
複数のREFER-Targetを含むREFERリクエストのRefer-Toヘッダーフィールドには、ボディパーツまたはメッセージボディを指すポインタ（つまり、RFC 2392 [RFC2392]に基づくContent-ID Uniform Resource Locator（URL））を含める必要がありますURIリストを保持します。 REFER-Issuerは、URIリストに特定のURIを複数回含めてはなりません（SHOULD NOT）。 REFER要求は、MIME Content-IDヘッダーフィールド[RFC4483]またはSIP Content-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を更新し、本文部分への参照を許可することに加えて、Content-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.
Content-ID URLを使用すると、本文部分への参照を作成できます。特定のContent-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).
Content-ID URLを使用すると、本文部分またはメッセージ本文（およびメッセージ本文を説明するヘッダーフィールド）への参照を作成できます。特定のContent-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の2番目の段落を更新し、MIME Content-IDヘッダーフィールドまたはSIP Content-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では、アリスはターゲットであり、LSであり、LRとして機能するボブに自分の位置を直接伝えています。この伝達はポイントツーポイントであり、SIPレイヤの中間を通過しません。ロケーションオブジェクトは、初期のSIPリクエストで値によってMIME本文として表示され、ボブはそのSIPリクエストに適切に応答します。このドキュメント内に導入された「悪い位置情報」応答コードは、悪い位置情報をボブに伝えた場合にアリスに具体的に通知するためのものです（たとえば、ボブは「提供された位置を解析できません」、または「アリスを特定するのに十分な位置情報がありませんです」）。
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では、アリスはターゲットであり、LSであり、LRとして機能するボブに自分の位置を直接伝えています。この伝達はポイントツーポイントであり、SIPレイヤの中間を通過しません。ロケーションオブジェクトは、初期のSIPリクエストで値によってMIME本文として表示され、ボブはそのSIPリクエストに適切に応答します。ロケーション情報のラベル付けには、MIME Content-IDヘッダーフィールド[RFC4483]またはSIP Content-IDヘッダーフィールド[RFC8262]のいずれかを使用する必要があります。このドキュメント内に導入された「悪い位置情報」応答コードは、悪い位置情報をボブに伝えた場合にアリスに具体的に通知するためのものです（たとえば、ボブは「提供された位置を解析できません」、または「アリスを特定するのに十分な位置情報がありませんです」）。
The Content-ID header field value MUST NOT reveal sensitive user information.
Content-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.
Content-IDヘッダーフィールドに関連付けられたメッセージ本文が暗号化された本文である場合、Content-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で説明したヘッダーフィールドは、「Session Initiation Protocol（SIP）Parameters」レジストリの「Header Fields」サブレジストリに、次の値を含む行を追加することで登録されています。
Header Name: Content-ID
ヘッダー名：Content-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、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年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。、「Content-ID and Message-ID Uniform Resource Locators」、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：Session Initiation Protocol」 、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]バーガー、E、編、「セッション開始プロトコル（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]クロッカー、D。、エド。および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。、編、「インターネットメッセージ形式」、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、「Referring to Multiple Resources in the Session Initiation Protocol（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
Ivo Sedlacek Ericsson Sokolovska 79 Praha 18600 Czech Republic
Ivo Sedlacek Ericsson Sokolovska 79 Praha 18600チェコ共和国
Email: ivo.sedlacek@ericsson.com