[要約] RFC 3420は、メディアタイプmessage/sipfragの定義と使用方法に関するものです。このRFCの目的は、SIP（Session Initiation Protocol）フラグメントメッセージの表現と処理を標準化することです。
Network Working Group R. Sparks
Request for Comments: 3420 dynamicsoft
Category: Standards Track November 2002
Internet Media Type message/sipfrag
インターネットメディアタイプメッセージ/SIPFRAG
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) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request.
このドキュメントは、メッセージ/SIPFRAG多目的インターネットメールエクステンション（MIME）メディアタイプを登録します。このタイプはメッセージ/SIPに似ていますが、完全なSIPメッセージを必要とする代わりに、適切に形成されたセッション開始プロトコル（SIP）メッセージの特定のサブセットを表現できます。エンドツーエンドのセキュリティの使用に加えて、メッセージ/SIPFRAGは参照方法とともに使用され、参照されるリクエストのステータスに関する情報を伝えます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition: message/sipfrag . . . . . . . . . . . . . . . . . 2
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Valid message/sipfrag parts . . . . . . . . . . . . . . . 3
3.2 Invalid message/sipfrag parts . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
Normative References . . . . . . . . . . . . . . . . . . . . . 7
Non-Normative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
The message/sip MIME media type defined in [1] carries an entire well formed SIP message. Section 23.4 of [1] describes the use of message/sip in concert with S/MIME to enhance end-to-end security. The concepts in that section can be extended to allow SIP entities to make assertions about a subset of a SIP message (for example, as described in [6]). The message/sipfrag type defined in this document is used to represent this subset.
[1]で定義されているメッセージ/SIP Mimeメディアタイプには、よく形成されたSIPメッセージ全体が含まれています。[1]のセクション23.4では、s/mimeと協調してメッセージ/SIPの使用について、エンドツーエンドのセキュリティを強化します。そのセクションの概念を拡張して、SIPエンティティがSIPメッセージのサブセットについてアサーションを作成できるようにすることができます（たとえば、[6]で説明されているように）。このドキュメントで定義されているメッセージ/SIPFRAGタイプは、このサブセットを表すために使用されます。
A subset of a SIP message is also used by the REFER method defined in [5] to carry the status of referenced requests. Allowing only a portion of a SIP message to be carried allows information that could compromise privacy and confidentiality to be protected by removal.
SIPメッセージのサブセットは、参照されるリクエストのステータスを運ぶために[5]で定義された参照メソッドによっても使用されます。SIPメッセージの一部のみを実施できるようにすることで、プライバシーと機密性を損なう可能性のある情報が削除によって保護されます。
This document does NOT provide a mechanism to segment a SIP message into multiple pieces for separate transport and later reassemble. The message/partial type defined in [2] provides a solution for that problem.
このドキュメントは、SIPメッセージを個別のトランスポートとその後の再組み立てのために複数の部分にセグメント化するメカニズムを提供しません。[2]で定義されているメッセージ/部分タイプは、その問題の解決策を提供します。
The key words "MUST", "MUST NOT", REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMEND", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4].
「必須」、「必須」、「必須」、「shall」、「shall "、" ingle "、" with "not"、 "beccound"、 "may"、および「optional」は、[4]で説明されているように解釈されます。
A valid message/sipfrag part is one that could be obtained by starting with some valid SIP message and deleting any of the following:
有効なメッセージ/SIPFRAGパーツは、有効なSIPメッセージから開始し、次のいずれかを削除することで取得できるものです。
o the entire start line
o スタートライン全体
o one or more entire header fields
o 1つ以上のヘッダーフィールド
o the body
o 体
The following Augmented Backus-Naur Form (ABNF) [3] rule describes a message/sipfrag part using the SIP grammar elements defined in [1]. The expansion of any element is subject to the restrictions on valid SIP messages defined there.
次の拡張されたバックスノーフォーム（ABNF）[3]ルールは、[1]で定義されているSIP文法要素を使用したメッセージ/SIPFRAGパーツを説明しています。要素の拡張は、そこに定義されている有効なSIPメッセージの制限の対象となります。
sipfrag = [ start-line ]
*message-header
[ CRLF [ message-body ] ]
If the message/sipfrag part contains a body, it MUST also contain the appropriate header fields describing that body (such as Content-Length) as required by Section 7.4 of [1] and the null-line separating the header from the body.
メッセージ/sipfragの部分に本体が含まれている場合、[1]のセクション7.4で要求されているボディ（コンテンツ長など）を記述する適切なヘッダーフィールドを含む必要があります。
This section uses a vertical bar and a space to the left of each example to illustrate the example's extent. Each line of the message/sipfrag element begins with the first character after the "|" pair.
このセクションでは、垂直バーと各例の左側のスペースを使用して、例の範囲を示します。メッセージ/sipfrag要素の各行は、「|」の後の最初の文字から始まりますペア。
The first two examples show that a message/sipfrag part can consist of only a start line.
最初の2つの例は、メッセージ/SIPFRAGの部分がスタートラインのみで構成されていることを示しています。
| INVITE sip:alice@atlanta.com SIP/2.0 or | SIP/2.0 603 Declined
|sipを招待：alice@atlanta.com SIP/2.0または|SIP/2.0 603が拒否されました
The next two show that Subsets of a full SIP message may be represented.
次の2つは、完全なSIPメッセージのサブセットを表すことができることを示しています。
| REGISTER sip:atlanta.com SIP/2.0
| To: sip:alice@atlanta.com
| Contact: <sip:alicepc@atlanta.com>;q=0.9,
| <sip:alicemobile@atlanta.com>;q=0.1
| SIP/2.0 400 Bad Request | Warning: 399 atlanta.com Your Event header field was malformed
|SIP/2.0 400悪いリクエスト|警告：399 atlanta.comあなたのイベントヘッダーフィールドは奇形でした
A message/sipfrag part does not have to contain a start line. This example shows a part that might be signed to make assertions about a particular message. (See [6].)
メッセージ/SIPFRAGパーツには、スタートラインを含める必要はありません。この例は、特定のメッセージについて主張するために署名される可能性のある部分を示しています。（[6]を参照。）
| From: Alice <sip:alice@atlanta.com>
| To: Bob <sip:bob@biloxi.com>
| Contact: <sip:alice@pc33.atlanta.com>
| Date: Thu, 21 Feb 2002 13:02:03 GMT
| Call-ID: a84b4c76e66710
| Cseq: 314159 INVITE
The next two examples show message/sipfrag parts that contain bodies.
次の2つの例は、ボディを含むメッセージ/SIPFRAGパーツを示しています。
| SIP/2.0 200 OK
| Content-Type: application/sdp
| Content-Length: 247
|
| v=0
| o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
| s=
| c=IN IP4 host.anywhere.com
| t=0 0
| m=audio 49170 RTP/AVP 0
| a=rtpmap:0 PCMU/8000
| m=video 51372 RTP/AVP 31
| a=rtpmap:31 H261/90000
| m=video 53000 RTP/AVP 32
| a=rtpmap:32 MPV/90000
| Content-Type: text/plain
| Content-Length: 11
|
| Hi There!
This section uses the character "X" followed by a space to the left of each example to illustrate the example's extent. Each line of the invalid message/sipfrag element begins with the first character after the "X " pair.
このセクションでは、キャラクター「x」を使用して、各例の左側にスペースが続き、例の範囲を示します。無効なメッセージ/SIPFRAG要素の各行は、「X」ペアの後の最初の文字から始まります。
The start line, if present, must be complete and valid per [1].
存在する場合は、スタートラインは完全で有効でなければなりません[1]。
X INVITE
x招待
X INVITE sip:alice@atlanta.com SIP/1.09
X招待SIP：alice@atlanta.com SIP/1.09
X SIP/2.0
X SIP/2.0
X 404 Not Found
X 404は見つかりません
All header fields must be valid per [1].
すべてのヘッダーフィールドは、[1]ごとに有効でなければなりません。
X INVITE sip:alice@atlanta.com SIP/2.0
X Via: SIP/2.0/UDP ;branch=z9hG4bK29342a
X To: <>;tag=39234
X To: sip:alice@atlanta.com
X From: sip:bob@biloxi.com;tag=1992312
X Call-ID: this is invalid
X INVITE sip:alice@atlanta.com SIP/2.0
X From: <sip:bob@biloxi.com>;tag=z9hG4bK2912;tag=z9hG4bK99234
If a body is present in the message/sipfrag part, the headers required by Section 7.4 of [1] and the null-line separating the header from the body.
ボディがメッセージ/SIPFRAGパーツに存在する場合、[1]のセクション7.4で必要なヘッダーと、ヘッダーをボディから分離するヌルライン。
X MESSAGE sip:alice@atlanta.com SIP/2.0 X Hi There!
XメッセージSIP：alice@atlanta.com sip/2.0 xこんにちは！
Section 23 of [1], and memos [5] and [6] provide motivation and detailed examples of carrying all or part of a SIP message in a MIME part. Briefly, using this representation along with S/MIME enables protecting and making assertions about portions of a SIP message header. It also enables applications to describe the messaging involved in a SIP transaction using portions of the messages themselves.
[1]のセクション23、およびメモ[5]および[6]は、MIME部分にSIPメッセージのすべてまたは一部を運ぶ動機と詳細な例を提供します。簡単に言えば、S/MIMEとともにこの表現を使用すると、SIPメッセージヘッダーの一部について保護し、主張することができます。また、アプリケーションは、メッセージ自体を使用してSIPトランザクションに伴うメッセージングを記述することができます。
The SIP REFER method [5], for instance, uses this to report the result of a SIP request to an authorized third party. However, as that document details, it is rarely desirable to include the entire SIP response message in this report as a message/sip MIME part. Doing so has significant negative security implications. The message/sipfrag type, on the other hand, allows a sender to select what information is exposed. Further, it allows information required in a full SIP message that is not pertinent to a description of that message to be elided, reducing message size. For instance, this allows a SIP element responding to a REFER to say "I got a 400 Bad Request with this Warning header field" without having to include the Via, To, From, Call-ID, CSeq and Content-Length header fields mandatory in a full SIP message.
たとえば、SIP参照方法[5]は、これを使用して、SIPリクエストの結果を認定された第三者に報告します。ただし、そのドキュメントの詳細として、このレポートにSIP応答メッセージ全体をメッセージ/SIP Mimeパーツとして含めることはめったにありません。そうすることには、重大なセキュリティへの影響があります。一方、メッセージ/SIPFRAGタイプにより、送信者が公開されている情報を選択できます。さらに、そのメッセージの説明に関係のない完全なSIPメッセージで必要な情報が削除され、メッセージサイズが削減されます。たとえば、これにより、via、from、from、from、call-id、cseq、およびコンテンツ長ヘッダーフィールドを必須にすることなく、「この警告ヘッダーフィールドで400の悪いリクエストが得られた」という参照に応答するSIP要素ができます。完全なSIPメッセージで。
The message protection mechanism discussed in Section 23 of [1] assumes an entire SIP message is being protected. However, there are several header fields in a full SIP message that necessarily change during transport. [1] discusses how to inspect and ignore those changes. This idea is refined in [6] to allow protection of a subset of the entire message, avoiding the extra work and potential errors involved in ignoring parts of the message that may legitimately change in transit. That document also describes constructing cryptographic assertions about pertinent subsets of a SIP message header before the full header (including hop-by-hop transport specific information) may be available.
[1]のセクション23で説明したメッセージ保護メカニズムは、SIPメッセージ全体が保護されていると仮定しています。ただし、輸送中に必然的に変更される完全なSIPメッセージには、いくつかのヘッダーフィールドがあります。[1]これらの変更を検査および無視する方法について説明します。このアイデアは[6]で洗練されており、メッセージ全体のサブセットを保護し、輸送が合法的に変化する可能性のあるメッセージの一部を無視することに伴う追加の作業と潜在的なエラーを避けます。また、このドキュメントでは、フルヘッダー（ホップバイホップトランスポート特定の情報を含む）が利用可能になる前に、SIPメッセージヘッダーの関連するサブセットに関する暗号化アサーションの構築についても説明しています。
The message/sipfrag media type is defined by the following information:
メッセージ/SIPFRAGメディアタイプは、次の情報で定義されています。
Media type name: message Media subtype name: sipfrag Required parameters: none Optional parameters: version Version: The SIP-Version number of the enclosed message (e.g., "2.0"). If not present, the version defaults to "2.0". Encoding scheme: SIP messages consist of an 8-bit header optionally followed by a binary MIME data object. As such, SIP messages must be treated as binary. Under normal circumstances SIP messages are transported over binary-capable transports, no special encodings are needed. Security considerations: see below
メディアタイプ名：メッセージメディアサブタイプ名：SIPFRAG要求パラメーター：なしオプションパラメーター：バージョンバージョン：同封のメッセージのSIPバージョン番号（例： "2.0"）。存在しない場合、バージョンはデフォルトで「2.0」になります。エンコーディングスキーム：SIPメッセージは、オプションでバイナリMIMEデータオブジェクトが続く8ビットヘッダーで構成されています。そのため、SIPメッセージはバイナリとして扱う必要があります。通常の状況では、SIPメッセージはバイナリ対応トランスポートを介して輸送され、特別なエンコーディングは必要ありません。セキュリティ上の考慮事項：以下を参照してください
A message/sipfrag mime-part may contain sensitive information or information used to affect processing decisions at the receiver. When exposing that information or modifying it during transport would do harm, its level of protection can be improved using the S/MIME mechanisms described in section 23 of [1], with the limitations described in section 26 of that document, and the mechanisms described in [6].
メッセージ/SIPFRAG MIME-PARTには、受信機の処理決定に影響を与えるために使用される機密情報または情報が含まれている場合があります。その情報を公開したり、輸送中にそれを変更すると、[1]のセクション23で説明されているS/MIMEメカニズムを使用してそのレベルを改善できます。[6]。
Applications using message/sipfrag to represent a subset of the header fields from a SIP message must consider the implications of the message/sipfrag part being captured and replayed and include sufficient information to mitigate risk. Any SIP extension which uses message/sipfrag MUST describe the replay and cut and paste threats unique to its particular usage. For example, [6] discusses how a subset of a SIP message can be used to assert the identity of the entity making a SIP request. The draft details what information must be contained in the subset to bind the assertion to the request.
メッセージ/SIPFRAGを使用して、SIPメッセージからヘッダーフィールドのサブセットを表すアプリケーションは、キャプチャおよび再生されるメッセージ/SIPFRAGパーツの意味を考慮し、リスクを軽減するのに十分な情報を含める必要があります。メッセージ/SIPFRAGを使用するSIP拡張機能は、特定の使用法に固有のリプレイとカットおよび貼り付けの脅威を説明する必要があります。たとえば、[6]は、SIPメッセージのサブセットを使用して、SIPリクエストを作成するエンティティのIDを主張する方法について説明します。ドラフトの詳細は、サブセットにどの情報を含める必要があり、リクエストにアサーションをバインドします。
Normative References
引用文献
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3265, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3265、2002年6月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[2] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Non-Normative References
非規範的な参照
[5] Sparks, R., "The SIP Refer Method", Work in Progress.
[5] Sparks、R。、「SIP refery Method」、進行中の作業。
[6] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress.
[6] ピーターソン、J。、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理のための強化」、進行中の作業。
Author's Address
著者の連絡先
Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
Robert J. Sparks Dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano、TX 75024
EMail: rsparks@dynamicsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。