Internet Media Type message/sipfrag
RFC 3420

Document Type RFC - Proposed Standard (November 2002; Errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3420 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Allison Mankin
Send notices to <rohan@cisco.com>
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.
Show full document text