summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3420.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3420.txt')
-rw-r--r--doc/rfc/rfc3420.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3420.txt b/doc/rfc/rfc3420.txt
new file mode 100644
index 0000000..c6e3e05
--- /dev/null
+++ b/doc/rfc/rfc3420.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+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.
+
+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
+
+
+
+
+
+
+
+
+Sparks Standards Track [Page 1]
+
+RFC 3420 Internet Media Type message/ipfrag November 2002
+
+
+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.
+
+ 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.
+
+ 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.
+
+ 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].
+
+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:
+
+ o the entire start line
+
+ o one or more entire header fields
+
+ o the body
+
+ 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.
+
+ sipfrag = [ start-line ]
+ *message-header
+ [ CRLF [ message-body ] ]
+
+
+
+
+
+
+
+Sparks Standards Track [Page 2]
+
+RFC 3420 Internet Media Type message/ipfrag November 2002
+
+
+ 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.
+
+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.
+
+ The first two examples show that a message/sipfrag part can consist
+ of only a start line.
+
+ | INVITE sip:alice@atlanta.com SIP/2.0
+ or
+ | SIP/2.0 603 Declined
+
+ The next two show that Subsets of a full SIP message may be
+ represented.
+
+ | 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
+
+ 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].)
+
+ | 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
+
+
+
+
+
+
+
+
+
+Sparks Standards Track [Page 3]
+
+RFC 3420 Internet Media Type message/ipfrag November 2002
+
+
+ The next two examples show message/sipfrag parts that contain bodies.
+
+ | 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!
+
+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.
+
+ The start line, if present, must be complete and valid per [1].
+
+ X INVITE
+
+ X INVITE sip:alice@atlanta.com SIP/1.09
+
+ X SIP/2.0
+
+ X 404 Not Found
+
+ All header fields must be valid per [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
+
+
+
+Sparks Standards Track [Page 4]
+
+RFC 3420 Internet Media Type message/ipfrag November 2002
+
+
+ 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.
+
+ X MESSAGE sip:alice@atlanta.com SIP/2.0
+ X Hi There!
+
+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.
+
+ 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.
+
+ 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.
+
+
+
+
+Sparks Standards Track [Page 5]
+
+RFC 3420 Internet Media Type message/ipfrag November 2002
+
+
+5. IANA Considerations
+
+ The message/sipfrag media type is defined by the following
+ information:
+
+ 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
+
+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].
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks Standards Track [Page 6]
+
+RFC 3420 Internet Media Type message/ipfrag November 2002
+
+
+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
+
+ Robert J. Sparks
+ dynamicsoft
+ 5100 Tennyson Parkway
+ Suite 1200
+ Plano, TX 75024
+
+ EMail: rsparks@dynamicsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks Standards Track [Page 7]
+
+RFC 3420 Internet Media Type message/ipfrag November 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks Standards Track [Page 8]
+