Edit

Page

Page title:

Page body:

>
'''Internet Media Type message/sipfrag'''
- Network Working Group                                          
- Request for Comments: 3420                                   
- Category: Standards Track                                  
- R. Sparks
- dynamicsoft
- November 2002

* 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.

* Copyright Notice

* 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.

[8] この文書は、 message/sipfrag 多目的 Internet メイル拡張 (MIME)
媒体型を登録します。この型は message/sip と似ていますが、完全な
Session 初期化プロトコル (SIP) メッセージであることを要求する代わりに、整形式
SIP メッセージのある部分集合で表現することを認めています。
末端対末端の安全性の用途に用いるのに加えて、 message/sipfrag
は REFER 方式で被参照要求の状態についての情報を伝えるのに使います。

* Table of Contents

[PRE[
   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
]PRE]

* 1. Introduction

> 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.

[9] >>1 で定義された [CODE[message/sip]] [[MIME]]
[[媒体型]]は、完全に[[整形式]]の [[SIP]]
[[メッセージ]]を伝えます。 >>1 の23.4章は [CODE[message/sip]]
を [[S/MIME]] 
と一緒に使って末端対末端安全性を向上させる方法を説明しています。
この章の概念は、 SIP メッセージの部分集合について SIP 
[[実体]]が断言することを認めるように拡張出来ます
(例えば >>6 で説明されているように)。この文書で定義する
[CODE[message/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.

[10] SIP メッセージの部分集合は >>5 で定義された [CODE[REFER]] 
方式でも被参照要求の状態を伝えるのに使います。 SIP
メッセージの一部分のみを伝えることを可能にすることで、
privacy や秘密性を侵害し得る情報を削除して保護出来ます。

> 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.

[11] この文書は SIP 
メッセージを複数の破片に分割して分割配送して後で際結合する仕組みは提供'''しません'''。
>>2 で定義された [CODE[message/partial]] 
型がこの問題の解法を提供しています。

> 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].
[12]

* 2. Definition: message/sipfrag

> A valid message/sipfrag part is one that could be obtained by
starting with some valid SIP message and deleting any of the
following:

[13] 妥当な [CODE[message/sipfrag]] [[部分]]は妥当な SIP
メッセージを用意して、次のいずれかを削除することで得られるものです。

- the entire start line
- one or more entire header fields
- the body

- [14] [[開始行]]全体
- [15] 1つ以上の[[実体頭欄]]
- [16] [[本体]]

> 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.

[17] 次に示す増補 Backus-Naur 法 ([[ABNF]]) 規則は >>1
で定義された SIP 文法要素を使って [CODE[message/sipfrag]]
部分を説明したものです。
各要素の拡張はそこで定義された妥当な SIP メッセージの制限の対象になります。

- [18] 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.

[19] [CODE[message/sipfrag]] 部分が本体を含む場合、本体を説明した適切な頭欄
(例えば [CODE[Content-Length]]) を >>1
の7.4章が要求しているように含め'''なければなりません'''し、頭と本体を区切る空行を含め'''なければなりません'''。

* 3. Examples

** 3.1 Valid message/sipfrag parts

> 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.

[20] この章では例の範囲を説明するために垂直線と[[間隔]]を各例の左に入れています。
[CODE[message/sipfrag]] 要素の各行は「|」組の後の最初の文字から始まります。

> The first two examples show that a message/sipfrag part can consist
of only a start line.

[21] 最初の2つの例は [CODE[message/sipfrag]] 
部分が開始行だけで構成できることを示します。

[PRE[
         | INVITE sip:alice@atlanta.com SIP/2.0
>      or
         | SIP/2.0 603 Declined
]PRE]

> The next two show that Subsets of a full SIP message may be
represented.

[22] 次の2つの例は完全な SIP メッセージの部分集合を表現できることを示します。

[PRE[
      | 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
]PRE]

[PRE[
      | SIP/2.0 400 Bad Request
      | Warning: 399 atlanta.com Your Event header field was malformed
]PRE]

> 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].)

[23] [CODE[message/sipfrag]] 部分は開始行を持つ必要がありません。
この例は特定メッセージについて断言するため署名されている部分を示します。

> The next two examples show message/sipfrag parts that contain bodies.

[24] 次の2つの例は [CODE[message/sipfrag]] 
が本体を含められることを示します。

[PRE[
         | Content-Type: text/plain
         | Content-Length: 11
         |
         | Hi There!
]PRE]

* 3.2 Invalid message/sipfrag parts

> 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.

[25] この章では例の範囲を説明するために文字「X」と[[間隔]]を各例の左に入れています。
不正な [CODE[message/sipfrag]] 要素の各行は「X」組の後の最初の文字から始まります。

> The start line, if present, must be complete and valid per [1].

[26] 開始行がある場合、完全で >>1 に照らして妥当でないといけません。

[PRE[
         X INVITE
]PRE]

[PRE[
         X INVITE sip:alice@atlanta.com SIP/1.09
]PRE]

[PRE[
         X SIP/2.0
]PRE]

[PRE[
         X 404 Not Found
]PRE]

> All header fields must be valid per [1].

[27] 全ての頭欄は >>1 に照らして妥当でなければなりません。

