Network Working Group G. Camarillo
Request for Comments: 5621 Ericsson
Updates: 3204, 3261, 3459 September 2009
Category: Standards Track
Message Body Handling in the Session Initiation Protocol (SIP)
Abstract
抽象
This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies.
この文書では、メッセージ本文がSIPでどのように扱われるかを指定します。また、この文書は、メッセージ本文にMIME（多目的インターネットメール拡張）のためのSIPユーザエージェントのサポートを指定します。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message Body Encoding . . . . . . . . . . . . . . . . . . . . 3
3.1. Background on Message Body Encoding . . . . . . . . . . . 3
3.2. UA Behavior to Encode Binary Message Bodies . . . . . . . 5
4. 'multipart' Message Bodies . . . . . . . . . . . . . . . . . . 6
4.1. Background on 'multipart' Message Bodies . . . . . . . . . 6
4.2. Mandatory Support for 'multipart' Message Bodies . . . . . 7
4.3. UA Behavior to Generate 'multipart' Message Bodies . . . . 7
5. 'multipart/mixed' Message Bodies . . . . . . . . . . . . . . . 7
6. 'multipart/alternative' Message Bodies . . . . . . . . . . . . 8
6.1. Background on 'multipart/alternative' Message Bodies . . . 8
6.2. UA Behavior to Generate 'multipart/alternative'
Message Bodies . . . . . . . . . . . . . . . . . . . . . . 8
6.3. UA Behavior to Process 'multipart/alternative' Message
Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. 'multipart/related' Message Bodies . . . . . . . . . . . . . . 9
7.1. Background on 'multipart/related' Message Bodies . . . . . 9
7.2. UA Behavior to Generate 'multipart/related' Message
Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3. UA Behavior to Process 'multipart/related' Message
Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Background on Content and Disposition Types in SIP . . . . 10
8.2. UA Behavior to Set the 'handling' Parameter . . . . . . . 12
8.3. UA Behavior to Process 'multipart/alternative' . . . . . . 13
8.4. UAS Behavior to Report Unsupported Message Bodies . . . . 13
9. Message Body Processing . . . . . . . . . . . . . . . . . . . 14
9.1. Background on References to Message Body Parts . . . . . . 14
9.2. UA Behavior to Generate References to Message Bodies . . . 14
9.3. UA Behavior to Process Message Bodies . . . . . . . . . . 14
9.4. The 'by-reference' Disposition Type . . . . . . . . . . . 15
10. Guidelines to Authors of SIP Extensions . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12.1. Registration of the 'by-reference' Disposition Type . . . 17
12.2. Update of the 'handling' Parameter Registration . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . . 18
Message body handling in SIP was originally specified in [RFC3261], which relied on earlier specifications (e.g., MIME) to describe some areas. This document contains background material on how bodies are handled in SIP and normative material on areas that had not been specified before or whose specifications needed to be completed. Sections containing background material are clearly identified as such by their titles. The material on the normative sections is based on experience gained since [RFC3261] was written. Implementers need to implement what is specified in [RFC3261] (and its references) in addition to what is specified in this document.
SIPの取り扱いメッセージボディは、もともといくつかの領域を説明するために、以前の仕様（例えば、MIME）に頼っている、[RFC3261]で指定されました。この文書では、体がまたはその仕様に完了する必要の前に指定されていなかった分野にSIPおよび規範的な材料で処理する方法に背景資料が含まれています。背景素材を含むセクションは明確にそのタイトルによってそのように識別されます。規範のセクションの材料は、[RFC3261]以来、得られた経験に基づいて書かれていました。実装者は、本書に定めるもののほかに、[RFC3261]（およびその参考文献）に指定されているものを実装する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following abbreviations are used in this document.
以下の略語が本文書で使用されています。
UA: User Agent
UA：ユーザエージェント
UAC: User Agent Client
UAC：ユーザー・エージェント・クライアント
UAS: User Agent Server
WHO：ユーザエージェントサーバ
URL: Uniform Resource Locator
URL：ユニフォームリソースロケータ
This section deals with the encoding of message bodies in SIP.
このセクションでは、SIPのメッセージボディのエンコーディングを扱います。
SIP [RFC3261] messages consist of an initial line (request line in requests and status line in responses), a set of header fields, and an optional message body. The message body is described using header fields such as Content-Disposition, Content-Encoding, and Content-Type, which provide information on its contents. Figure 1 shows a SIP message that carries a body. Some of the header fields are not shown for simplicity:
SIP [RFC3261]メッセージは、最初の行（要求および応答のステータス行のリクエストライン）、ヘッダフィールドのセット、および任意のメッセージ本体から成ります。メッセージ本体は、そのようなコンテンツの廃棄、コンテンツ符号化、およびその内容に関する情報を提供するコンテンツタイプ、などのヘッダフィールドを用いて説明します。図1は、本体を運ぶSIPメッセージを示しています。ヘッダフィールドの一部は簡略化のため図示されていません。
INVITE sip:conf-fact@example.com SIP/2.0 Content-Type: application/sdp Content-Length: 192
SIPのINVITE：conf-fact@example.com SIP / 2.0のContent-Type：アプリケーション/ SDPコンテンツの長さ：192
v=0 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 20002 RTP/AVP 31 a=rtpmap:31 H261/90000
V = 0 0 =アリス2890844526 2890842807 IN IP4 atlanta.example.com S = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ20000 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル=ビデオ20002 RTP / AVP 31 = rtpmap：31 H261 / 90000
Figure 1: SIP message carrying a body
図1：本体を運ぶSIPメッセージ
The message body of a SIP message can be divided into various body parts. Multipart message bodies are encoded using the MIME (Multipurpose Internet Mail Extensions) [RFC2045] format. Body parts are also described using header fields such as Content-Disposition, Content-Encoding, and Content-Type, which provide information on the contents of a particular body part. Figure 2 shows a SIP message that carries two body parts. Some of the header fields are not shown for simplicity:
SIPメッセージのメッセージ本体は、様々な身体の部分に分割することができます。マルチパートメッセージ本体はMIME（多目的インターネットメール拡張）[RFC2045]の形式を使用して符号化されます。本体部分は、特定の身体の部分の内容に関する情報を提供し、そのようなコンテンツの廃棄、コンテンツ符号化、およびコンテンツタイプとしてヘッダフィールドを用いて説明します。図2は、2つの本体部分を運ぶSIPメッセージを示しています。ヘッダフィールドの一部は簡略化のため図示されていません。
INVITE sip:conf-fact@example.com SIP/2.0 Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 619
conf-fact@example.com SIP / 2.0のContent-Type：SIP INVITE混合/マルチパートと、境界= "boundary1" のContent-Length：619
--boundary1 Content-Type: application/sdp
--boundary1のContent-Type：アプリケーション/ SDP
v=0 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 20002 RTP/AVP 31 a=rtpmap:31 H261/90000
V = 0 0 =アリス2890844526 2890842807 IN IP4 atlanta.example.com S = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ20000 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル=ビデオ20002 RTP / AVP 31 = rtpmap：31 H261 / 90000
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1のContent-Type：アプリケーション/リソース・リスト+ xmlのコンテンツディスポジション：受信者リスト
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list> <entry uri="sip:bill@example.com"/> <entry uri="sip:randy@example.net"/> <entry uri="sip:joe@example.org"/> </list> </resource-lists> --boundary1--
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト"> <リスト> <エントリーのURI =「SIP：法案@ example.com "/> <エントリURI =" SIP：randy@example.net "/> <エントリURI =" SIP：joe@example.org "/> </リスト> </リソース・リスト> --boundary1 -
Figure 2: SIP message carrying a body
図2：本体を運ぶSIPメッセージ
SIP uses S/MIME [RFC3851] to protect message bodies. As specified in [RFC3261], UASs that cannot decrypt a message body or a body part can use the 493 (Undecipherable) response to report the error.
SIPメッセージボディを保護するために、S / MIME [RFC3851]を使用します。 [RFC3261]で指定されるように、メッセージ本文または身体部分を解読することができないのUASは、エラーを報告する493（解読不能）応答を使用することができます。
SIP messages can carry binary message bodies such as legacy signalling objects [RFC3204]. SIP proxy servers are 8-bit safe. That is, they are able to handle binary bodies. Therefore, there is no need to use encodings such as base64 to transport binary bodies in SIP messages. Consequently, UAs SHOULD use the binary transfer encoding [RFC4289] for all payloads in SIP, including binary payloads. The only case where a UA MAY use a different encoding is when transferring application data between applications that only handle a different encoding (e.g., base64).
SIPメッセージは、レガシーシグナリングオブジェクト[RFC3204]などのバイナリメッセージ本体を運ぶことができます。 SIPプロキシサーバは、8ビット安全です。それは、彼らがバイナリ遺体を処理することができる、です。したがって、SIPメッセージ内のバイナリ体を輸送するようBASE64などのエンコーディングを使用する必要はありません。したがって、UAはバイナリペイロードを含むSIP内のすべてのペイロード、バイナリ転送エンコード[RFC4289]を使用すべきです。のみ異なる符号化（例えば、BASE64）を処理するアプリケーションの間でアプリケーションデータを転送するとき、UAは、異なる符号化を使用するかもしれない唯一の場合です。
This section deals with 'multipart' message bodies and their handling.
このセクションでは、「マルチパート」メッセージ本文とその取扱いを扱っています。
[RFC3261] did not mandate support for 'multipart' message bodies in MIME format [RFC2046]. However, since [RFC3261] was written, many SIP extensions rely on them.
[RFC3261]はMIME形式[RFC2046]の「マルチパート」メッセージ本体のサポートを強制しませんでした。 [RFC3261]が書かれていたので、多くのSIPの拡張は、それらに依存しています。
The use of 'multipart/mixed' MIME bodies is a useful tool to build SIP extensions. An example of such an extension could be the inclusion of location information in an INVITE request. Such an INVITE request would use the 'multipart/mixed' MIME type [RFC2046] to carry two body parts: a session description and a location object. An example of an existing extension that uses 'multipart/mixed' to send a session description and a legacy-signalling object is defined in [RFC3204].
「multipart / mixedの」MIMEボディの使用は、SIPの拡張機能を構築するための便利なツールです。そのような拡張の例は、INVITE要求に位置情報を含めることができました。セッション記述と位置オブジェクト：そのような要求は、2つの本体部分を運ぶために「混合/マルチパート」のMIMEタイプ[RFC2046]を使用するINVITE。セッション記述を送信するために「混合/マルチ」を使用して、レガシーシグナリングオブジェクトは[RFC3204]で定義されている既存の拡張の例を示します。
Another MIME type that is useful to build SIP extensions is 'multipart/alternative' [RFC2046]. Each body part within a 'multipart/alternative' carries an alternative version of the same information.
SIPの拡張機能を構築するために有用な別のMIMEタイプは「マルチパート/代替」[RFC2046]です。 「マルチパート/代替」内の各部位は、同じ情報の別のバージョンを運びます。
The transition from SDP to new session description protocols could be implemented using 'multipart/alternative' bodies. SIP messages (e.g., INVITE requests) could carry a 'multipart/alternative' body with two body parts: a session description written in SDP and a session description written in a newer session description format. Legacy recipient UAs would use the session description written in SDP. New recipient UAs would use the one written in the newer format.
SDPから新しいセッション記述プロトコルへの移行は、「マルチパート/代替の体を使用して実施することができます。 SDPで記述されたセッション記述と、新しいセッション記述形式で記述されたセッション記述：SIPメッセージ（例えば、INVITE要求）2つの本体部分と「マルチパート/代替の体を運ぶことができます。レガシー受信者UAはSDPで書かれたセッション記述を使用します。新しい受信者UAは、新しい形式で書かれたものを使用します。
Nested MIME bodies are yet another useful tool to build and combine SIP extensions. Using the extensions in the previous examples, a UA that supported a new session description format and that needed to include a location object in an INVITE request would include a 'multipart/mixed' body with two body parts: a location object and a 'multipart/alternative'. The 'multipart/alternative' body part would, in turn, have two body parts: a session description written in SDP and a session description written in the newer session description format.
入れ子になったMIMEボディはまだSIPの拡張機能を構築し、組み合わせるための別の有用なツールです。位置オブジェクトと「マルチ：前の例での拡張を使用して、INVITE要求内の位置のオブジェクトを含むために必要な新たなセッション記述形式とそれをサポートUAは、2つの本体部分と「マルチパート/混合」体を含むであろう「/代替。セッション記述SDPで記述され、新しいセッション記述形式で記述されたセッション記述：「マルチパート/代替」身体の部分は、次に、2つの本体部分を有することになります。
For all MIME-based extensions to work, the recipient needs to be able to decode the multipart bodies. Therefore, SIP UAs MUST support parsing 'multipart' MIME bodies, including nested body parts. Additionally, UAs MUST support the 'multipart/mixed' and 'multipart/ alternative' MIME types. Support for other MIME types such as 'multipart/related' is OPTIONAL.
仕事へのすべてのMIMEベースの拡張機能の場合、受信者がマルチパートボディをデコードできるようにする必要があります。したがって、SIP UAは、ネストされた本体部分を含む「マルチパート」のMIMEボディを、解析サポートしなければなりません。また、UAは「マルチパート/ミックス」と「マルチパート/代替」MIMEタイプをサポートしなければなりません。このような「マルチパート/関連」などの他のMIMEタイプのためのサポートはオプションです。
Note that, by default, unknown 'multipart' subtypes are treated as 'multipart/mixed'. Also note that SIP extensions can also include 'multipart' MIME bodies in responses. That is why both UACs and UASs need to support 'multipart' bodies.
デフォルトでは、未知の「マルチパート」サブタイプは「multipart / mixedの」として扱われることに注意してください。また、SIPの拡張も応答でMIMEボディ「マルチパート」を含むことができることに注意してください。求めるUACとのUASの両方が、 "マルチパートの体をサポートする必要がある理由です。
Legacy SIP UAs without support for 'multipart' bodies generate a 415 (Unsupported Media Type) response when they receive a 'multipart' body in a request. A UAC sending a 'multipart' body can receive such an error response when communicating with a legacy SIP UA that predates this specification.
彼らは要求の中で「マルチパートの体を受信したときに "マルチパートの体のためのサポートなしでレガシーのSIP UAは415（サポートされていないメディアタイプ）応答を生成します。本明細書に先行レガシSIP UAと通信するときに「マルチパート」体を送るUACは、エラー応答を受信することができます。
It has been observed in the field that a number of legacy SIP UAs without support for 'multipart' bodies simply ignored those bodies when they were received. These UAs did not return any error response. Unsurprisingly, SIP UAs not being able to report this type of error have caused serious interoperability problems in the past.
それは、「マルチパートの体のためのサポートなしでレガシーSIPのUAの数は、単に彼らが受信されたそれらのボディを無視フィールドで観察されています。これらのUAは任意のエラー応答を返しませんでした。当然のことながら、このタイプのエラーを報告することができないSIP UAは、過去に深刻な相互運用性の問題を引き起こしています。
UAs SHOULD avoid unnecessarily nesting body parts because doing so would, unnecessarily, make processing the body more laborious for the receiver. However, [RFC2046] states that a 'multipart' media type with a single body part is useful in some circumstances (e.g., for sending non-text media types). In any case, UAs SHOULD NOT nest one 'multipart/mixed' within another unless there is a need to reference the nested one (i.e., using the Content ID of the nested body part). Additionally, UAs SHOULD NOT nest one 'multipart/alternative' within another.
そうすることが、必要以上に、受信機のために体を処理するには、より面倒になるだろうので、UAは、不必要にネスティング体の部分を避ける必要があります。しかしながら、[RFC2046]は、単一の本体部分と「マルチパート」メディアタイプが（非テキストメディアタイプを送信するために、例えば）いくつかの状況において有用であると述べています。いずれの場合においても、UAはネスト1べきではない「複合/混合」別内（すなわち、ネストされた身体部分のコンテンツIDを使用して）、ネストされたものを参照する必要がある場合を除き。また、UAは巣互いに内の「マルチパート/代替」べきではありません。
Note that UAs receiving unnecessarily nested body parts treat them as if they were not nested.
それらがネストされていなかったかのように不必要にネストされた体の部分を受け取るUAがそれらを扱うことに注意してください。
This section does not specify any additional behavior regarding how to generate and process 'multipart/mixed' bodies. This section is simply included for completeness.
このセクションでは、「混合/マルチパートの体を生成して処理する方法に関するいかなる追加の動作を指定しません。このセクションでは、単に完全性のために含まれています。
This section deals with 'multipart/alternative' message bodies and their handling.
「マルチパート/代替」というメッセージの本文とその取り扱いこのセクションでは扱っています。
Each body part within a 'multipart/alternative' carries an alternative version of the same information. The body parts are ordered so that the last one is the richest representation of the information. The recipient of a 'multipart/alternative' body chooses the last body part it understands.
「マルチパート/代替」内の各部位は、同じ情報の別のバージョンを運びます。最後は、情報の豊かな表現があるように、体の部分を注文しています。 「マルチパート/代替の体の受信者は、それが理解し、最後の身体の部分を選択します。
Note that within a body part encoded in a given format (i.e., of a given content type), there can be optional elements that can provide richer information to the recipient in case the recipient supports them. For example, in SDP (Session Description Protocol) [RFC4566], those optional elements are encoded in 'a' lines. These types of optional elements are internal to a body part and are not visible at the MIME level. That is, a body part is understood if the recipient understands its content type, regardless of whether or not the body part's optional elements are understood.
（すなわち、特定のコンテンツタイプの）所定のフォーマットで符号化さ本体部内に、受信者がそれらをサポートする場合に受信者に豊かな情報を提供することができる任意の要素があり得ることに留意されたいです。例えば、SDP（セッション記述プロトコル）[RFC4566]に、これらのオプションの要素は、「」線で符号化されます。オプションの要素のこれらのタイプは、本体部の内部にあるとMIMEレベルでは見えません。受信者は関係なく、身体部分の任意の要素は理解されているか否かの、そのコンテンツの種類を理解している場合、すなわち、身体の一部が理解されます。
Note as well that each part of a 'multipart/alternative' body represents the same data, but the mapping between any two parts is not necessarily without information loss. For example, information can be lost when translating 'text/html' to 'text/ plain'. [RFC2046] recommends that each part should have a different Content-ID value in the case where the information content of the two parts is not identical.
「マルチパート/代替の体の各部分が同じデータを表すが、任意の2つの部分の間のマッピングは、情報の損失なしに、必ずしもではないことも注意してください。 「プレーンテキスト/」から「text / htmlで」を翻訳するとき例えば、情報が失われることがあります。 [RFC2046]は、各部分は、2つの部分の情報量が同一でない場合には、異なるコンテンツIDの値を有していなければならないことをお勧めします。
Section 8.2 mandates all the top-level body parts within a 'multipart/alternative' to have the same disposition type.
「マルチパート/代替」内のセクション8.2義務すべてのトップレベルの体の部分は、同じ気質のタイプを持っています。
The 'session' and 'early-session' [RFC3959] disposition types require that all the body parts of a 'multipart/alternative' body have different content types. Consequently, for the 'session' and 'early-session' disposition types, UAs MUST NOT place more than one body part with a given content type in a 'multipart/alternative' body. That is, for 'session' and 'early-session', no body part within a 'multipart/alternative' can have the same content type as another body part within the same 'multipart/alternative'.
「セッション」と「早期セッション」[RFC3959]処分の種類は、「マルチパート/代替の体のすべてのボディ部分が異なるコンテンツタイプを持っている必要があります。その結果、「セッション」と「初期セッションの処分タイプについて、UAは "マルチパート/代替の体に与えられたコンテンツ・タイプを持つ複数のボディ部を配置してはならず。それは、「セッション」と「初期セッションのために、「マルチパート/代替」内には身体の部分は同じ「マルチパート/代替」内の別の身体の部分と同じコンテンツタイプを持つことはできませんされています。
This section does not specify any additional behavior regarding how to process 'multipart/alternative' bodies. This section is simply included for completeness.
このセクションでは、「マルチパート/代替の体をどのように処理するかに関するいかなる追加の動作を指定しません。このセクションでは、単に完全性のために含まれています。
This section deals with 'multipart/related' message bodies and their handling.
「マルチパート/関連」メッセージ本文とその取り扱いこのセクションで扱っています。
Compound objects in MIME are represented using the 'multipart/ related' content type [RFC2387]. The body parts within a particular 'multipart/related' body are all part of a compound object and are processed as such. The body part within a 'multipart/related' body that needs to be processed first is referred to as the 'root' body part. The root body part of a 'multipart/related' body is identified by the 'start' parameter, which is a Content-Type header field parameter and contains a Content-ID URL pointing to the root body part. If the start parameter is not present, the root body part is, by default, the first body part of the 'multipart/related'. An example of a compound object is a web page that contains images. The html body part would be the root. The remaining body parts would contain the images. An example of a SIP extension using 'multipart/ related' is specified in [RFC4662].
MIME中の化合物のオブジェクトは、「マルチパート/関連のコンテンツタイプ[RFC2387]を使用して表されます。特定の「マルチパート/関連」体内の体の部分は、すべての化合物の一部であり、そのように処理されます。最初に処理する必要が「マルチパート/関連」体内の身体部分は「ルート」の身体部分と呼ばれます。 「マルチパート/関連」のルート本体部分は、本体は、Content-Typeヘッダフィールドパラメータであり、ルート本体部分を指すのContent-ID URLが含まれている「開始」パラメータによって識別されます。スタートパラメータが存在しない場合は、ルート本体部分は、デフォルトでは、「マルチパート/関連」の最初の本体部分です。複合オブジェクトの例は、画像を含むWebページです。 HTMLのボディ部分はルートになります。残りの体の部分は、画像が含まれます。 「関連/マルチ」を使用してSIP拡張の例は[RFC4662]で指定されています。
This section does not specify any additional behavior regarding how to generate 'multipart/related' bodies. This section is simply included for completeness.
このセクションでは、「マルチパート/関連の体を生成する方法に関するいかなる追加の動作を指定しません。このセクションでは、単に完全性のために含まれています。
Per [RFC2387], a UA processing a 'multipart/related' body processes the body as a compound object ignoring the disposition types of the body parts within it. Ignoring the disposition types of the individual body parts makes sense in the context in which 'multipart/ related' was originally specified. For instance, in the example of the web page, the implicit disposition type for the images would be 'inline', since the images are displayed as indicated by the root html file. However, in SIP, the disposition types of the individual body parts within a 'multipart/related' play an important role and, thus, need to be considered by the UA processing the 'multipart/ related'. Different SIP extensions that use the same disposition type for the 'multipart/related' body can be distinguished by the disposition types of the individual body parts within the 'multipart/ related'. Consequently, SIP UAs processing a 'multipart/related' body with a given disposition type MUST process the disposition types of the body parts within it according to the SIP extension making use the disposition type of the 'multipart/related'.
[RFC2387]、UAは、「マルチパート/関連の体がその中の身体の部分の配置タイプを無視する化合物として体を処理する処理。個々のボディパーツの配置タイプを無視すると、「関連するマルチパートが/」最初に指定されたコンテキストでは意味があります。例えば、ウェブページの例では、画像のための暗黙的な配置タイプがルートHTMLファイルによって示されるように画像が表示されるので、「インライン」であろう。しかし、SIPに、「マルチパート/関連」内の個々のボディパーツの配置タイプは、重要な役割を果たし、したがって、「マルチパート/関連」の処理UAによって検討する必要があります。 「マルチパート/関連する」本体「は、マルチパート/関連」内の個々の身体部分の配置の種類によって区別することができるため、同じ配置のタイプを使用し、異なるSIP拡張機能。所与の配置タイプが「マルチパート/関連」の配置タイプを使用行うSIPの拡張に応じてその中の身体の部分の配置タイプを処理しなければならないとの結果として、SIP UAは、「マルチパート/関連の体を処理します。
Note that UAs that do not understand 'multipart/related' will treat 'multipart/related' bodies as 'multipart/mixed' bodies. These UAs will not be able to process a given body as a compound object. Instead, they will process the body parts according to their disposition type as if each body part was independent from each other.
なお、「マルチパート/関連は」 'はmultipart / mixedの体としての「マルチパート/関連の体を扱います理解していないのUA。これらのUAは複合オブジェクトとして与えられた体を処理することができません。各部位は、互いに独立していたかのようにその代わりに、彼らは彼らの配置タイプに応じて身体の部分を処理します。
This section deals with disposition types in message bodies.
このセクションでは、メッセージ本文中に処分の種類を扱っています。
The Content-Disposition header field, defined in [RFC2183] and extended by [RFC3261], describes how to handle a SIP message's body or an individual body part. Examples of disposition types used in SIP in the Content-Disposition header field are 'session' and 'render'.
Content-Dispositionヘッダーフィールド、[RFC2183]で定義されており、[RFC3261]によって拡張は、SIPメッセージのボディまたは個々の身体部分を処理する方法について説明します。コンテンツの廃棄ヘッダフィールドに、SIPで使用される配置タイプの例は、「セッション」と「レンダリング」です。
[RFC3204] and [RFC3459] define the 'handling' parameter for the Content-Disposition header field. This parameter describes how a UAS reacts if it receives a message body whose content type or disposition type it does not understand. If the parameter has the value 'optional', the UAS ignores the message body; if the parameter has the value 'required', the UAS returns a 415 (Unsupported Media Type) response. The default value for the 'handling' parameter is 'required'. The following is an example of a Content-Disposition header field:
[RFC3204]及び[RFC3459]はコンテンツの廃棄ヘッダーフィールドのための「処理」パラメータを定義します。このパラメータは、そのコンテンツタイプや気質タイプ、それは理解していないメッセージ本文を受信した場合、UASがどのように反応するかを説明します。パラメータは「オプション」値を有する場合、UASは、メッセージボディを無視します。パラメータは、「必要な」の値を持つ場合、UASは415（サポートされていないメディアタイプ）応答を返します。 「取扱」パラメータのデフォルト値が「必要」です。以下は、Content-Dispositionヘッダーフィールドの例です。
Content-Disposition: signal; handling=optional
コンテンツディスポジション：信号。取り扱い=オプション
[RFC3204] identifies two situations where a UAS (User Agent Server) needs to reject a request with a body part whose handling is required:
[RFC3204]はUAS（ユーザエージェントサーバ）が取り扱いが要求される身体部分との要求を拒絶する必要がある二つの状況を識別する。
If the UAS did not understand the content type of the body part, the UAS can add an Accept header field to its 415 (Unsupported Media Type) response listing the content types that the UAS does understand. Nevertheless, there is no mechanism for a UAS that does not understand the disposition type of a body part to inform the UAC about which disposition type was not understood or about the disposition types that are understood by the UAS.
UASは、身体の一部のコンテンツタイプを理解していない場合、UASは、UASが理解しないコンテンツタイプをリストするその415（サポートされていないメディアタイプ）応答にAcceptヘッダーフィールドを追加することができます。それにも関わらず、処分の種類は理解されていなかったかについてやUASによって理解されている処分タイプについてUACを知らせるために、身体の部分の配置タイプを理解していないUASのためのメカニズムはありません。
The reason for not having such a mechanism is that disposition types are typically supported within a context. Outside that context, a UA need not support the disposition type. For example, a UA can support the 'session' disposition type for body parts in INVITE and UPDATE requests and their responses. However, the same UA would not support the 'session' disposition type in MESSAGE requests.
このような機構を備えていない理由は、配置のタイプは、典型的には、コンテキスト内でサポートされていることです。その文脈の外では、UAは、処分の種類をサポートしている必要はありません。例えば、UAはINVITEおよびUPDATE要求とその応答で体の部分のための「セッションの気質タイプをサポートすることができます。しかし、同じUAはMESSAGEリクエストで「セッション」気質タイプをサポートしていません。
In another example, a UA can support the 'render' disposition type for 'text/plain' and 'text/html' body parts in MESSAGE requests. Additionally, the UA can support the 'session' disposition type for 'application/sdp' body parts in INVITE and UPDATE requests and their responses. However, the UA might not support the 'render' disposition type for 'application/sdp' body parts in MESSAGE requests, even if, in different contexts, the UA supported all of the following: the 'render' disposition type, the 'application/sdp' content type, and the MESSAGE method.
別の例では、UAは、MESSAGE要求の「text / plainの」と「text / htmlの」身体の部分のための「レンダリング」気質タイプをサポートすることができます。また、UAはINVITEおよびUPDATE要求とその応答で「アプリケーション/ SDP」体の部分のための「セッションの気質タイプをサポートすることができます。しかし、UAは、異なるコンテキストで、UAは、次のすべてをサポートしていても、MESSAGEリクエストで「アプリケーション/ SDP」体の部分は「レンダリング」気質タイプをサポートしていない可能性があります：「レンダリング」気質タイプ、「アプリケーションを/ SDPのコンテンツの種類、およびMESSAGE方法。
A given context is generally (but not necessarily) defined by a method, a disposition type, and a content type. Support for a specific context is usually defined within an extension. For example, the extension for instant messaging in SIP [RFC3428] mandates support for the MESSAGE method, the 'render' disposition type, and the 'text/plain' content type.
指定されたコンテキストは、一般に（必ずしもそうではない）方法、気質タイプ、およびコンテンツタイプによって定義されます。特定のコンテキストのサポートは、通常の拡張内で定義されています。例えば、SIP [RFC3428]でインスタントメッセージングのための拡張は、MESSAGEメソッド、「レンダリング」気質タイプ、および「text / plainの」コンテンツタイプのサポートを義務付け。
Note that, effectively, content types are also supported within a context. Therefore, the use of the Accept header field in a 415 (Unsupported Media Type) response is not enough to describe in which contexts a particular content type is supported.
なお、効果的に、コンテンツタイプは、コンテキスト内でサポートされています。したがって、415（サポートされていないメディアタイプ）応答のヘッダを許可するフィールドの使用は、特定のコンテンツタイプがサポートされているコンテキスト記述するのに十分ではありません。
Therefore, support for a particular disposition type within a given context is typically signalled by the use of a particular method or an option-tag in a Supported or a Require header field. When support for a particular disposition type within a context is mandated, support for a default content type is also mandated (e.g., a UA that supports the 'session' disposition type in an INVITE request needs to support the 'application/sdp' content type).
したがって、特定のコンテキスト内の特定の配置タイプの支持体は、典型的に担持またはRequireヘッダーフィールドに特定の方法またはオプションタグの使用によってシグナリングされます。コンテキスト内の特定の気質タイプのサポートが義務付けられている場合は、デフォルトのコンテンツタイプのサポートも義務付けられている（例えば、「アプリケーション/ SDP」コンテンツタイプをサポートする必要があるINVITEリクエストで「セッション」気質タイプをサポートしていますUA ）。
As stated earlier, the 'handling' Content-Disposition parameter can take two values: 'required' or 'optional'. While it is typically easy for a UA to decide which type of handling an individual body part requires, setting the 'handling' parameter of 'multipart' bodies requires extra considerations.
先に述べたように、「ハンドリング」のContent-処分のパラメータは、2つの値を取ることができます：「必要」または「オプション」。 UAは "マルチパートの体の「取扱」パラメータを設定し、必要とする個々の身体の部分を扱うのタイプを決定することが一般的に簡単ですが、余分な配慮が必要です。
If the handling of a 'multipart/mixed' body as a whole is required for processing its enclosing body part or message, the UA MUST set the 'handling' parameter of the 'multipart/mixed' body to 'required'. Otherwise, the UA MUST set it to 'optional'. The 'handling' parameters of the top-level body parts within the 'multipart/mixed' body are set independently from the 'handling' parameter of the 'multipart/mixed' body. If the handling of a particular top-level body part is required, the UA MUST set the 'handling' parameter of that body part 'required'. Otherwise, the UA MUST set it to 'optional'.
全体として「混合/マルチ」本体の取り扱いは、その封入体の一部またはメッセージを処理するために必要とされる場合、UAは、「必須」に「multipart / mixedの」本体の「処理」パラメータを設定しなければなりません。そうしないと、UAは、「オプション」に、それを設定しなければなりません。 「混合/マルチ」体内の最上位の本体部分の「処理」のパラメータは、「multipart / mixedの」本体の「ハンドリング」パラメータとは独立に設定されます。特に最上位の本体部分の処理が必要な場合、UAは、「必須」という身体の部分の「処理」パラメータを設定しなければなりません。そうしないと、UAは、「オプション」に、それを設定しなければなりません。
Per the previous rules, a 'multipart/mixed' body whose handling is optional can contain body parts whose handling is required. In such case, the receiver is required to process the body parts whose handling is required if and only if the receiver decides to process the optional 'multipart/mixed' body.
以前のルール、その取り扱いオプションであり取り扱いが必要である体の部分を含めることができます "はmultipart / mixedの体あたり。このような場合、受信機は、その取り扱いが要求される身体の部分を処理するために必要であれば、受信機は、オプション「multipart / mixedの」体を処理することを決定した場合にのみ。
Also per the previous rules, a 'multipart/mixed' body whose handling is required can contain only body parts whose handling is optional. In such case, the receiver is required to process the body as a whole but, when processing it, the receiver may decide (based on its local policy) not to process any of the body parts.
また、以前のルール、その取り扱いが要求される処理オプションのみ身体の部分を含むことができ「multipart / mixedの」体当たり。このような場合、受信機は、全体として身体を処理するために必要とされるが、それを処理する場合、受信機は、本体部分のいずれかを処理しない（ローカルポリシーに基づいて）決定することができます。
The 'handling' parameter is a Content-Disposition parameter. Therefore, in order to set this parameter, it is necessary to provide the 'multipart/mixed' body with a disposition type. Per [RFC3261], the default disposition type for 'application/sdp' is 'session' and for other bodies is 'render'. UAs SHOULD assign 'multipart/mixed' bodies a disposition type of 'render'.
「取扱」パラメータには、Content-処分のパラメータです。したがって、このパラメータを設定するためには、気質タイプで「混合/マルチパート」体を提供することが必要です。パー[RFC3261]、「SDPアプリケーション/」のデフォルトの配置タイプが「セッション」であり、他の機関のための「レンダリング」されます。 UAは "マルチパート/混合の体「レンダリング」の気質タイプを割り当てる必要があります。
Note that the fact that 'multipart/mixed' bodies have a default disposition type of 'render' does not imply that they will be rendered to the user. The way the body parts within the 'multipart/mixed' are handled depends on the disposition types of the individual body parts. The actual disposition type of the whole 'multipart/mixed' is irrelevant. The 'render' disposition type has been chosen for 'multipart/mixed' bodies simply because 'render' is the default disposition type in SIP.
「マルチパート/混合の体は、「レンダリング」のデフォルトの配置タイプを持っているという事実は、彼らがユーザーにレンダリングされることを意味するものではないことに注意してください。 「混合/マルチ」内の本体部分が処理される方法は、個々のボディパーツの配置の種類に依存します。全体「multipart / mixedの」の実際の配置タイプは無関係です。 「レンダリング」気質タイプは、というだけの理由「レンダリング」SIPのデフォルトの気質のタイプがある「混合/マルチパートの体のために選択されています。
If the handling of a 'multipart/alternative' body as a whole is required for processing its enclosing body part or message, the UA MUST set the 'handling' parameter of the 'multipart/alternative' body to 'required'. Otherwise, the UA MUST set it to 'optional'. The UA SHOULD also set the 'handling' parameter of all the top-level body part within the 'multipart/alternative' to 'optional'.
全体としての「マルチパート/代替」本体の取り扱いは、その封入体の一部またはメッセージを処理するために必要とされる場合、UAは、「必須」に「マルチパート/代替の体の「処理」パラメータを設定しなければなりません。そうしないと、UAは、「オプション」に、それを設定しなければなりません。 UAはまた、「オプション」の「マルチパート/代替」内のすべての最上位の本体部分の「処理」パラメータを設定する必要があります。
The receiver will process the body parts based on the handling parameter of the 'multipart/alternative' body. The receiver will ignore the handling parameters of the body parts. That is why setting them to 'optional' is at the "SHOULD" level and not at the "MUST" level -- their value is irrelevant.
受信機は、「マルチパート/代替の体のハンドリングパラメータに基づいて、身体の部分を処理します。受信機は、ボディ部品の取り扱いパラメータを無視します。 「オプション」に、それらを設定する理由は、「MUST」レベルで「SHOULD」レベルであるとはない - 彼らの値は無関係です。
The UA MUST use the same disposition type for the 'multipart/ alternative' body and all its top-level body parts.
UAは、「マルチパート/代替」体及びそのすべての最上位の本体部分に対して同じ配置のタイプを使用しなければなりません。
If the handling of a 'multipart/related' body as a whole is required for processing its enclosing body part or message, the UA MUST set the 'handling' parameter of the 'multipart/related' body to 'required'. Otherwise, the UA MUST set it to 'optional'. The 'handling' parameters of the top-level body parts within the 'multipart/related' body are set independently from the 'handling' parameter of the 'multipart/related' body. If the handling of a particular top-level body part is required, the UA MUST set the 'handling' parameter of that body part to 'required'. Otherwise, the UA MUST set it to 'optional'. If at least one top-level body part within a 'multipart/related' body has a 'handling' parameter of 'required', the UA SHOULD set the 'handling' parameter of the root body part to 'required'.
全体としての「マルチパート/関連の体の取り扱いは、その封入体の一部またはメッセージを処理するために必要とされる場合、UAは、「必須」に「マルチパート/関連の体の「処理」パラメータを設定しなければなりません。そうしないと、UAは、「オプション」に、それを設定しなければなりません。 「マルチパート/関連」体内の最上位の本体部分の「処理」パラメータが「マルチパート/関連の体の「ハンドリング」パラメータとは独立に設定されます。特に最上位の本体部分の処理が必要な場合、UAは、「必須」にその本体部分の「処理」パラメータを設定しなければなりません。そうしないと、UAは、「オプション」に、それを設定しなければなりません。 「マルチパート/関連」ボディ内に少なくとも1つのトップレベルの本体部が「必要」の「処理」パラメータを有する場合、UAは、「必須」にルート本体部分の「処理」パラメータを設定する必要があります。
The receiver of a 'multipart/alternative' body MUST process the body based on its handling parameter. The receiver SHOULD ignore the handling parameters of the body parts within the 'multipart/ alternative'.
受信機のマルチパート/代替 'の本体は、その処理パラメータに基づいて体を処理しなければなりません。受信機は、「マルチパート/代替」内の身体部分の処理パラメータを無視すべきです。
If a UAS cannot process a request because, in the given context, the UAS does not support the content type or the disposition type of a body part whose handling is required, the UAS SHOULD return a 415 (Unsupported Media Type) response even if the UAS supported the content type, the disposition type, or both in a different context.
指定されたコンテキストで、UASは、コンテンツの種類や取り扱い必要とされる身体部分の配置タイプをサポートしていない、ので、UASがリクエストを処理できない場合、UASは、たとえ415（サポートされていないメディアタイプ）レスポンスを返すべきですUASは、別のコンテキスト内のコンテンツタイプ、気質タイプ、またはその両方をサポート。
Consequently, it is possible to receive a 415 (Unsupported Media Type) response with an Accept header field containing all the content types used in the request.
これにより、リクエストで使用されるすべてのコンテンツタイプを含有するAcceptヘッダーフィールドを持つ415（サポートされていないメディアタイプ）応答を受信することが可能です。
If a UAS receives a request with a body part whose disposition type is not compatible with the way the body part is supposed to be handled according to other parts of the SIP message (e.g., a Refer-To header field with a Content-ID URL pointing to a body part whose disposition type is 'session'), the UAS SHOULD return a 415 (Unsupported Media Type) response.
UASは、その気質型本体部は、例えば、参照のために、コンテンツIDとURLフィールドヘッダ（SIPメッセージの他の部分に応じて処理することになっている方法と互換性のない身体の部分と要求を受信した場合その気質タイプは「セッション」）身体の部分を指し、UASは415（サポートされていないメディアタイプ）レスポンスを返すべきです。
This section deals with the processing of message bodies and how that processing is influenced by the presence of references to them.
このセクションでは、メッセージ本文の処理方法と、その処理は、それらへの参照の存在によって影響さを扱っています。
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. The way to handle that body part is defined by the field the Content-ID URL appears. For example, the extension to refer to multiple resources in SIP [RFC5368] places a Content-ID URL in a Refer-To header field. Such a Content-ID URL points to a body part that carries a URI list. In another example, the extension for file transfer in SDP [RFC5547] places a Content-ID URL in a 'file-icon' SDP attribute. This Content-ID URL points to a body part that carries a (typically small) picture.
コンテンツIDのURLは、身体の部分への参照を作成することができます。与えられたコンテンツID URL [RFC2392]、（SDP属性で、例えば）ヘッダフィールド内、又は身体部分内に表示することができ、特定の身体の部分を指します。その身体の部分を処理するための方法は、Content-IDのURLが表示されたフィールドで定義されています。例えば、SIP [RFC5368]で複数のリソースを参照する拡張は、参照のために、ヘッダフィールド内のContent-ID URLを置きます。 URIリストを運ぶ身体の一部にこのようなコンテンツIDのURLを指します。別の例では、SDP [RFC5547]でのファイル転送のための拡張子が「ファイルアイコン」SDP属性のContent-IDのURLを配置します。 （典型的には小さい）画像を担持する身体部分にこのContent-ID URLがポイント。
UAs MUST only include forward references in the SIP messages they generate. That is, an element in a SIP message can reference a body part only if the body part appears after the element. Consequently, a given body part can only be referenced by another body part that appears before it or by a header field. Having only forward references allows recipients to process body parts as they parse them. They do not need to parse the remainder of the message in order to process a body part.
UAは前方にのみ、彼らが生成するSIPメッセージ内の参照を含まなければなりません。つまり、SIPメッセージ内の要素は、本体部分が要素の後に表示された場合にのみ、身体部分を参照することができます。したがって、所与の本体部分は、その前またはヘッダフィールドによって表示される他の身体部分によって参照することができます。唯一の前方参照を持つことは、彼らはそれらを解析すると、受信者は、体の部分を処理することができます。彼らは、身体の部分を処理するために、メッセージの残りの部分を解析する必要はありません。
It was considered to only allow (forward) references among body parts that belonged to the same 'multipart/related' [RFC2387] wrapper. However, it was finally decided that this extra constraint was not necessary.
これは、同じ「マルチパート/関連」[RFC2387]ラッパーに属し本体部品間のみ許可（フォワード）参照と考えられました。しかし、それは最終的に、この余分な制約が必要ではなかったと判断されました。
In order to process a message body or a body part, a UA needs to know whether a SIP header field or another body part contains a reference to the message body or body part (e.g., a Content-ID URL pointing to it). If the body part is not referenced in any way (e.g., there are no header fields or other body parts with a Content-ID URL pointing to it), the UA processes the body part as indicated by its disposition type and the context in which the body part was received.
メッセージ本文または身体部分を処理するために、UAは、SIPヘッダフィールド又は他の身体部分がメッセージボディまたは身体部分（例えば、コンテンツID URLは、それを指す）への参照を含むかどうかを知る必要があります。本体部は、どのような方法で参照されていない場合（例えば、コンテンツID URLは、それを指すとはヘッダフィールド又は他の身体部分が存在しない）、その気質タイプとコンテキストによって示されるように、UAは、本体部分を処理するに体の一部が受信されました。
If the SIP message contains a reference to the body part, the UA processes the body part according to the reference. If the SIP message contains more than one reference to the body part (e.g., two header fields contain Content-ID URLs pointing to the body part), the UA processes the body part as many times as references are.
SIPメッセージは、本体部分への参照が含まれている場合、UAは、基準に従って身体部分を処理します。 SIPメッセージは、本体部に対して複数の参照が含まれている場合（例えば、2つのヘッダフィールドは、本体部分を指すのContent-IDのURLを含む）、UAは、参照があるように、多くの倍の身体部分を処理します。
Note that, following the rules in [RFC3204], if a UA does not understand a body part whose handling is optional, the UA ignores it. Also note that the content indirection mechanism in SIP [RFC4483] allows UAs to point to external bodies. Therefore, a UA receiving a SIP message that uses content indirection could need to fetch a body part (e.g., using HTTP [RFC2616]) in order to process it.
UAは、その取扱いオプションである身体の部分を理解していない場合なお、[RFC3204]の規則以下、UAはそれを無視します。また、SIP [RFC4483]におけるコンテンツ間接メカニズムは、UAが外部体を指すことを可能にすることに注意してください。したがって、身体部分をフェッチする必要がある可能性がコンテンツ間接参照を使用するSIPメッセージを受信するUA（例えば、HTTP [RFC2616]を使用して）、それを処理するために。
Per the rules in Section 9.3, if a SIP message contains a reference to a body part, the UA processes the body part according to the reference. Since the reference provides the context in which the body part needs to be processed, the disposition type of the body part is irrelevant. However, a UA that missed a reference to a body part (e.g., because the reference was in a header field the UA did not support) would attempt to process the body part according to its disposition type alone. To keep this from happening, we define a new disposition type for the Content-Disposition header field: by-reference.
SIPメッセージは、本体部分への参照が含まれている場合、セクション9.3の規則あたり、UAは、基準に従って身体部分を処理します。基準身体部分を処理する必要のあるコンテキストを提供するので、身体部分の配置タイプは無関係です。しかしながら、身体部分への参照を逃したUA（例えば、基準UAがサポートしていないヘッダフィールドであったため）単独でその配置の種類に応じて身体の部分を処理しようとします。バイ参照：起きてからこれを維持するために、我々はコンテンツ-Dispositionヘッダーフィールドのための新たな処分タイプを定義します。
A body part whose disposition type is 'by-reference' needs to be handled according to a reference to the body part that is located in the same SIP message as the body part (given that SIP only allows forward references, the reference will appear in the same SIP message before the body part). A recipient of a body part whose disposition type is 'by-reference' that cannot find any reference to the body part (e.g., the reference was in a header field the recipient does not support and, thus, did not process) MUST NOT process the body part. Consequently, if the handling of the body part was required, the UA needs to report an error.
その気質型のボディ部分は「によって参照」、基準に表示されるSIPだけ前方参照を可能にすることを考えると、本体部分（同じSIPメッセージ内に配置された本体部を基準に従って処理する必要があります本体部の前に同じSIPメッセージ）。身体部分への参照を見つけることができません「によって参照」気質タイプである身体部分の受信者（例えば、基準は、受信者がサポートしていないと、このようにして、処理しなかったヘッダフィールドにあった）プロセスNOT MUST体の一部。身体の部分の処理が必要となった場合には結果的に、UAはエラーを報告する必要があります。
Note that extensions that predate this specification use references to body parts whose disposition type is not 'by-reference'. Those extensions use option-tags to make sure the recipient understands the whole extension and, thus, cannot miss the reference and attempt to process the body part according to its disposition type alone.
その気質型「によって参照」ではない体の部分には、この仕様書の使用の参照に先行拡張することに注意してください。これらの拡張機能は、受信者は、このように、全体の拡張を理解し、確認するために、参照を見逃すことはできないし、一人でその処分の種類に応じて身体の一部を処理しようとオプション・タグを使用します。
These guidelines are intended for authors of SIP extensions that involve, in some way, message bodies or body parts. These guidelines discuss aspects that authors of such extensions need to consider when designing them.
これらのガイドラインは、何らかの方法で、メッセージ本文や体の部分を伴うSIPの拡張機能の作者のために意図されています。これらのガイドラインは、このような拡張の作者がそれらを設計する際に考慮する必要がある側面を議論します。
This specification mandates support for 'multipart/mixed' and 'multipart/alternative'. At present, there are no SIP extensions that use different 'multipart' subtypes such as parallel [RFC2046] or digest [RFC2046]. If such extensions were to be defined in the future, their authors would need to make sure (e.g., by using an option-tag or by other means) that entities receiving those 'multipart' subtypes were able to process them. As stated earlier, UAs treat unknown 'multipart' subtypes as 'multipart/mixed'.
この仕様の義務は「multipart / mixedの」と「マルチパート/代替」のサポート。現在のところ、このような並列[RFC2046]のような異なる「マルチパート」のサブタイプを使用するか、[RFC2046]をダイジェストないSIP拡張機能はありません。そのような拡張は、将来的に定義されていた場合は、その作者はそれらの「マルチパート」のサブタイプを受信エンティティがそれらを処理することができたこと（例えば、オプションタグを使用するか、他の手段によって）ことを確認する必要があります。先に述べたように、UAは「multipart / mixedの」と、未知の「マルチパート」のサブタイプを扱います。
Authors of SIP extensions making use of 'multipart/related' bodies have to explicitly address the handling of the disposition types of the body parts within the 'multipart/related' body. Authors wishing to make use of 'multipart/related' bodies should keep in mind that UAs that do not understand 'multipart/related' will treat it as 'multipart/mixed'. If such treatment by a recipient is not acceptable for a particular extension, the authors of such extension would need to make sure (e.g., by using an option-tag or by other means) that entities receiving the 'multipart/related' body were able to correctly process them.
「マルチパート/関連の体を利用したSIPの拡張機能の作成者は、明示的に「マルチパート/関連の体の中に身体のパーツの配置タイプの取り扱いに対処する必要があります。 「マルチパート/関連の体を利用することを希望する著者は、理解していないUAは「マルチパートが/関連」「はmultipart / mixed」としてそれを扱うことを覚えておいてください。受信者がこのような治療は、特定の拡張のために許容できない場合は、そのような拡張の作者は、「マルチパート/関連の体を受信エンティティができたことを（例えば、オプションタグを使用するか、他の手段によって）ことを確認する必要がありますそれらを正しく処理します。
As stated earlier, SIP extensions can also include 'multipart' MIME bodies in responses. Hence, a response can be extremely complex and the UAC receiving the response might not be able to process it correctly. Because UACs receiving a response cannot report errors to the UAS that generated the response (i.e., error responses can only be generated for requests), authors of SIP extensions need to make sure that requests clearly indicate (e.g., by using an option-tag or by other means) the capabilities of the UAC so that UASs can decide what to include in their responses.
先に述べたように、SIPの拡張も応答で「マルチパート」MIMEボディを含めることができます。したがって、応答が非常に複雑にすることができ、応答を受け取るUACは、それを正しく処理できない場合があります。求めるUACは（例えば、オプションタグを使用することにより、SIPの拡張機能の作者が要求を明確に示していることを確認する必要があります（つまり、エラー応答が要求だけのために生成することができます）応答を生成UASにエラーを報告することはできません応答を受信するのでかUACの機能）他の手段でのUASは、その応答に含めるかを決めることができるように。
This document specifies how SIP entities handle message bodies. [RFC3261] discusses what type of information is encoded in SIP message bodies and how SIP entities can protect that information. In addition to the hop-by-hop security SIP can provide, SIP can also secure information in an end-to-end fashion. SIP message bodies can be end-to-end encrypted and integrity protected using S/MIME [RFC3851], as described in [RFC3261].
この文書では、SIPエンティティは、メッセージ本文をどのように処理するかを指定します。 [RFC3261]は、SIPメッセージボディとどのSIPエンティティその情報を保護することができるで符号化される情報の種類について説明します。 SIPが提供するホップバイホップセキュリティに加えて、SIPは、エンドツーエンド方式で情報を確保することができます。 SIPメッセージボディには、[RFC3261]に記載されているように、暗号化および完全性は、S / MIME [RFC3851]を使用して保護されたエンドツーエンドであってもよいです。
This document contains two actions that have been completed by IANA.
この文書は、IANAによって完成された2つのアクションが含まれています。
This document defines a new Content-Disposition header field disposition type (by-reference) Section 9.4. This value has been registered in the IANA registry for Mail Content Disposition Values with the following description:
この文書は、新しいコンテンツの廃棄ヘッダーフィールドの配置タイプ（参照による）セクション9.4に規定しています。この値は、以下の説明でメールコンテンツ配置値のためのIANAレジストリに登録されています。
by-reference The body needs to be handled according to a
reference to the body that is located in
the same SIP message as the body.
References to this specification, to [RFC3204], and to [RFC3459] have been added to the entry for the Content-Disposition 'handling' parameter in the Header Field Parameters and Parameter Values registry. The following is the resulting entry.
この仕様書に、[RFC3204]、および[RFC3459]への参照がヘッダーフィールドパラメータとパラメータ値レジストリ内のContent-処分「取扱」パラメータのためのエントリに追加されました。以下は、得られたエントリです。
Predefined
Header Field Parameter Name Values Reference
------------------- --------------- --------- -------------------
Content-Disposition handling Yes [RFC3204] [RFC3261]
[RFC3459] [RFC5621]
The ideas in this document were originally discussed with Paul Kyzivat. Christer Holmberg, Francois Audet, Dan Wing, Adam Roach, Keith Drage, and Dale Worley provided comments on it. Dave Crocker performed a thorough review on the whole document.
この文書のアイデアはもともとポールKyzivatで議論されました。クリステルHolmbergの、フランソワAudet、ダン・ウィング、アダムローチ、キース糖剤、及びデールウォーリーはそれにコメントを提供しました。デイブ・クロッカーは、文書全体の徹底的な見直しを行いました。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、ドルナー、S.、およびK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、RFC 2183、1997年8月。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2387]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、RFC 2387、1998年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2392、1998年8月。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[RFC3204] Zimmerer、E.、ピーターソン、J.、Vemuri、A.、オング、L.、Audet、F.、ワトソン、M.、およびM. Zonoun、 "ISUPとQSIGオブジェクトのMIMEメディアタイプ"、RFC 3204、2001年12月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[RFC3459]バーガー、E.、 "重要なコンテンツ多目的インターネットメール拡張（MIME）パラメータ"、RFC 3459、2003年1月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[RFC3959] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[RFC3959]キャマリロ、G.、RFC 3959 "セッション開始プロトコル（SIP）のための初期セッション処分タイプ"、2004年12月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483]バーガー、E.、 "セッション開始プロトコル（SIP）におけるコンテンツの間接化の仕組みメッセージ"、RFC 4483、2006年5月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
[RFC4289]解放され、N.とJ. Klensin、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、BCP 13、RFC 4289、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]ローチ、A.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのAのセッション開始プロトコル（SIP）イベント通知拡張"、RFC 4662、2006年8月。
[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, October 2008.
[RFC5368]キャマリロ、G.、ニエミ、A.、Isomaki、M.、ガルシア - マーチン、M.、およびH. Khartabil、RFC 5368 "セッション開始プロトコル（SIP）で複数のリソースを参照すると、" 2008年10月。
[RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", RFC 5547, May 2009.
[RFC5547]ガルシア - マーチン、M.、Isomaki、M.、カマリロ、G.、ロレート、S.、およびP. Kyzivat、 "ファイル転送を可能にするセッション記述プロトコル（SDP）オファー/アンサーメカニズム"、RFC 5547 、2009年5月。
Author's Address
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com