RFC 3420 (rfc3420) - Page 2 of 8
Internet Media Type message/sipfrag
Alternative Format: Original Text Document
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