[PRE[
         X INVITE sip:alice@atlanta.com SIP/2.0
         X Via: SIP/2.0/UDP ;branch=z9hG4bK29342a
         X To: <>;tag=39234
]PRE]

[PRE[
         X To: sip:alice@atlanta.com
         X From: sip:bob@biloxi.com;tag=1992312
]PRE]

[PRE[
         X Call-ID: this is invalid
]PRE]

[PRE[
         X INVITE sip:alice@atlanta.com SIP/2.0
         X From: <sip:bob@biloxi.com>;tag=z9hG4bK2912;tag=z9hG4bK99234
]PRE]

> 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.

[28] 本体が [CODE[message/sipfrag]] 部分中にある場合、頭は >>1
の7.4章により必須とされており、頭と本体を分ける空行も必要です。

[PRE[
         X MESSAGE sip:alice@atlanta.com SIP/2.0
         X Hi There!
]PRE]

* 4. Discussion

> 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.

[29]  >>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.

[30] 例えば SIP [CODE[REFERER]] 方式は認証された第三者への SIP
要求の結果を報告するためにこれを使います。
しかし、この文書が説明するように、この報告には [CODE[message/sip]]
MIME 部分として SIP 応答全体が含まれるのが望ましいことは稀です。
そうすることは重大な安全上の悪い含みを持ちます。他方で
[CODE[message/sipfrag]] 型は送信者にどの情報が開示されるかを選択することが出来ます。
更に、完全な SIP 
メッセージでは必要とされる情報でそのメッセージの説明には適当でないものをメッセージ長の削減のために省略できます。
例えば、 [CODE[REFER]] に対応する SIP 要素で「私は 400 悪しき要求をこの
[CODE[Warning]] 頭欄と共に受け取りました」と言うことが、完全な SIP
メッセージで必須である Via, To, From, Call-ID, CSeq, Content-Length
各頭欄を含めること無しに出来ます。

> 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.

[31] >>1 の23章で議論されているメッセージ保護の仕組みは SIP
メッセージ全体が保護されることを想定しています。しかし転送の過程で変更される必要がある頭欄が完全な
SIP メッセージには幾つかあります。 >>1 
はそうした変更をどう調べてどう無視するかを議論しています。
この考え方は >>6 で洗練されていて、メッセージ全体の一部の保護を可能にしています。
これによって転送において正当に変更され得るメッセージの部分を無視することに要する余計な作業とエラーの可能性を避けることが出来ます。
この文書は完全な頭 (hop-by-hop 転送特有情報を含む。)
が利用可能になる以前に SIP
メッセージ頭の適切な部分について暗号断言を構築することも説明しています。

* 5. IANA Considerations

> The message/sipfrag media type is defined by the following
information:

[32] [CODE[message/sipfrag]] 媒体型は次の情報のように定義します。

[PRE[
   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
[33]
:媒体型名: [CODE[message]]
:媒体亜型名: [CODE[sipfrag]]
:必須パラメーター: なし
;省略可能パラメーター: [CODE[version]]  [CODE[Version]]: 囲まれたメッセージの [CODE[SIP-VERSION]] 番号 (例えば [CODE(ABNF)["2.0"]])。存在しない場合版の既定値は [CODE(ABNF)["2.0"]]。
:符号化方式: SIP メッセージは8ビット頭及び省略可能なバイナリ MIME データ物体で構成されます。通常の場合は SIP メッセージはバイナリ転送路上で転送しますから、特別な符号化は必要ありません。
:安全性に関して: 下記参照。
]PRE]

* 6. Security Considerations

> 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].

[34] [CODE[message/sipfrag]] mime 部分は繊細な情報や受信者が処理決定に使う情報を含むかもしれません。
転送の過程で情報を公開したり修正したりすることが害になる時は、 >>1
の23章で説明されている S/MIME とその文書の26章で説明されている制限及び
>>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.

[35] SIP メッセージの頭欄の部分集合を表現するのに [CODE[message/sipfrag]]
を使う応用は、記録・再生される [CODE[messag/sipfrag]]
部分を含めるのを熟慮し、危険を和らげるために十分な情報を含めなければなりません。
[CODE[message/sipfrag]] を使用する SIP 
拡張はすべて、その特定の用法に固有の再生及び切り取り・貼り付けの脅威を説明し'''なければなりません'''。
例えば、 >>6 は SIP メッセージが 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.

[2]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.

[3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

* Non-Normative References

[5]  Sparks, R., "The SIP Refer Method", Work in Progress.

[6]  Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", Work in
Progress.

* Author's Address

[PRE[
   Robert J. Sparks
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024
]PRE]

EMail: rsparks@dynamicsoft.com

[INS[

[36] 注: 原文の著作権声明の全文及び訳文については、 [[RFCのライセンス]]を参照。
]INS]

* Acknowledgement

> Funding for the RFC Editor function is currently provided by the
Internet Society.

* License

[[RFCのライセンス]]。

* メモ

[37]
[CITE[RFC ERRATA]] 
<http://www.rfc-editor.org/cgi-bin/errata.pl#rfc3420>

原文の頁見出しの文字の欠落が訂正されています。

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)