Network Working Group R. Sparks
Request for Comments: 3420 dynamicsoft
Category: Standards Track November 2002
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.
版权所有（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.
本文档注册了message/sipfrag多用途Internet邮件扩展（MIME）媒体类型。这种类型类似于message/sip，但允许表示格式良好的会话启动协议（sip）消息的某些子集，而不需要完整的sip消息。除了端到端的安全性使用之外，message/sipfrag还与refere方法一起使用，以传递有关被引用请求的状态的信息。
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
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]中定义的message/sip MIME媒体类型包含完整的格式良好的sip消息。[1]的第23.4节描述了将消息/sip与S/MIME结合使用以增强端到端安全性。该部分中的概念可以扩展，以允许SIP实体对SIP消息的子集进行断言（例如，如[6]中所述）。本文档中定义的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.
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“推荐”、“可”和“可选”应按照[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.
以下扩展的Backus Naur Form（ABNF）[3]规则描述了使用[1]中定义的SIP语法元素的消息/sipfrag部分。任何元素的扩展都受到其中定义的有效SIP消息的限制。
sipfrag = [ start-line ]
*message-header
[ CRLF [ message-body ] ]
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.
本节使用竖条和每个示例左侧的空格来说明示例的范围。message/sipfrag元素的每一行都以“|”对后的第一个字符开头。
The first two examples show that a message/sipfrag part can consist of only a start line.
前两个示例表明，消息/sipfrag部分只能由起始行组成。
| INVITE sip:alice@atlanta.com SIP/2.0 or | SIP/2.0 603 Declined
|邀请sip：alice@atlanta.comSIP/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
| 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
| 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.
下面两个示例显示了包含主体的message/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
| 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!
| 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 INVITE 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 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 To: sip:alice@atlanta.com
X From: sip:bob@biloxi.com;tag=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
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 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 REFER方法[5]使用该方法向授权的第三方报告SIP请求的结果。然而，正如该文档所详述的，很少希望将整个SIP响应消息作为消息/SIP MIME部分包含在该报告中。这样做会对安全产生重大的负面影响。另一方面，message/sipfrag类型允许发送者选择公开哪些信息。此外，它允许省略与该消息的描述无关的完整SIP消息中所需的信息，从而减小消息大小。例如，这允许一个SIP元素响应一个引用，比如说“我收到了一个400错误的请求，带有这个警告头字段”，而不必在完整的SIP消息中包含必须包含的Via、to、From、Call ID、CSeq和内容长度头字段。
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消息由8位报头（可选）和二进制MIME数据对象组成。因此，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]第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.
使用消息/SIPRAFG来表示来自SIP消息的报头字段的子集必须考虑消息/SIPRAG部分被捕获和重放的影响，并包含足够的信息来降低风险。任何使用message/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] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 32652002年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）第二部分：媒体类型”，RFC 20461996年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参考方法”，正在进行中。
[6] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress.
[6] Peterson，J.，“会话启动协议（SIP）中身份验证管理的增强”，正在进行中。
Author's Address
作者地址
Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
Robert J.Sparks dynamicsoft 5100田纳西州普莱诺市坦尼生大道1200号套房，邮编75024
EMail: rsparks@dynamicsoft.com
EMail: 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编辑功能的资金目前由互联网协会提供。