SIPPING                                                         S. Olson
Internet-Draft                                                 Microsoft
Expires: November 30, 2002                                     June March 24, 2003                               September 23, 2002

  Requirements for Content Indirection in SIP Session Initiation Protocol
                             (SIP) Messages
                 draft-ietf-sipping-content-indirect-01
                 draft-ietf-sipping-content-indirect-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 November 30, 2002. March 24, 2003.

Copyright Notice

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

Abstract

   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 specification defines requirements for a mechanism to indirectly
   specify such
   information so that the content of a more appropriate non-SIP channel may be used SIP message for the transfer. purpose of transferring
   the content via a non-SIP channel.

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

2. Introduction

   The purpose of the Session Initiation Protocol [2] (SIP) is to
   create, modify, or terminate sessions with one or more participants.
   SIP messages, like HTTP, are sytnactically composed of a start line,
   one or more headers, and an optional body.  Unlike HTTP, SIP is not intended
   designed as a general purpose transfer protocol in the way
   HTTP or FTP is.  One limitation transport of SIP in this regard is in data.

   There are numerous reasons why it might be desirable to indirectly
   specify the use content of a SIP over the UDP transport.  On message body.  For bandwidth limited
   applications such as cellular wireless, indirection provides a transport, the size of means
   to annotate the
   SIP message is effectively bounded (indirect) content with meta-data which may be used
   by the MTU recipient to avoid fragmentation.
   A reasonable nominal value for such an MTU would be 1500 bytes.
   Taking into account determine whether or not to retrieve the potential content
   over the resource limited link.

   It is also possible that the content size of routing information, a safe
   upper bound to use for SIP messages on the UDP transport would be
   1200 bytes.  Clearly transferred might
   potentially overwhelm intermediate signaling proxies, thereby
   unnecessarily increasing network latency.  For time-sensitive SIP
   applications, this is not sufficient for carrying any
   arbitrary payload, though it is perfectly adequate for most session
   signalling.

   There may be scenarios however where session related data needs to be
   conveyed and unacceptable.  Indirect content can remedy
   this by moving the given data exceeds transfer of this content out of the recommended size for a SIP
   message. signaling
   network and into a potentially separate data transfer channel.

   There may also be scenarios where the session related data (body)
   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.

   The purpose of content indirection is purely to provide an
   alternative transport mechanism for SIP MIME body parts.  With the
   exception of the transport mechanism, indirected body parts are
   equivalent, and should have the same treatment, as in-line body
   parts.

3. Example Use Cases

   There are several potential immediate example 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.

   Figure 1: Example information flow for presence notification

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

   In this example, the presence server returns an HTTP URL URI 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, conversation, 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 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.

   Figure 2: Example information flow for document sharing

               UAC                  UAS         Web Server
                |                    |                |
                |   MESSAGE w/URL w/URI    |                |
                |------------------->|                |
                |        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 conversation
   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.

4. Requirements

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

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

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

      It MUST be possible to specify the timespan for which a given URL URI
      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 the type of
      the indirect content types when using the content indirection mechanism.

      It MUST be possible for the UAC and UAS to negotiate support for
      URL
      URI 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 URI when
      they are it
      is 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

5. Security Considerations

   Any content indirection mechanism MUST introduces additional security
   concerns.  By its nature, content indirection requires an extra
   processing step and information transfer.  There are a number of
   potential abuses of a content indirection mechanism:

      Content indirection allows the initiator to choose an alternative
      protocol with weaker security or known vulnerabilities for the
      content transfer.  For example, asking the recipient to issue an
      HTTP request which results in a Basic authentication challenge.

      Content indirection allows the initiator to ask the recipient to
      consume additional resources in the information transfer and
      content processing, potentially creating an avenue for denial of
      service attacks.  For example, an active FTP URL consuming 2
      connections for every indirect content message.

      Content indirection could be usable used as a form of port scanning
      attack where the indirect content URL is actually a bogus URL
      pointing to an internal resource of the recipient.  The response
      to the content indirection request could reveal information about
      open (and vulnerable) ports on these internal resources.

      A content indirection URL can disclose sensitive information about
      the initiator such as an internal user name (as part of an HTTP
      URL) or possibly geolocation information.

   Fortunately, all of these potential threats can be mitigated through
   careful screening of both the indirect content URIs that are received
   as well as those that are sent.  The clear requirement is that
   integrity and potentially privacy protection SHOULD be applied to the
   content indirection URI(s) in a MIME
      multipart body. [4] SIP message.

References

   [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
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   US

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

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.