One document matched: draft-camarillo-sip-body-handling-00.txt
SIP Working Group G. Camarillo
Internet-Draft Ericsson
Expires: November 24, 2007 May 23, 2007
Message Body Handling in the Session Initiation Protocol (SIP)
draft-camarillo-sip-body-handling-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 November 24, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document clarifies how message bodies are handled in SIP.
Additionally, it discusses to which degree SIP user agents need to
support MIME (Multipurpose Internet Mail Extensions)-encoding of body
parts.
Camarillo Expires November 24, 2007 [Page 1]
Internet-Draft Message Body Handing in SIP May 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message-Body and Body-Part Disposition . . . . . . . . . . . . 3
4. Multipart Message Bodies . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Camarillo Expires November 24, 2007 [Page 2]
Internet-Draft Message Body Handing in SIP May 2007
1. Introduction
SIP [RFC3261] messages consist of an initial line (request line in
requests and status line in responses) a set of header fields and an
optional message body. The message body is described using header
fields such as Content-Disposition, Content-Encoding, and Content-
Type, which provide information on its contents.
The message body of a SIP message can be divided into various body
parts. Multipart message bodies are encoded using the MIME
(Multipurpose Internet Mail Extensions) [RFC2045] format. Body parts
are also described using header fields such as Content-Disposition,
Content-Encoding, and Content-Type, which provide information on the
contents of a particular body part.
Section 3 discusses issues related to the disposition of message
bodies and body parts in SIP. Section 4 discusses issues related to
the handling of multipart message bodies in SIP.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Message-Body and Body-Part Disposition
The Content-Disposition header field, defined in [RFC2183] and
extended by [RFC3261], describes how to handle a SIP message's body
or an individual body part. Examples of disposition types used in
SIP in the Content-Disposition header field are 'session' and
'render'.
[RFC3204] defines the 'handling' parameter for the Content-
Disposition header field. From Section 6 of [RFC3204]:
"This document also defines a Content Disposition parameter,
"handling". The handling parameter, handling-parm, describes how
the UAS should react if it receives a message body whose content
type or disposition type it does not understand. If the parameter
has the value "optional", the UAS MUST ignore the message body; if
it has the value "required", the UAS MUST return 415 (Unsupported
Media Type). If the handling parameter is missing, the value
"required" is to be assumed."
[RFC3204] identifies two situations where a UAS (User Agent Server)
Camarillo Expires November 24, 2007 [Page 3]
Internet-Draft Message Body Handing in SIP May 2007
needs to reject a request with a body part whose handling is
required:
1. if it has an unknown content type.
2. if it has an unknown disposition type.
If the UAS (User Agent Server) did not understand the content type of
the body part, it can add an Accept header field to its 415
(Unsupported Media Type) response listing the content types that the
UAS does understand. Nevertheless, there is no mechanism for a UAS
that does not understand the disposition type of a body part to
inform the UAC (User Agent Client) about which disposition type was
not understood or about the disposition types that are understood by
the UAS.
The reason for not having such a mechanism is that disposition types
are typically supported within a context. Outside that context, a UA
(User Agent) may not support the disposition type. For example, a UA
may support the 'session' disposition type for body parts in INVITE
and UPDATE requests and their responses. However, the same UA would
not support the 'session' disposition type in MESSAGE requests.
In another example, a UA may support the 'render' disposition type
for 'text/plain' and 'text/html' body parts in MESSAGE requests.
Additionally, the UA may support the 'session' disposition type for
'application/sdp' body parts in INVITE and UPDATE requests and their
responses. However, the UA may not support the 'render' disposition
type for 'application/sdp' body parts in MESSAGE requests, even if,
in different contexts, the UA supported all the 'render' disposition
type, the 'application/sdp' content type, and the MESSAGE method.
A given context is generally (but not necessarily) defined by a
method, a disposition type, and a content type. Support for a
specific context is usually defined within an extension. For
example, the extension for instant messaging in SIP [RFC3428]
mandates support for the MESSAGE method, the 'render' disposition
type, and the 'text/plain' content type.
Therefore, support for a particular disposition type within a given
context is typically signalled by the use of a particular method or
an option-tag in a Supported or a Require header field. When support
for a particular disposition type within a context is mandated,
support for a default content type is also mandated (e.g., a UA that
supports the 'session' disposition type in an INVITE request needs to
support the 'application/sdp' content type). The previous two rules
are to be followed by authors of new SIP extensions.
In any case, if a UAS cannot process a request because, in the given
Camarillo Expires November 24, 2007 [Page 4]
Internet-Draft Message Body Handing in SIP May 2007
context, it does not support the content type or the disposition type
of a body part whose handling is required, the UAS SHOULD return a
415 (Unsupported Media Type) response even if the UAS supported the
content type, the disposition type, or both in a different context.
Content-ID URLs (Uniform Resource Locators) are another tool to
describe how a body part should be handled. Some extensions use a
Content-ID URL [RFC2392] that points to a body part. The way to
handle that body part is defined by the header field the Content-ID
URL appears in and by the disposition type of the body part. For
example, the extension to refer to multiple resources in SIP
[I-D.ietf-sip-multiple-refer] places a Content-ID URL in a Refer-To
header field. Such a Content-ID URL points to a body part whose
disposition type is supposed to be 'recipient-list'.
If a UAS receives a request with a body part whose disposition type
is not compatible with the way the body part should be handled
according to other parts of the SIP message (e.g., a Refer-To header
field with a Content-ID URL pointing to a body part whose disposition
type is 'session'), the UAS SHOULD return a 415 (Unsupported Media
Type) response.
OPEN ISSUE: we could define a new response code (Content or
Disposition Type not Supported in this Context) to report known
content and disposition types appearing in an unsupported context in
order to be more explicit than always using 415. It would avoid
receiving a 415 response with an Accept header field containing all
the content types used in the request. How useful would this really
be?
4. Multipart Message Bodies
[RFC3261] did not mandate support for multipart message bodies in
MIME format [RFC2046]. However, since [RFC3261] was written, many
SIP extensions relay on them. Therefore, this specification updates
[RFC3261]'s recommendation regarding support for multipart MIME
bodies.
It is expected that most SIP UAs will implement extensions that
require them to generate 'multipart/mixed' MIME bodies. An example
of such an extension would be the inclusion of location information
in an INVITE request. Such an INVITE request would use the
'multipart/mixed' MIME type to carry two body parts: a session
description and a location object.
Another MIME type a number of SIP UAs will need to generate is
'multipart/alternative'. Each body part within a 'multipart/
Camarillo Expires November 24, 2007 [Page 5]
Internet-Draft Message Body Handing in SIP May 2007
alternative' carries an alternative version of the same information.
The body parts are ordered so that the last one is the richest
representation of the information. This way, the recipient of a
'multipart/alternative' body chooses the last body part it
understands. Therefore, 'multipart/alternative' body parts MUST all
have different content types. That is, no body part within a
'multipart/alternative' can have the same content type as another
body part within the same 'multipart/alternative'.
Note that within a body part encoded in a given format (i.e., of a
given content type), there may be optional elements that may
provide richer information to the recipient in case the recipient
supports them. For example, in SDP (Session Description Protocol)
[RFC4566], those optional elements are encoded in 'a' lines.
These types of optional elements are internal to a body part and
are not visible at the MIME level. That is, a body part is
understood if the recipient understands its content type,
regardless of whether or not the body part's optional elements are
understood.
It is expected that the transition from SDP to new session
description protocols is implemented using 'multipart/alternative'
bodies. INVITE requests would carry a 'multipart/alternative' body
with two body parts: a session description written in SDP and a
session description written in a newer session description format.
Legacy UASs would use the session description written in SDP. New
UASs would use the one written in the newer format.
A number of SIP UAs will also need to generate nested MIME bodies.
Using the extensions in the previous examples, a UA that supported a
new session description format and that needed to include a location
object in an INVITE request would include a 'multipart/mixed' body
with two body parts: a location object and a 'multipart/alternative'.
The 'multipart/alternative' body part would, in turn, have two body
parts: a session description written in SDP and a session description
written in the newer session description format.
For all MIME-based extensions to work, the recipient needs to, of
course, be able to decode the multipart bodies. Therefore, SIP UAs
SHOULD be able to parse 'multipart' MIME bodies, including nested
body parts. In particular, UAs SHOULD support the 'multipart/mixed'
and 'multipart/alternative' MIME types. Note that, by default,
unknown 'multipart' subtypes are treated as 'multipart/mixed'.
If a UAS does not support multipart bodies and receives one, the UAS
SHOULD return a 415 (Unsupported Media Type) response.
OPEN ISSUE: do we need to talk about encrypted body parts?
Camarillo Expires November 24, 2007 [Page 6]
Internet-Draft Message Body Handing in SIP May 2007
5. Security Considerations
TBD.
6. Acknowledgements
The ideas in this document were discussed with Paul Kyzivat.
Christer Holmberg provided comments on this document.
7. IANA Considerations
This document does not contain any IANA actions.
8. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP
and QSIG Objects", RFC 3204, December 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
Camarillo Expires November 24, 2007 [Page 7]
Internet-Draft Message Body Handing in SIP May 2007
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[I-D.ietf-sip-multiple-refer]
Camarillo, G., "Referring to Multiple Resources in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-multiple-refer-01 (work in progress),
January 2007.
Author's Address
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Camarillo Expires November 24, 2007 [Page 8]
Internet-Draft Message Body Handing in SIP May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Camarillo Expires November 24, 2007 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 22:47:15 |