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]. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
