[Sip] Protocol Action: 'A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'A Mechanism for Content Indirection in Session Initiation Protocol (SIP) 
   Messages '
   <draft-ietf-sip-content-indirect-mech-05.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-05.txt

Technical Summary

   The content indirection mechanism in SIP provides an alternative
   transport mechanism for SIP MIME body parts.  It is very general,
   in that indirected body parts are equivalent to in-line body parts,
   but specific uses include ensuring that large content (such a png
   images) is transported along a different path than the signaling
   when MESSAGE is used for messaging, and to ensure the most 
   efficient handling of large presence documents, just to give 
   two examples.

   Previous attempts at solving the content indirection problem 
   made use of the text/uri-list MIME type. While attractive 
   for its simplicity (a list of URIs delimited by end-of-line markers), 
   it did not satisfy all the requirements for SIP's content
   indirection (which are presented in the document).  Most notably
   lacking were an ability to specify attributes for it on a per-
   URI basis, such as the MIME type of the reference's content,
   and an expiration time for interest in it.     

   The SIP content indirection solution uses the MIME type
   message/external-body (RFC 2017), along with MIME parameters
   and entity headers from there, RFC 2045 and RFC 2046. 
   MIME Content-Type parameters are the preferred manner of
   describing the URI, while entity headers are the preferred
   manner of describing the (indirect) content.

Working Group Summary

   The working group reviewed the design directions for a long while
   and this one appeared the cleanest to them.  There was strong support
   for the document in the working group and in the SIMPLE Working Group.
   
Protocol Quality

   The document has been reviewed for the IESG by Allison Mankin. 
   It received careful security review and revision.
   The design got some desired mid-course Apps review while still
   in the WG.  It appeared efficient and sound, but it needed the
   IESG's Apps review as well.
   
RFC Editor Note - 
   [13] has been published as RFC 3986, and should become the
   normative reference [7] instead of RFC 2396, which it obsoletes.
   Delete the informative reference.

 Also:

OLD:
4.  Requirements

   o  It MUST be possible to specify the location of content via a URI.
      Such URIs MUST conform with RFC2396 [7] or its successors, such as
      [13].

NEW:
4.  Requirements

   o  It MUST be possible to specify the location of content via a URI.
      Such URIs MUST conform with RFC3986 [7].


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip