SIP                                                            R. Sparks
Internet-Draft                                               dynamicsoft
Expires: October 25, 2002                                 April 26, 2002


                  Internet Media Type message/sipfrag
                     draft-sparks-sip-mimetypes-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 25, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document registers the message/sipfrag MIME media type.  This
   type is similar to message/sip , but allows fragments of well formed
   SIP messages to be used for the same tunelling purposes as message/
   sip.  In addition to end-to-end security uses , message/sipfrag is
   used with the REFER method  to tunnel information about the status of
   a referrenced request.









Sparks                  Expires October 25, 2002                [Page 1]

Internet-Draft               message/sipfrag                  April 2002


Table of Contents

   1. message/sipfrag  . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 3
   3. Security Considerations  . . . . . . . . . . . . . . . . . . . . 4
      References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
      Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 5











































Sparks                  Expires October 25, 2002                [Page 2]

Internet-Draft               message/sipfrag                  April 2002


. message/sipfrag

   This document registers the message/sipfrag MIME media type.  This
   type is similar to message/sip as defined in [1], but allows
   fragments of well formed SIP messages to be used for the same
   tunelling purposes as message/sip.  In addition to the end-to-end
   security uses discussed in [1], message/sipfrag is used in the REFER
   [2] to tunnel information about the status of a referrenced request.

   The motivation and examples of usage of message/sip as a security
   mechanism in concert with S/MIME are given in seciton 23.4 of [1].
   These apply equally to message/sipfrag, with the additional benefit
   of being able to choose which portions of the message to protect.

   Motivation and examples of usage of message/sipfrag to carry the
   status of referrenced requests is provided in [2].  In particular,
   allowing only a portion of a SIP message to be carried allows
   information that could compromise privacy and confidentiality to be
   protected by removal.

   Where a message/sip mime-part must be a complete well formed SIP
   message, a mime-part of type message/sipfrag can contain a subset of
   a SIP message.  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 headers

   o  the body

   If the message/sipfrag part contains a body, it must also contain a
   Content-Length header and the null-line separating headers from the
   body.

. IANA Considerations

   The message/sipfrag media type is defined by the following
   information:











Sparks                  Expires October 25, 2002                [Page 3]

Internet-Draft               message/sipfrag                  April 2002


         Media type name: message
         Media subtype name: sipfrag
         Required parameters: none
         Optional parameters: version
            version: The SIP-Version number of the enclosed message
              (e.g., "2.0"). If not present, the version defaults to "2.0".
         Encoding scheme: SIP messages consist of an 8-bit header optionally
            followed by a binary MIME data object. As such, SIP messages
            must be treated as binary. Under normal circumstances SIP
            messages are transported over binary-capable transports, no
            special encodings are needed.
         Security considerations: see below


. Security Considerations

   A message/sip mime-part may contain sensitive information or
   information used to affect processing decisions at the receiver.
   When exposing that information or modifying it during transport would
   do harm its level of protection can be improved using the S/MIME
   mechanisms described in section 23 of , with the limitations
   described in section 26 of that document.

References

   []  PlaceHolder, A., "Placeholder", RFC 3261, May 2002.

   []  Sparks, R., "The REFER Method", draft-ietf-sip-refer-02 (work in
        progress), September 2001.


Author's Address

   Robert J. Sparks
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024

   EMail: rsparks@dynamicsoft.com











Sparks                  Expires October 25, 2002                [Page 4]

Internet-Draft               message/sipfrag                  April 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Sparks                  Expires October 25, 2002                [Page 5]