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