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