SIP R. Sparks
Internet-Draft dynamicsoft
Expires: October 25, 2002 April 26, 2002
Internet Media Type message/sipfrag
draft-sparks-sip-mimetypes-02
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 serves as the specification for the media type message/
sipfrag.
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. Encoding Considerations . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6
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. 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 message fragments being carried as the body of
other messages, 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/sipfrag part MAY be binary encoded.
If the transport is not 8-bit clean, encoding formats such as base-64
can be used.
4. 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.
Sparks Expires October 25, 2002 [Page 4]
Internet-Draft message/sipfrag April 2002
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 5]
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 6]