[要約] RFC 5621は、SIPでのメッセージボディの処理に関するガイドラインです。その目的は、SIPセッションでのメッセージボディの正確な処理と相互運用性を確保することです。
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)
セッション開始プロトコル（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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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でのメッセージ本文の処理は、もともと[RFC3261]で指定されていました。これは、いくつかの領域を説明するために以前の仕様（MIMEなど）に依存していました。このドキュメントには、以前に指定されていなかった領域、またはどの仕様を完了する必要があるかについて、体が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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The following abbreviations are used in this document.
このドキュメントでは、次の略語が使用されています。
UA: User Agent
UA：ユーザーエージェント
UAC: User Agent Client
UAC：ユーザーエージェントクライアント
UAS: User Agent Server
UAS：ユーザーエージェントサーバー
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
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
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
--boundary1
Content-Type: application/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
--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--
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]で指定されているように、メッセージ本文またはボディパーツを復号化できないUASSは、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などのエンコーディングを使用する必要はありません。したがって、UASは、バイナリペイロードを含むSIPのすべてのペイロードに対して、[RFC4289]をエンコードするバイナリ転送[RFC4289]を使用する必要があります。UAが異なるエンコーディングを使用する可能性のある唯一のケースは、異なるエンコードのみを処理するアプリケーション間でアプリケーションデータを転送するときです（例：Base64）。
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].
「マルチパート/ミックス」マイムボディの使用は、SIP拡張機能を構築するための便利なツールです。このような拡張機能の例は、招待状リクエストに位置情報を含めることです。このような招待リクエストは、「MultiPart/Mixed」Mime Type [RFC2046]を使用して、セッションの説明とロケーションオブジェクトの2つの体の部分を運びます。「MultiPart/Mixed」を使用してセッションの説明とレガシー署名オブジェクトを送信する既存の拡張機能の例は、[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]です。「MultiPart/Alternative」内の各身体部分には、同じ情報の代替バージョンが含まれています。
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から新しいセッションの説明プロトコルへの移行は、「MultiPart/Alternative」ボディを使用して実装できます。SIPメッセージ（招待リクエストなど）は、2つのボディパーツを持つ「マルチパート/代替」本体を搭載できます。SDPで書かれたセッション説明と、新しいセッションの説明形式で書かれたセッション説明。レガシー受信者UASは、SDPで記述されたセッションの説明を使用します。新しい受信者UASは、新しい形式で書かれたものを使用します。
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.
ネストされたマイムボディは、SIP拡張機能を構築および結合するためのもう1つの有用なツールです。前の例で拡張機能を使用して、新しいセッションの説明形式をサポートし、招待リクエストにロケーションオブジェクトを含める必要があるUAには、2つのボディパーツを持つ「マルチパート/混合」ボディが含まれます：ロケーションオブジェクトと 'マルチパート/別'。「マルチパート/代替」ボディの部分には、2つのボディ部分があります。SDPで書かれたセッション説明と、新しいセッションの説明形式で書かれたセッション説明。
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 UASは、ネストされた身体の部分を含む「マルチパート」マイムボディの解析をサポートする必要があります。さらに、UASは「MultiPart/ Mixed」および「MultiPart/ Alternative」MIMEタイプをサポートする必要があります。「MultiPart/関連」などの他の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.
デフォルトでは、不明な「マルチパート」サブタイプは「マルチパート/混合」として扱われることに注意してください。また、SIP拡張機能には、応答に「マルチパート」マイムボディも含まれることに注意してください。そのため、UACとUASSの両方が「マルチパート」ボディをサポートする必要があります。
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 UASは、リクエストで「マルチパート」ボディを受け取ったときに415（サポートされていないメディアタイプ）応答を生成します。「マルチパート」ボディを送信するUACは、この仕様よりも前のレガシーSIP UAと通信するときに、このようなエラー応答を受信できます。
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が、受け取ったときにそれらの遺体を単に無視したことが観察されています。これらのUASはエラー応答を返しませんでした。当然のことながら、SIP UASがこのタイプのエラーを報告できないことは、過去に深刻な相互運用性の問題を引き起こしました。
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.
UASは、不必要に、体の処理を受信者にとってより面倒にするため、不必要にネストする身体部分を避ける必要があります。ただし、[RFC2046]は、単一のボディパーツを持つ「マルチパート」メディアタイプは、状況によっては（例えば、テキスト以外のメディアタイプを送信するために）役立つと述べています。いずれにせよ、UASは、ネストされたものを参照する必要がない限り（つまり、ネストされた本体部分のコンテンツIDを使用する）、別の内側に「マルチパート/混合」をネストするべきではありません。さらに、UASは、1つの「マルチパート/代替」を別のものにネストするべきではありません。
Note that UAs receiving unnecessarily nested body parts treat them as if they were not nested.
不必要にネストされた体の部分を受け取ったUASは、それらがネストされていないかのようにそれらを扱うことに注意してください。
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.
「MultiPart/Alternative」内の各身体部分には、同じ情報の代替バージョンが含まれています。体の部分は、最後の部分が情報の最も豊かな表現であるように順序付けられます。「マルチパート/代替」ボディの受信者は、理解している最後の体の部分を選択します。
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]では、これらのオプションの要素は「a」行でエンコードされています。これらのタイプのオプション要素は、体の部分の内部であり、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つの部分の間のマッピングには必ずしも情報の損失がないわけではありません。たとえば、「テキスト/ 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]の処分タイプでは、「マルチパート/代替」ボディのすべてのボディ部分に異なるコンテンツタイプがあることが必要です。したがって、「セッション」と「早期セッション」の処分タイプの場合、UASは「マルチパート/代替」本体に特定のコンテンツタイプを持つ複数のボディパーツを配置してはなりません。つまり、「セッション」と「早期セッション」の場合、「マルチパート/代替」内のボディ部分は、同じ「マルチパート/代替」内の別のボディパーツと同じコンテンツタイプを持つことはできません。
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の複合オブジェクトは、「MultiPART/関連」コンテンツタイプ[RFC2387]を使用して表されます。特定の「マルチパート/関連」ボディ内の体の部分はすべて複合オブジェクトの一部であり、そのように処理されます。最初に処理する必要がある「マルチパート/関連」本体内の身体部分は、「ルート」本体部分と呼ばれます。「マルチパート/関連」ボディのルートボディ部分は、コンテンツタイプのヘッダーフィールドパラメーターであり、ルート本体の部分を指すコンテンツID URLを含む「start」パラメーターによって識別されます。開始パラメーターが存在しない場合、ルートボディの部分は、デフォルトでは、「マルチパート/関連」の最初のボディ部分です。複合オブジェクトの例は、画像を含むWebページです。HTMLボディの部分がルートになります。残りの体の部分には画像が含まれます。[MultiPart/関連]を使用した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が「マルチパート/関連」ボディを処理し、身体をその中の身体部分の処分タイプを無視する複合物体として処理します。個々の身体部分の気質タイプを無視すると、「マルチパート/関連」が当初指定されていたコンテキストでは理にかなっています。たとえば、Webページの例では、画像がルートHTMLファイルで示されているように表示されるため、画像の暗黙の処分タイプは「インライン」になります。ただし、SIPでは、「マルチパート/関連」内の個々の身体部分の処分タイプが重要な役割を果たし、したがって、UAが「マルチパート/関連」を処理することで考慮する必要があります。「マルチパート/関連」ボディに同じ処分タイプを使用するさまざまなSIP拡張機能は、「マルチパート/関連」内の個々の身体部分の処分タイプによって区別できます。したがって、SIP UAS「マルチパート/関連」のボディを特定の処分タイプで処理する必要があります。SIP拡張に従って、「マルチパート/関連」の処分タイプを使用するSIP拡張に従って、その中の身体の部分を処理する必要があります。
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.
「マルチパート/関連」を理解していないUAは、「マルチパート/混合」ボディとして「マルチパート/関連」ボディを扱うことに注意してください。これらのUASは、特定のボディを複合オブジェクトとして処理することはできません。代わりに、彼らは、各体の部分が互いに独立しているかのように、彼らの処分の種類に従って身体の部分を処理します。
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'.
[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: 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（ユーザーエージェントサーバー）が、取り扱いが必要なボディパートでリクエストを拒否する必要がある2つの状況を特定します。
1. if it has an unknown content type.
1. 不明なコンテンツタイプがある場合。
2. if it has an unknown disposition type.
2. 不明な処分タイプがある場合。
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（サポートされていないメディアタイプ）応答に受け入れヘッダーフィールドを追加できます。それにもかかわらず、UACの気質タイプを理解していない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は、招待状と更新リクエストとその応答の身体部分の「セッション」処分タイプをサポートできます。ただし、同じUAがメッセージリクエストで「セッション」処分タイプをサポートしません。
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はメッセージリクエストで「テキスト/プレーン」および「テキスト/HTML」ボディパーツの「レンダリング」処分タイプをサポートできます。さらに、UAは、招待状と更新リクエストとその応答で「アプリケーション/SDP」ボディパーツの「セッション」処分タイプをサポートできます。ただし、UAは、異なるコンテキストで、UAが「レンダリング」処分タイプ、「アプリケーションタイプ」、「アプリケーション/SDP」ボディパーツの「アプリケーション/SDP」ボディパーツの「レンダリング」処分タイプをサポートできない場合があります。/SDP 'コンテンツタイプ、およびメッセージメソッド。
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]のインスタントメッセージングの拡張は、メッセージメソッド、「レンダリング」処分タイプ、および「テキスト/プレーン」コンテンツタイプのサポートを義務付けています。
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).
したがって、特定のコンテキスト内の特定の処分タイプのサポートは、通常、サポートされているヘッダーフィールドまたは要求ヘッダーフィールドで特定のメソッドまたはオプションタグを使用することにより通知されます。コンテキスト内の特定の処分タイプのサポートが義務付けられている場合、デフォルトのコンテンツタイプのサポートも義務付けられています（たとえば、「アプリケーション/SDP」コンテンツタイプをサポートするために招待リクエストの「セッション」処分タイプをサポートする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.
前述のように、「処理」コンテンツ拡張パラメーターは、「必須」または「オプション」の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は「マルチパート/混合」本体の「処理」パラメーターを「必要」に設定する必要があります。それ以外の場合、UAは「オプション」に設定する必要があります。「MultiPart/Mixed」ボディ内のトップレベルのボディ部分の「処理」パラメーターは、「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.
以前のルールによると、ハンドリングがオプションである「マルチパート/混合」ボディには、ハンドリングが必要な身体の部分が含まれています。そのような場合、受信機は、受信者がオプションの「マルチパート/混合」ボディを処理することを決定した場合にのみ、その取り扱いが必要な本体部分を処理する必要があります。
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.
また、以前のルールに従って、ハンドリングが必要な「マルチパート/混合」ボディには、ハンドリングがオプションである身体部分のみを含めることができます。そのような場合、受信者は体全体を処理する必要がありますが、それを処理する場合、レシーバーは（ローカルポリシーに基づいて）身体の部分を処理しないことを決定できます。
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'.
「処理」パラメーターは、コンテンツ拡張パラメーターです。したがって、このパラメーターを設定するには、「マルチパート/混合」本体を処分タイプに提供する必要があります。[RFC3261]によると、「アプリケーション/SDP」のデフォルトの処分タイプは「セッション」であり、他のボディは「レンダリング」です。UASは、「マルチパート/混合」ボディに気質タイプの「レンダリング」を割り当てる必要があります。
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.
受信機は、「マルチパート/代替」本体の処理パラメーターに基づいてボディ部分を処理します。レシーバーは、身体部分のハンドリングパラメーターを無視します。そのため、それらを「オプション」に設定することは、「必須」レベルではなく「必須」レベルにあります。その価値は無関係です。
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.
その結果、リクエストで使用されているすべてのコンテンツタイプを含む受け入れヘッダーフィールドを使用して、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が、SIPメッセージの他の部分に従って身体部分の処理方法と互換性がないボディパーツのリクエストを受信した場合（たとえば、Content-ID URLを備えた参照ヘッダーフィールド気質タイプが「セッション」である身体部分を指して、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.
Content-ID URLにより、身体部分への参照を作成できます。特定のコンテンツID URL [RFC2392]は、ヘッダーフィールドまたは身体部分（例えば、SDP属性）内に表示される可能性があり、特定の身体部分を指します。その身体部分を処理する方法は、コンテンツID URLが表示されるフィールドによって定義されます。たとえば、SIP [RFC5368]の複数のリソースを参照する拡張機能は、紹介ヘッダーフィールドにコンテンツID URLを配置します。このようなコンテンツID URLは、URIリストを搭載した身体部分を指しています。別の例では、SDP [RFC5547]のファイル転送の拡張機能は、 'file-icon' SDP属性にコンテンツID URLを配置します。このコンテンツ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.
UASには、生成する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つのヘッダーフィールドには、体の部分を指すコンテンツ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.
[RFC3204]のルールに従って、UAがハンドリングがオプションである身体部分を理解していない場合、UAはそれを無視します。また、SIP [RFC4483]のコンテンツ間接メカニズムにより、UASが外部体を指すことができることに注意してください。したがって、コンテンツの間接を使用する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.
セクション9.3のルールごとに、SIPメッセージに身体部分への参照が含まれている場合、UAは参照に従って身体部分を処理します。参照は、身体部分を処理する必要があるコンテキストを提供するため、身体部分の気質タイプは無関係です。ただし、身体部分への参照を逃したUA（たとえば、参照がヘッダーフィールドにあるため、UAがサポートしていなかったため）は、その気質タイプのみに従って身体の部分を処理しようとします。これを発生させるために、コンテンツディスポジションヘッダーフィールドの新しい気質タイプ：by-referenceを定義します。
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メッセージ）。身体部分への参照を見つけることができない気質のタイプが「バイリファレンス」である身体部分の受信者（たとえば、参照は、受信者がサポートしていないため、処理してはならないヘッダーフィールドにありました）体の部分。その結果、身体部分の処理が必要な場合、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」および「MultiPart/Alternative」のサポートが義務付けられています。現在、平行[RFC2046]やダイジェスト[RFC2046]など、異なる「マルチパート」サブタイプを使用するSIP拡張機能はありません。このような拡張機能が将来定義された場合、著者は、それらの「マルチパート」サブタイプを受け取るエンティティがそれらを処理できることを確認する必要があります（たとえば、オプションタグまたは他の手段で）。前述のように、UASは不明な「マルチパート」サブタイプを「マルチパート/混合」として扱います。
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拡張機能の著者は、「マルチパート/関連」ボディ内の身体部分の処分タイプの処理を明示的に対処する必要があります。「マルチパート/関連」の本体を使用したい著者は、「マルチパート/関連」を理解していないUASが「マルチパート/ミックス」として扱うことに留意する必要があります。受信者によるそのような治療が特定の拡張機能に受け入れられない場合、そのような拡張の著者は、「マルチパート/関連」ボディを受け取るエンティティが可能であることを確認する必要があります（たとえば、オプションタグまたは他の手段で）それらを正しく処理します。
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はそれを正しく処理できない可能性があります。応答を受信するUACSは、応答を生成したUASにエラーを報告できないため（つまり、リクエストに対してエラー応答のみを生成できます）、SIP拡張機能の著者は、リクエストが明確に示すことを確認する必要があります（たとえば、オプションタグまたは使用して他の手段で）UACの機能を、UASSが応答に何を含めるかを決定できるように。
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.
by-referenceボディと同じSIPメッセージにある身体への参照に従って、身体を処理する必要があります。
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]への参照は、ヘッダーフィールドパラメーターとパラメーター値レジストリのコンテンツディスポジション「処理」パラメーターのエントリに追加されました。結果のエントリは次のとおりです。
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.
この文書のアイデアは、もともとポール・キジバトと議論されました。Christer Holmberg、Francois Audet、Dan Wing、Adam Roach、Keith Drage、およびDale Worleyはコメントを提供しました。Dave Crockerは、ドキュメント全体について徹底的なレビューを実行しました。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Dorner、S。、およびK. Moore、「インターネットメッセージのプレゼンテーション情報の通信：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年8月。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2387]レビンソン、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2387、1998年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E。、「コンテンツIDおよびメッセージ-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.、Peterson、J.、Vemuri、A.、Ong、L.、Audet、F.、Watson、M。、およびM. Zonoun、「ISUPおよびQSIGオブジェクトのMIMEメディアタイプ」、RFC3204、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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。、「Secure/Multipurpose Internet Mail Extensions（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] Camarillo、G。、「セッション開始プロトコル（SIP）の初期セッション処分タイプ」、RFC 3959、2004年12月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483] Burger、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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] Campbell、B.、Rosenberg、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] Freed、N。およびJ. Klensin、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、BCP 13、RFC 4289、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Roach、A.、Campbell、B。、およびJ. Rosenberg、「リソースリストのセッション開始プロトコル（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] Camarillo、G.、Niemi、A.、Isomaki、M.、Garcia-Martin、M.、およびH. Khartabil、「セッション開始プロトコル（SIP）の複数のリソースを指す」、RFC 5368、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] Garcia-Martin、M.、Isomaki、M.、Camarillo、G.、Loreto、S。、およびP. Kyzivat、「セッション説明プロトコル（SDP）ファイル転送を有効にするためのオファー/回答メカニズム」、RFC 5547、2009年5月。
Author's Address
著者の連絡先
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com