[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-olson-sip-content-indirect-mech) 00 01 02 03 04 05 RFC 4483

SIP                                                             S. Olson
Internet-Draft                                                 Microsoft
Expires: May 20, 2003                                  November 19, 2002


   A Mechanism for Content Indirection in Session Initiation Protocol
                             (SIP) Messages
                draft-ietf-sip-content-indirect-mech-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 May 20, 2003.

Copyright Notice

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

Abstract

   This Internet-Draft proposes an extension to the URL MIME External-
   Body Access-Type to satisfy the content indirection requirements for
   SIP.  These extensions are aimed at allowing any MIME part in a SIP
   message to be referred to indirectly via a URI.










Olson                     Expires May 20, 2003                  [Page 1]


Internet-Draft     Content Indirection in SIP Messages     November 2002


1. 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 RFC 2119 [2].














































Olson                     Expires May 20, 2003                  [Page 2]


Internet-Draft     Content Indirection in SIP Messages     November 2002


2. Introduction

   Previous attempts at solving the content indirection problem made use
   of the text/uri-list [8] MIME type.  While attractive for its
   simplicity (a list of URIs delimted by end-of-line markers), it fails
   to satisfy a number of the requirements [1] for a more general
   purpose content indirection mechanism in SIP.  Most notably lacking
   is the ability to specify various attributes on a per-URI basis.
   These attributes might include version information, the MIME type of
   the referenced content, etc.

   In searching for a replacement for the text/uri-list MIME type,
   RFC2017 defines a strong candidate.  RFC2017 defines an extension to
   the message/external-body MIME type originally defined in RFC2046
   [6].  The extension that RFC2017 makes is to allow a generic URI to
   specify the location of the content rather than protocol specific
   parameters for FTP, etc.  as originally defined in RFC2046.  While
   providing most of the functionality needed for a SIP content
   indirection mechanism, RFC2017 by itself is not a complete solution.
   This document will specify the usage of RFC2017 necessary to fulfill
   the requirments outlined for content indirection.

   The requirements of [1] can be classified as applying either to the
   URI which indirectly references the desired content or to the content
   itself.  Where possible, existing MIME parameters and entity headers
   will be used to satisfy those requirements.  MIME (Content-Type)
   parameters will be the preferred manner of describing the URI while
   entity headers will be the preferred manner of describing the
   (indirect) content.  See RFC 2045 [5] for a description of most of
   these entity headers and MIME parameters.





















Olson                     Expires May 20, 2003                  [Page 3]


Internet-Draft     Content Indirection in SIP Messages     November 2002


3. Application of RFC2017 to the Content Indirection Problem

   The following text describes the application of RFC2017 to the
   requirements for content indirection.

