RFC 3420 (rfc3420) - Page 2 of 8

Internet Media Type message/sipfrag

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