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 1. 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. 2. 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 3. 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 [1] PlaceHolder, A., "Placeholder", RFC 3261, May 2002. [2] 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]