Network Working Group R. Sparks
Request for Comments: 3420 dynamicsoft
Category: Standards Track November 2002
Internet Media Type message/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.
著作権（C）インターネット協会（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（Multipurpose Internet Mail Extensions）のメディアタイプを登録します。このタイプのメッセージ/ SIPに類似しているが、十分に形成されたセッション開始プロトコル（SIP）メッセージの特定のサブセットではなく、完全なSIPメッセージを必要と表現されることを可能にします。エンドツーエンドにセキュリティが使用に加えて、メッセージ/ sipfragは、参照要求のステータスに関する情報を伝達するREFERメソッドで使用されています。
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メッセージを運びます。セクション23.4 [1]は、エンドツーエンドのセキュリティを強化するためにS / MIMEと協調して、メッセージ/ SIPの使用を記載しています。 （に記載されているように、例えば[6]）はセクションの概念は、SIPエンティティは、SIPメッセージのサブセットに関するアサーションを行うことができるように拡張することができます。この文書で定義されたメッセージ/ 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]で定義されたREFERメソッドによって使用されます。 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].
キーワード "MUST" は、REQUIRED」、 ""、 "SHALL NOT"、 ""、 "SHOULD NOT"、 "このドキュメントでは"、 "MAY"、および "オプション" 勧告すべきものとし、 "てはならない" にしています[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
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のINVITE：alice@atlanta.com SIP / 2.0または| SIP / 2.0 603不承認
The next two show that Subsets of a full SIP message may be represented.
次の二つは、完全な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 REGISTER：atlanta.comのSIP / 2.0を| To：SIP：alice@atlanta.com |連絡先：<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あなたのEventヘッダーフィールドが不正でした
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!
|コンテンツタイプ：テキスト/平野|コンテンツの長さ：11 | |こんにちは！
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 INVITE
X INVITE sip:alice@atlanta.com SIP/1.09
alice@atlanta.com SIP / 1.09：X SIPのINVITE
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へ：SIP：alice@atlanta.comからX：SIP：bob@biloxi.com;タグ= 1992312
X Call-ID: this is invalid
Xコール-ID：これは無効です。
X INVITE sip:alice@atlanta.com SIP/2.0 X From: <sip:bob@biloxi.com>;tag=z9hG4bK2912;tag=z9hG4bK99234
タグ= z9hG4bK2912;タグ= z9hG4bK99234 <bob@biloxi.com SIP：> alice@atlanta.com SIP / 2.0からX：X SIPのINVITE
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!
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要求の結果を報告するためにこれを使用します。しかし、その文書の詳細としては、メッセージ/一口のMIMEの一部として、この報告書では全体のSIP応答メッセージを含めることがまれことが望ましいです。そうすることで有意な負のセキュリティに影響を持っています。メッセージ/ sipfragタイプは、他の一方で、送信者が公開する情報を選択することができます。また、メッセージのサイズを減少させる、省略されるため、そのメッセージの説明に関係ない完全なSIPメッセージに必要な情報を可能にします。例えば、これは、ビアを含めることなく、「私はこのWarningヘッダーフィールドと400不正な要求を得ました」と言ってREFERに応答してSIP要素は、から、には、コールID、のCSeqと必須のContent-Lengthヘッダフィールドを可能に完全な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部分は、受信機での処理の決定に影響を与えるために使用される機密情報または情報を含むことができます。その情報を露出又は害をするだろう輸送中にそれを変更するときに、保護のそのレベルが[1]、そのドキュメントのセクション26に記載の制限、及び機構を説明のセクション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要求を行うエンティティのアイデンティティをアサートするために使用することができる方法について説明します。サブセットに含まれている必要がありどのような情報のドラフトの詳細は、要求にアサーションをバインドします。
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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3265、2002年6月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[2]フリード、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]クロッカー、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
Non-Normative References
非引用規格
[5] Sparks, R., "The SIP Refer Method", Work in Progress.
[5]、進行中の作業 "SIPメソッドを参照してください"、R.スパークス。
[6] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress.
[6]ピーターソン、J.、 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理の強化"、ProgressのWork。
Author's Address
著者のアドレス
Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
ロバートJ.がdynamicsoft 5100テニソンパークウェイスイート1200プラノ、TX 75024スパークス
EMail: rsparks@dynamicsoft.com
メールアドレス：rsparks@dynamicsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。