3.1 Specifying support for content indirection

   A UAC/UAS may indicate support for content indirection through an
   Accept header containing the message/external-body MIME type.  The
   UAC/UAS must supply additional values in the Accept header to
   indicate the content types that it is willing to accept either
   directly or through content indirection.  User-Agents supporting
   content indirection MUST support content indirection of the
   application/sdp MIME type.

   For example:


         Accept: message/external-body, image/*, application/sdp


3.2 Mandatory support for HTTP URI

   Applications which use this content indirection mechanism MUST
   support at least the HTTP URI scheme.  Additional URI schemes MAY be
   used, but a UAC/UAS MUST support receiving a HTTP URI for indirect
   content if it advertises support for content indirection.

   The intention is to establish a baseline of support to further
   strengthen interoperability.  Implementors may design for the most
   common case (HTTP) without having to worry about negotiation of
   support for this particular URI scheme.

3.3 Rejecting content indirection

   If a UAS receives a SIP request which contains a content indirection
   payload, and the UAS cannot or does not wish to support such a
   content type, it MUST reject the request with a 415 Unsupported Media
   Type response as defined in section 21.4.13 of SIP [3].  In
   particular, the UAC should note the absence of the message/external-
   body MIME type in the Accept header of this response to indicate that
   the UAS does not support content indirection.

3.4 Specifying the location of the content via a URI

   The URI for the indirect content is specified in a "URI" parameter of
   the message/external-body MIME type.  An access-type parameter
   indicates that the external content is referenced by a URI.



Olson                     Expires May 20, 2003                  [Page 4]


Internet-Draft     Content Indirection in SIP Messages     November 2002


   For example:


         Content-Type: message/external-body;
                       access-type="URL";
                       URL="http://www.volcano.com/the-indirect-content"


3.5 Specifying versioning information for the URI

   In order to determine whether or not the content indirectly
   referenced by the URI has changed, a Content-ID entity header is
   used.  The syntax of this header is defined in RFC2045 [5].  Changes
   in the underlying content referred to by a URI MUST result in a
   change in the Content-ID associated with that URI.  Multiple SIP
   messages carrying URI that refer to the same content SHOULD reuse the
   same Content-ID to allow the receiver to cache this content and avoid
   unnecessary retrievals.  The Content-ID is intended to be globally
   unique and SHOULD be temporally unique across SIP dialogs.

   For example:


         Content-ID: <4232423424@www.volcano.com>


3.6 Specifying the lifetime of the URI

   The URI supplied by in Content-Type header is not required to be
   accessible or valid for an indefinite period of time.  Rather, the
   supplier of the URI MUST specify the time period for which this URI
   is valid and accessible.  This is done through an "EXPIRATION"
   parameter of the Content-Type.  The format of this expiration
   parameter is a RFC1123 date-time value.  This is further restricted
   in this application to use only GMT time, consistent with the Date:
   header in SIP.  This is a mandatory parameter.

   For example:


         Content-Type: message/external-body;
                       expiration="Mon, 24 June 2002 09:00:00 GMT"


3.7 Specifying the type of the indirect content

   To support existing SIP mechanisms for the negotiation of content
   types, a Content-Type entity header SHOULD be present in the entity



Olson                     Expires May 20, 2003                  [Page 5]


Internet-Draft     Content Indirection in SIP Messages     November 2002


   (payload) itself.  If the protocol (scheme) of the URI supports its
   own content negotiation mechanisms (e.g.  HTTP), this header may be
   omitted.  The sender MUST however be prepared for the receiving party
   to reject content indirection if the receiver is unable to negotiate
   an appropriate MIME type using the underlying protocol for the URI
   scheme.

   For example:


         Content-Type: message/external-body; access-type="URL";
                       expiration="Mon, 24 June 2002 09:00:00 GMT";
                       URL="http://www.volcano.com/the-indirect-content"
         <CRLF>
         Content-Type: application/sdp
         <CRLF>


3.8 Specifying the size of the indirect content

   When known in advance, the size of the indirect content should be
   supplied via a size parameter on the Content-Type header.  This is an
   extension of RFC2017 but in line with other access types defined for
   the message/external-body MIME type in RFC2046.  The content size is
   useful for the receiving party to make a determination about whether
   or not to retrieve the content.  As with directly supplied content, a
   UAS may return a 513 error response in the event the content size is
   too large.  This is an optional parameter.

   For example:


         Content-Type: message/external-body; access-type="URL";
                       expiration="Mon, 24 June 2002 09:00:00 GMT";
                       URL="http://www.volcano.com/the-indirect-content";
                       size=4123


3.9 Specifying the purpose of the indirect content

   A Content-Disposition entity header SHOULD be present for all
   indirect content.  In the absence of an an explicit Content-
   Disposition header, a content disposition of "session" should be
   assumed.

   For example:





Olson                     Expires May 20, 2003                  [Page 6]


Internet-Draft     Content Indirection in SIP Messages     November 2002


         Content-Type: message/external-body; access-type="URL";
                       expiration="Mon, 24 June 2002 09:00:00 GMT";
                       URL="http://www.volcano.com/the-indirect-content"
         <CRLF>
         Content-Type: image/jpeg
         Content-Disposition: render


3.10 Specifying multiple URIs for content indirection

   If there is a need to send multiple URIs for the purpose of content
   indirection, an appropriate multipart MIME type [6] should be used.
   Each URI should be contained in a single entity.  Indirect content
   may be mixed with directly supplied content.  This is particularly
   useful with the multipart/alternative MIME type.

   For example:


        MIME-Version: 1.0
        Content-Type: multipart/mixed; boundary=boundary42

        --boundary42
        Content-Type: text/plain; charset=us-ascii

        The company announcement for June, 2002 follows:
        --boundary42
        Content-Type: message/external-body;
                      access-type="URL";
                      expiration="Mon, 24 June 2002 09:00:00 GMT";
                   URL="http://www.volcano.com/announcements/07242002";
                   size=4123

        Content-Type: text/html
        Content-Disposition: render

        --boundary42--


3.11 Supplying additional comments about the indirect content

   Optional, freeform text may be supplied to comment on the indirect
   content.  This should be supplied in a Content-Description entity
   header.

   For example:





Olson                     Expires May 20, 2003                  [Page 7]


Internet-Draft     Content Indirection in SIP Messages     November 2002


         Content-Type: message/external-body;
                       access-type="URL";
                       expiration="Mon, 24 June 2002 09:00:00 GMT";
                       URL="http://www.volcano.com/the-indirect-content";
                       size=52723
         <CRLF>
         Content-Description: Multicast gaming session


3.12 Relationship to Call-Info, Error-Info, and Alert-Info Headers

   SIP [3] defines three headers which are used to supply additional
   information with regard to a session, a particular error response, or
   alerting.  All three of these headers allow the UAC or UAS to
   indicate additional information through a URI.  They may be
   considered a form of content indirection.  The content indirection
   mechanism defined in this document is not intended as a replacement
   for these headers.  Rather, the headers defined in SIP MUST be used
   in preference to this mechanism where applicable because of the well
   defined semantics of those headers.































Olson                     Expires May 20, 2003                  [Page 8]


Internet-Draft     Content Indirection in SIP Messages     November 2002


4. Examples

4.1 Single Content Indirection


        INVITE sip:boromir@volcano.com SIP/2.0
        From: <sip:gandalf@nwt.com>;tag=347242
        To: <sip:boromir@volcano.com>
        Call-ID: 3573853342923422@nwt.com
        CSeq: 2131 INVITE
        Accept: message/external-body application/sdp
        Content-Type: message/external-body;
                      ACCESS-TYPE=URL;
                      URL="http://www.nwt.com/party/06/2002/announcement";
                   EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"
                   size=231
        Content-Length: ...

        Content-Type: application/sdp
        Content-Disposition: session
        Content-ID: <4e5562cd1214427d@nwt.com>




4.2 Multipart MIME with Content Indirection

























Olson                     Expires May 20, 2003                  [Page 9]


Internet-Draft     Content Indirection in SIP Messages     November 2002


        MESSAGE sip:boromir@volcano.com SIP/2.0
        From: <sip:gandalf@nwt.com>;tag=34589882
        To: <sip:boromir@volcano.com>
        Call-ID: 9242892442211117@nwt.com
        CSeq: 388 MESSAGE
        Accept: message/external-body, text/html, text/plain, image/*, text/x-emoticon
        MIME-Version: 1.0
        Content-Type: multipart/mixed; boundary=zz993453

        --zz993453
        Content-Type: message/external-body;
                      access-type="URL";
                      expiration="Mon, 24 June 2002 09:00:00 GMT";
                   URL="http://www.nwt.com/company_picnic/image1.png"
                   size=234422

        Content-Type: image/png
        Content-ID: <9535035333@nwt.com>
        Content-Disposition: render
        Content-Description: Kevin getting dunked in the wading pool

        --zz993453
        Content-Type: message/external-body;
                      access-type="URL";
                      expiration="Mon, 24 June 2002 09:00:00 GMT";
                   URL="http://www.nwt.com/company_picnic/image2.png"
                   size=233811

        Content-Type: image/png
        Content-ID: <1134299224244@nwt.com>
        Content-Disposition: render
        Content-Description: Peter on his tricycle

        --zz993453--

















Olson                     Expires May 20, 2003                 [Page 10]


Internet-Draft     Content Indirection in SIP Messages     November 2002


5. Security Considerations

   For confidentiality, integrity, and authentication, this content
   indirection mechanism relies on the security mechanisms outlined in
   RFC3261.  In particular, the usage of S/MIME as defined in section 23
   of RFC3261 provides the necessary mechanism to ensure integrity
   protection and privacy of the indirect content URI and associated
   parameters.

   Securing the transfer of the indirect content is the responsibility
   of the underlying protocol used for this transfer.  It is RECOMMENDED
   that applications implementing this content indirection method
   support the HTTPS URI scheme for secure transfer of content.

   Access control to the content referenced by the URI is not defined by
   this specification.  Access control mechanisms may be defined by the
   protocol for the scheme of the indirect content URI.


































Olson                     Expires May 20, 2003                 [Page 11]


Internet-Draft     Content Indirection in SIP Messages     November 2002


References

   [1]  Olson, S., "Requirements for Content Indirection in SIP
        Messages", draft-ietf-sipping-content-indirect-02 (work in
        progress), September 2002.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [3]  Rosenberg, J., Schulzrinne, Camarillo, Johnston, Peterson,
        Sparks, Handley and Schooler, "SIP: Session Initiation
        Protocol", RFC 3261, June 2002.

   [4]  Berners-Lee, Fielding and Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1996.

   [5]  Freed and Borenstein, "Multipurpose Internet Mail Extensions
        (MIME) Part One: Format of Internet Message Bodies", RFC 2045,
        November 1996.

   [6]  Freed and Borenstein, "Multipurpose Internet Mail Extensions
        (MIME) Part Two: Media Types", RFC 2046, November 1996.

   [7]  Freed, "Definition of the URL MIME External-Body Access-Type",
        RFC 2017, October 1996.

   [8]  Daniel, R., "A Trivial Convention for using HTTP in URN
        Resolution", RFC 2169, June 1997.


Author's Address

   Sean Olson
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   US

   Phone: +1-425-707-2846
   EMail: seanol@microsoft.com
   URI:   http://www.microsoft.com/rtc










Olson                     Expires May 20, 2003                 [Page 12]


Internet-Draft     Content Indirection in SIP Messages     November 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.



















Olson                     Expires May 20, 2003                 [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/