SIPPING                                                         S. Olson
Internet-Draft                                                 Microsoft
Expires: November 30, 2002                                     June 2002

          Requirements for Content Indirection in SIP Messages

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-

   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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 30, 2002.

Copyright Notice

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


   Various applications of the Session Initiation Protocol (SIP) require
   the exchange of information between endpoints that is potentially too
   large to reasonably send directly in a SIP message.  This Internet-
   Draft defines requirements for a mechanism to indirectly specify such
   information so that a more appropriate non-SIP channel may be used
   for the transfer.

Olson                   Expires November 30, 2002               [Page 1]

Internet-Draft     Content Indirection in SIP Messages         June 2002

1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [1].

Olson                   Expires November 30, 2002               [Page 2]

Internet-Draft     Content Indirection in SIP Messages         June 2002

2. Introduction

   The purpose of the Session Initiation Protocol [2] (SIP) is to
   create, modify, or terminate sessions with one or more participants.
   SIP is not intended as a general purpose transfer protocol in the way
   HTTP or FTP is.  One limitation of SIP in this regard is in the use
   of SIP over the UDP transport.  On such a transport, the size of the
   SIP message is effectively bounded by the MTU to avoid fragmentation.
   A reasonable nominal value for such an MTU would be 1500 bytes.
   Taking into account the potential size of routing information, a safe
   upper bound to use for SIP messages on the UDP transport would be
   1200 bytes.  Clearly this is not sufficient for carrying any
   arbitrary payload, though it is perfectly adequate for most session

   There may be scenarios however where session related data needs to be
   conveyed and the given data exceeds the recommended size for a SIP
   message.  There may also be scenarios where the session related data
   that needs to be conveyed does not directly reside on the endpoint or
   User Agent.  In such scenarios, it is desirable to have a mechanism
   whereby the SIP message can contain an indirect reference to the
   desired content.  The receiving party would then use this indirect
   reference to retrieve the content via a non-SIP transfer channel such
   as HTTP, FTP, or LDAP.

Olson                   Expires November 30, 2002               [Page 3]

Internet-Draft     Content Indirection in SIP Messages         June 2002

3. Example Use Cases

   There are several potential immediate users of such a content
   indirection mechanism.  These are examples only and are not intended
   to limit the scope or applicability of the mechanism.

3.1 Presence Notification

   The information carried in a presence document could potentially
   exceed the recommended size for a SIP (NOTIFY) request, particularly
   if the document carries aggregated information from multiple
   endpoints.  In such a situation, it would be desirable to send the
   NOTIFY request with an indirect pointer to the presence document
   which could then be retrieved by, for example, HTTP.

   Example information flow for presence notification

                    Watcher                 Presence Server
                       |                           |
                       |      SUBSCRIBE/200        |
                       |       NOTIFY/200          |
                       |                           |
                       |      NOTIFY (w/URL)       |
                       |           200             |
                       |                           |
                       |         HTTP GET          |
                       |                           |
                       | application/cpim-pidf+xml |
                       |                           |

   In this example, the presence server returns an HTTP URL pointing to
   a presence document on the presence server which the watcher can then
   fetch using an HTTP GET.

3.2 Document Sharing

   During an instant messaging session, a useful service is document
   sharing wherein one party sends an IM (MESSAGE request) with an
   indirect pointer to a document which is meant to be rendered by the

Olson                   Expires November 30, 2002               [Page 4]

Internet-Draft     Content Indirection in SIP Messages         June 2002

   remote party.  Carrying such a document directly in the MESSAGE
   request is not appropriate for most documents.  Furthermore, the
   document to be shared may reside on a completely independent server
   from the originating party.

   Example information flow for document sharing

                       UAC                  UAS         Web Server
                       |                    |                |
                       |   MESSAGE w/URL    |                |
                       |------------------->|                |
                       |        200         |                |
                       |<-------------------|                |
                       |                    |                |
                       |                    |    HTTP GET    |
                       |                    |--------------->|
                       |                    |   image/jpeg   |
                       |                    |<---------------|
                       |                    |                |

   In this example, a user wishes to exchange a JPEG image that she has
   stored on her web server with another user she has a IM dialog with.
   The JPEG is intended to be rendered inline in the IM conversation.
   The recepient of the MESSAGE request launches a HTTP GET request to
   the web server to retrieve the JPEG image.

Olson                   Expires November 30, 2002               [Page 5]

Internet-Draft     Content Indirection in SIP Messages         June 2002

4. Requirements

      It MUST be possible to specify the location of content via one or
      more URIs [3].

      It MUST be possible to specify the purpose and disposition of each
      URL independently.

      It MUST be possible to label each URL to identify if and when the
      content referred to by that URL has changed.  Applications of this
      mechanism may send the same URL more than once.  The intention of
      this requirement is to allow the receiving party to determine if
      the content referenced by the URL has changed without having to
      actually retrieve that content.  Example ways the URL could be
      labelled include a sequence number, timestamp, version number,

      It MUST be possible to specify the timespan for which a given URL
      is valid.  Applications of this mechanism MUST specify a lifetime
      for the URL.  This may or may not be the same as the lifetime for
      the content itself.

      It MUST be possible for the UAC and the UAS to indicate support of
      this content indirection mechanism.  A fallback mechanism SHOULD
      be specified in the event that one of the parties is unable to
      support content indirection.

      It MUST be possible for the UAC and UAS to negotiate content types
      when using the content indirection mechanism.

      It MUST be possible for the UAC and UAS to negotiate support for
      URL scheme(s) to be used in the content indirection mechanism.
      This is in addition to the ability to negotiate the content type.

      It SHOULD be possible to ensure the integrity of the URLs when
      they are received by the remote party.

      It MUST be possible to process the content indirection without
      human intervention.

      It MUST allow for indirect transference of content in any SIP
      message which would otherwise carry that content as a body.

      The content indirection mechanism MUST be usable as part of a MIME
      multipart body. [4]

Olson                   Expires November 30, 2002               [Page 6]

Internet-Draft     Content Indirection in SIP Messages         June 2002


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

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

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

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

Author's Address

   Sean Olson
   One Microsoft Way
   Redmond, WA  98052

   Phone: +1-425-707-2846

Olson                   Expires November 30, 2002               [Page 7]

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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Olson                   Expires November 30, 2002               [Page 8]