A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages
RFC 4483

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                     E. Burger, Ed.
Request for Comments: 4483                       Cantata Technolgy, Inc.
Category: Standards Track                                       May 2006

                  A Mechanism for Content Indirection
             in Session Initiation Protocol (SIP) Messages

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines an extension to the URL MIME External-Body
   Access-Type to satisfy the content indirection requirements for the
   Session Initiation Protocol (SIP).  These extensions are aimed at
   allowing any MIME part in a SIP message to be referred to indirectly
   via a URI.

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Use Case Examples ...............................................3
      3.1. Presence Notification ......................................4
      3.2. Document Sharing ...........................................4
   4. Requirements ....................................................5
   5. Application of RFC 2017 to the Content Indirection Problem ......6
      5.1. Specifying Support for Content Indirection .................6
      5.2. Mandatory support for HTTP URI .............................7
      5.3. Rejecting Content Indirection ..............................7
      5.4. Specifying the Location of the Content via a URI ...........7
      5.5. Marking Indirect Content Optional ..........................7
      5.6. Specifying Versioning Information for the URI ..............8
      5.7. Specifying the URI Lifetime ................................8
      5.8. Specifying the type of the Indirect Content ................8
      5.9. Specifying the Size of the Indirect Content ................9
      5.10. Specifying the Purpose of the Indirect Content ............9
      5.11. Specifying Multiple URIs for Content Indirection .........10

Burger                      Standards Track                     [Page 1]
RFC 4483          Content Indirection in SIP Messages           May 2006

      5.12. Specifying a Hash Value for the Indirect Content .........10
      5.13. Supplying Additional Comments about the Indirect
            Content ..................................................11
      5.14. Relationship to Call-Info, Error-Info, and
            Alert-Info Headers .......................................11
   6. Examples .......................................................12
      6.1. Single Content Indirection ................................12
      6.2. Multipart MIME with Content Indirection ...................12
   7. Security Considerations ........................................13
   8. Contributions ..................................................15
   9. Acknowledgements ...............................................15
   10. References ....................................................15
      10.1. Normative References .....................................15
      10.2. Informative Reference ....................................16

1.  Introduction

   The purpose of the Session Initiation Protocol [9] (SIP) is to
   create, modify, or terminate sessions with one or more participants.
   SIP messages, like HTTP, are syntactically composed of a start line,
   one or more headers, and an optional body.  Unlike HTTP, SIP is not
   designed as a general-purpose data transport protocol.

   There are numerous reasons why it might be desirable to specify the
   content of the SIP message body indirectly.  For bandwidth-limited
   applications such as cellular wireless, indirection provides a means
   to annotate the (indirect) content with meta-data, which may be used
   by the recipient to determine whether or not to retrieve the content
   over a resource-limited link.

   It is also possible that the content size to be transferred might
   overwhelm intermediate signaling proxies, thereby unnecessarily
   increasing network latency.  For time-sensitive SIP applications,
   this may be unacceptable.  Indirect content can remedy this by moving
   the transfer of this content out of the SIP 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