Network Working Group                                          R. Sparks
Internet-Draft                                               dynamicsoft
Expires: March 13, 2002                               September 12, 2001


          Internet Media Types message/sip and message/sipfrag
                     draft-sparks-sip-mimetypes-01

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 March 13, 2002.

Copyright Notice

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

Abstract

   This document serves as the specification for the media types
   "message/sip" and "message/sipfrag".













Sparks                   Expires March 13, 2002                 [Page 1]


Internet-Draft         message/sip message/sipfrag        September 2001


Table of Contents

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









































Sparks                   Expires March 13, 2002                 [Page 2]


Internet-Draft         message/sip message/sipfrag        September 2001


1. message/sip

   A mime-part of type message/sip can contain a single SIP [1] request
   or response message.

2. message/sipfrag

   A mime-part of type message/sipfrag can contain a subset of a single
   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.

3. IANA Considerations

   The following is to be registered with IANA

          Media Type name:         message
          Media subtype name:      sip
          Required parameters:     none
          Optional parameters:     version, msgtype
           version: The SIP-Version number of the enclosed message
                    (e.g., "2.0"). If not present, the version can be
                    determined from the first line of the body.
           msgtype: The message type -- "request" or "response". If not
                    present, the type can be determined from the first
                    line of the body.
          Encoding considerations: See section 4
          Security considerations: See section 5


          Media Type name:         message
          Media subtype name:      sipfrag
          Required parameters:     version
           version: The SIP-Version number of the enclosed message
                    (e.g., "2.0").
          Optional parameters:     none
          Encoding considerations: See section 4
          Security considerations: See section 5







Sparks                   Expires March 13, 2002                 [Page 3]


Internet-Draft         message/sip message/sipfrag        September 2001


4. Encoding Considerations

   SIP specifies UTF-8 encoding.  While most header names and data
   elements will lie in the 7-bit ascii compatible range, data elements
   and SIP bodies may contain 8-bit values.  In order to preserve the
   "readability" of SIP messages being carried as the body of other
   messages, message/sip and message/sipfrag parts (including any body
   parts they contain) SHOULD be UTF-8 encoded.  If transcoding a
   contained body part is not feasible, the message/sip or
   message/sipfrag part MAY be binary encoded.  If the transport is not
   8-bit clean, encoding formats such as base-64 can be used.

5. Security Considerations

   A SIP message may contain sensitive information.  If so, it can
   either be protected inside the message using the mechanisms specified
   in [1], or protected using the S/MIME mechanisms in [2].

References

   [1]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [2]  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
        2633, June 1999.


Author's Address

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

   EMail: rsparks@dynamicsoft.com















Sparks                   Expires March 13, 2002                 [Page 4]


Internet-Draft         message/sip message/sipfrag        September 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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 March 13, 2002                 [Page 5]