Internet Media Type message/sipfrag
Extracted elements (12)
Protecting only a subset of a SIP message (rather than the whole message) avoids the complexity and potential errors of handling header fields that legitimately change in transit (e.g., Via), and allows cryptographic assertions to be constructed before the full hop-by-hop header is available.
The message/sipfrag type was created because including an entire SIP response as message/sip in a REFER notification has significant negative security implications. message/sipfrag allows the sender to select what information is exposed and to elide mandatory SIP fields not relevant to the notification, reducing message size.
message/sipfrag does NOT provide a mechanism to segment a SIP message into multiple pieces for separate transport and later reassembly. The message/partial type defined in RFC 2046 provides a solution for that separate problem.
SIP messages must be treated as binary for encoding purposes (8-bit header optionally followed by binary MIME data). Under normal circumstances SIP messages are transported over binary-capable transports, so no special encodings are needed.
Any SIP extension that uses message/sipfrag MUST describe the replay and cut-and-paste threats unique to its particular usage, since a captured sipfrag part could be replayed or combined with other message parts in harmful ways.
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 RFC 3261, and the null-line separating the header from the body.
A message/sipfrag part is a subset of a valid SIP message, obtained by starting with a well-formed SIP message and optionally deleting the entire start line, one or more entire header fields, and/or the body. All remaining elements must conform to SIP grammar.
The optional 'version' parameter of message/sipfrag carries the SIP-Version number of the enclosed message (e.g., '2.0'). If not present, the version defaults to '2.0'.
This document registers the message/sipfrag MIME media type. Required parameters: none. Optional parameters: version (SIP-Version number, defaulting to '2.0'). Encoding: binary (8-bit header optionally followed by binary MIME data object).
A message/sipfrag part may contain sensitive information or information used to affect processing decisions at the receiver. Protection can be improved using S/MIME mechanisms described in Section 23 of RFC 3261, with the limitations described in Section 26 of that document.
Applications using message/sipfrag to represent a subset of SIP header fields must consider replay and cut-and-paste threats, and must include sufficient information in the sipfrag part to mitigate those risks. For example, an identity assertion use case must bind the assertion to the specific request.
The ABNF grammar for a sipfrag part is: sipfrag = [ start-line ] *message-header [ CRLF [ message-body ] ]. The start-line, message-header, and message-body elements are defined by the SIP grammar in RFC 3261.