summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4483.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4483.txt')
-rw-r--r--doc/rfc/rfc4483.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc4483.txt b/doc/rfc/rfc4483.txt
new file mode 100644
index 0000000..793af5c
--- /dev/null
+++ b/doc/rfc/rfc4483.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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
+ 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, indirect body parts are
+
+
+
+Burger Standards Track [Page 2]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+ equivalent to, and should have the same treatment as, in-line body
+ parts.
+
+ Previous attempts at solving the content indirection problem made use
+ of the text/uri-list [6] MIME type. While attractive for its
+ simplicity (a list of URIs delimited by end-of-line markers), it
+ failed to satisfy a number of the requirements for a more general-
+ purpose content indirection mechanism in SIP. Most notably lacking
+ is the ability to specify various attributes on a per-URI basis.
+ These attributes might include version information, the MIME type of
+ the referenced content, etc.
+
+ RFC 2017 defines a strong candidate for a replacement for the
+ text/uri-list MIME type. RFC 2017 [1] defines an extension to the
+ message/external-body MIME type originally defined in RFC2046 [3].
+ The extension that RFC 2017 makes allows a generic URI to specify the
+ location of the content rather than protocol-specific parameters for
+ FTP, etc., as originally defined in RFC2046. Although it provides
+ most of the functionality needed for a SIP content indirection
+ mechanism, RFC 2017 by itself is not a complete solution. This
+ document specifies the usage of RFC 2017 necessary to fulfill the
+ requirements outlined for content indirection.
+
+ The requirements can be classified as applying either to the URI,
+ which indirectly references the desired content, or to the content
+ itself. Where possible, existing MIME parameters and entity headers
+ are used to satisfy those requirements. MIME (Content-Type)
+ parameters are the preferred manner of describing the URI, while
+ entity headers are the preferred manner of describing the (indirect)
+ content. See RFC 2045 [2] for a description of most of these entity
+ headers and MIME parameters.
+
+2. Terminology
+
+ RFC 2119 [5] defines the keywords "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL".
+
+3. Use Case Examples
+
+ There are several examples of using the content indirection
+ mechanism. These are examples only and are not intended to limit the
+ scope or applicability of the mechanism.
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 3]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+3.1. Presence Notification
+
+ The information carried in a presence document could 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.
+
+ Watcher Presence Server
+ | |
+ | SUBSCRIBE |
+ |-------------------------->|
+ | 200 OK |
+ |<--------------------------|
+ | |
+ | NOTIFY |
+ |<--------------------------|
+ | 200 OK |
+ |-------------------------->|
+ | |
+ | NOTIFY (w/URI) |
+ |<--------------------------|
+ | 200 |
+ |-------------------------->|
+ | |
+ | HTTP GET |
+ |-------------------------->|
+ | |
+ | application/cpim-pidf+xml |
+ |<--------------------------|
+ | |
+
+ In this example, the presence server returns an HTTP URI pointing to
+ a presence document on the presence server, which the watcher can
+ then fetch by using an HTTP GET.
+
+3.2. Document Sharing
+
+ During an instant messaging conversation, a useful service is
+ document sharing, wherein one party sends an IM (MESSAGE request)
+ with an indirect pointer to a document that is meant to be rendered
+ by the remote party. Carrying such a document directly in the
+ MESSAGE request is not an appropriate use of the signaling channel.
+ Furthermore, the document to be shared may reside on a completely
+ independent server from that of the originating party.
+
+
+
+
+
+Burger Standards Track [Page 4]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+ UAC UAS Web Server
+ (User Agent (User Agent |
+ Client) Server) |
+ | | |
+ | MESSAGE w/URI | |
+ |------------------->| |
+ | 200 | |
+ |<-------------------| |
+ | | |
+ | | HTTP GET |
+ | |--------------->|
+ | | image/jpeg |
+ | |<---------------|
+ | | |
+
+ In this example, a user UAC wishes to exchange a JPEG image that she
+ has stored on her web server with user UAS with whom she has an IM
+ conversation. She intends to render the JPEG inline in the IM
+ conversation. The recipient of the MESSAGE request launches an HTTP
+ GET request to the web server to retrieve the JPEG image.
+
+4. Requirements
+
+ o It MUST be possible to specify the location of content via a URI.
+ Such URIs MUST conform with RFC2396 [7].
+
+ o It MUST be possible to specify the length of the indirect content.
+
+ o It MUST be possible to specify the type of the indirect content.
+
+ o It MUST be possible to specify the disposition of each URI
+ independently.
+
+ o It MUST be possible to label each URI to identify if and when the
+ content referred to by that URI has changed. Applications of this
+ mechanism may send the same URI more than once. The intention of
+ this requirement is to allow the receiving party to determine
+ whether the content referenced by the URI has changed, without
+ having to retrieve that content. Examples of ways the URI could
+ be labeled include a sequence number, timestamp, and version
+ number. When used with HTTP, the entity-tag (ETAG) mechanism, as
+ defined in RFC2068 [4], may be appropriate. Note that we are
+ labeling not the URI itself but the content to which the URI
+ refers, and that the label is therefore effectively "metadata" of
+ the content itself.
+
+
+
+
+
+
+Burger Standards Track [Page 5]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+ o It MUST be possible to specify the time span for which a given URI
+ is valid. This may or may not be the same as the lifetime for the
+ content itself.
+
+ o 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.
+
+ o It MUST be possible for the UAC and UAS to negotiate the type of
+ the indirect content when using the content indirection mechanism.
+
+ o It MUST be possible for the UAC and UAS to negotiate support for
+ any URI scheme to be used in the content indirection mechanism.
+ This is in addition to the ability to negotiate the content type.
+
+ o It SHOULD be possible to ensure the integrity and confidentiality
+ of the URI when it is received by the remote party.
+
+ o It MUST be possible to process the content indirection without
+ human intervention.
+
+ o It MUST allow for indirect transference of content in any SIP
+ message that would otherwise carry that content as a body.
+
+5. Application of RFC 2017 to the Content Indirection Problem
+
+ The following text describes the application of RFC 2017 to the
+ requirements for content indirection.
+
+5.1. Specifying Support for Content Indirection
+
+ A UAC/UAS indicates support for content indirection by including the
+ message/external-body MIME type in the Accept header. The UAC/UAS
+ MAY supply additional values in the Accept header to indicate the
+ content types that it is willing to accept, either directly or
+ through content indirection. User-Agents supporting content
+ indirection MUST support content indirection of the application/sdp
+ MIME type.
+
+ For example:
+
+ Accept: message/external-body, image/*, application/sdp
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 6]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+5.2. Mandatory support for HTTP URI
+
+ Applications that use this content indirection mechanism MUST support
+ the HTTP URI scheme. Additional URI schemes MAY be used, but a
+ UAC/UAS MUST support receiving a HTTP URI for indirect content if it
+ advertises support for content indirection.
+
+ The UAS MAY advertise alternate access schemes in the schemes
+ parameter of the Contact header in the UAS response to the UAC's
+ session establishment request (e.g., INVITE, SUBSCRIBE), as described
+ in RFC 3840 [11].
+
+5.3. Rejecting Content Indirection
+
+ If a UAS receives a SIP request that contains a content indirection
+ payload and the UAS cannot or does not wish to support such a content
+ type, it MUST reject the request with a 415 Unsupported Media Type
+ response as defined in section 21.4.13 of SIP [9]. In particular,
+ the UAC should note the absence of the message/external-body MIME
+ type in the Accept header of this response to indicate that the UAS
+ does not support content indirection, or the absence of the
+ particular MIME type of the requested comment to indicate that the
+ UAS does not support the particular media type.
+
+5.4. Specifying the Location of the Content via a URI
+
+ The URI for the indirect content is specified in a "URI" parameter of
+ the message/external-body MIME type. An access-type parameter
+ indicates that the external content is referenced by a URI. HTTP URI
+ specifications MUST conform to RFC 2396 [7].
+
+ For example:
+
+ Content-Type: message/external-body; access-type="URL";
+ URL="http://www.example.com/the-indirect-content"
+
+5.5. Marking Indirect Content Optional
+
+ Some content is not critical to the context of the communication if
+ there is a fetch or conversion failure. The content indirection
+ mechanism uses the Critical-Content mechanism described in RFC 3459
+ [10]. In particular, if the UAS is unable to fetch or render an
+ optional body part, then the server MUST NOT return an error to the
+ UAC.
+
+
+
+
+
+
+
+Burger Standards Track [Page 7]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+5.6. Specifying Versioning Information for the URI
+
+ In order to determine whether the content indirectly referenced by
+ the URI has changed, a Content-ID entity header is used. The syntax
+ of this header is defined in RFC 2045 [2]. Changes in the underlying
+ content referred to by a URI MUST result in a change in the Content-
+ ID associated with that URI. Multiple SIP messages carrying URIs
+ that refer to the same content SHOULD reuse the same Content-ID, to
+ allow the receiver to cache this content and to avoid unnecessary
+ retrievals. The Content-ID is intended to be globally unique and
+ SHOULD be temporally unique across SIP dialogs.
+
+ For example:
+
+ Content-ID: <4232423424@www.example.com>
+
+5.7. Specifying the URI Lifetime
+
+ The URI supplied by the Content-Type header is not required to be
+ accessible or valid for an indefinite period of time. Rather, the
+ supplier of the URI MUST specify the time period for which this URI
+ is valid and accessible. This is done through an "EXPIRATION"
+ parameter of the Content-Type. The format of this expiration
+ parameter is an RFC 1123 [12] date-time value. This is further
+ restricted in this application to use only GMT time, consistent with
+ the Date: header in SIP. This is a mandatory parameter. Note that
+ the date-time value can range from minutes to days or even years.
+
+ For example:
+
+ Content-Type: message/external-body;
+ expiration="Mon, 24 June 2002 09:00:00 GMT"
+
+5.8. Specifying the type of the Indirect Content
+
+ To support existing SIP mechanisms for the negotiation of content
+ types, a Content-Type entity header SHOULD be present in the entity
+ (payload) itself. If the protocol (scheme) of the URI supports its
+ own content negotiation mechanisms (e.g., HTTP), this header may be
+ omitted. The sender MUST, however, be prepared for the receiving
+ party to reject content indirection if the receiver is unable to
+ negotiate an appropriate MIME type by using the underlying protocol
+ for the URI scheme.
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 8]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+ For example:
+
+ Content-Type: message/external-body; access-type="URL";
+ expiration="Mon, 24 June 2002 09:00:00 GMT";
+ URL="http://www.example.com/the-indirect-content"
+ <CRLF>
+ Content-Type: application/sdp
+ Content-Disposition: session
+ <CRLF>
+
+5.9. Specifying the Size of the Indirect Content
+
+ When known in advance, the size of the indirect content in bytes
+ SHOULD be supplied via a size parameter on the Content-Type header.
+ This is an extension of RFC 2017 but is in line with other access
+ types defined for the message/external-body MIME type in RFC 2046.
+ The content size is useful for the receiving party to make a
+ determination about whether to retrieve the content. As with
+ directly supplied content, a UAS may return a 513 error response in
+ the event that the content size is too large. Size is an optional
+ parameter.
+
+ For example:
+
+ Content-Type: message/external-body; access-type="URL";
+ expiration="Mon, 24 June 2002 09:00:00 GMT";
+ URL="http://www.example.com/the-indirect-content";
+ size=4123
+
+5.10. Specifying the Purpose of the Indirect Content
+
+ A Content-Disposition entity header MUST be present for all indirect
+ content.
+
+ For example:
+
+ Content-Type: message/external-body; access-type="URL";
+ expiration="Mon, 24 June 2002 09:00:00 GMT";
+ URL="http://www.example.com/the-indirect-content"
+ <CRLF>
+ Content-Type: image/jpeg
+ Content-Disposition: render
+
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 9]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+5.11. Specifying Multiple URIs for Content Indirection
+
+ If there is a need to send multiple URIs for content indirection, an
+ appropriate multipart MIME type [3] should be used. Each URI MUST be
+ contained in a single entity. Indirect content may be mixed with
+ directly-supplied content. This is particularly useful with the
+ multipart/alternative MIME type.
+
+ NOTE: This specification does not change the meanings of the various
+ multipart flavors, particularly multipart/related, as described in
+ RFC 2387 [13].
+
+ For example:
+
+ MIME-Version: 1.0
+ Content-Type: multipart/mixed; boundary=boundary42
+
+ --boundary42
+ Content-Type: text/plain; charset=us-ascii
+
+ The company announcement for June, 2002 follows:
+ --boundary42
+ Content-Type: message/external-body;
+ access-type="URL";
+ expiration="Mon, 24 June 2002 09:00:00 GMT";
+ URL="http://www.example.com/announcements/07242002";
+ size=4123
+
+ Content-Type: text/html
+ Content-Disposition: render
+
+ --boundary42--
+
+5.12. Specifying a Hash Value for the Indirect Content
+
+ If the sender knows the specific content being referenced by the
+ indirection, and if the sender wishes the recipient to be able to
+ validate that this content has not been altered from that intended by
+ the sender, the sender includes a SHA-1 [8] hash of the content. If
+ it is included, the hash is encoded by extending the MIME syntax [3]
+ to include a "hash" parameter for the content type "message/
+ external-body", whose value is a hexadecimal encoding of the hash.
+
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 10]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+ For example:
+
+ Content-Type: message/external-body;
+ access-type="URL";
+ expiration="Mon, 24 June 2002 09:00:00 GMT";
+ URL="http://www.example.com/the-indirect-content.au";
+ size=52723;
+ hash=10AB568E91245681AC1B
+ <CRLF>
+ Content-Disposition: render
+
+5.13. Supplying Additional Comments about the Indirect Content
+
+ One MAY use the Content-Description entity header to provide
+ optional, freeform text to comment on the indirect content. This
+ text MAY be displayed to the end user but MUST NOT used by other
+ elements to determine the disposition of the body.
+
+ For example:
+
+ Content-Type: message/external-body;
+ access-type="URL";
+ expiration="Mon, 24 June 2002 09:00:00 GMT";
+ URL="http://www.example.com/the-indirect-content";
+ size=52723
+ <CRLF>
+ Content-Description: Multicast gaming session
+ Content-Disposition: render
+
+5.14. Relationship to Call-Info, Error-Info, and Alert-Info Headers
+
+ SIP [9] defines three headers that supply additional information with
+ regard to a session, a particular error response, or alerting. All
+ three of these headers allow the UAC or UAS to indicate additional
+ information through a URI. They may be considered a form of content
+ indirection. The content indirection mechanism defined in this
+ document is not intended as a replacement for these headers. Rather,
+ the headers defined in SIP MUST be used in preference to this
+ mechanism, where applicable, because of the well-defined semantics of
+ those headers.
+
+
+
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 11]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+6. Examples
+
+6.1. Single Content Indirection
+
+ INVITE sip:boromir@example.com SIP/2.0
+ From: <sip:gandalf@example.net>;tag=347242
+ To: <sip:boromir@example.com>
+ Call-ID: 3573853342923422@example.net
+ CSeq: 2131 INVITE
+ Accept: message/external-body application/sdp
+ Content-Type: message/external-body;
+ ACCESS-TYPE=URL;
+ URL="http://www.example.net/party/06/2002/announcement";
+ EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT";
+ size=231
+ Content-Length: 105
+
+ Content-Type: application/sdp
+ Content-Disposition: session
+ Content-ID: <4e5562cd1214427d@example.net>
+
+6.2. Multipart MIME with Content Indirection
+
+ MESSAGE sip:boromir@example.com SIP/2.0
+ From: <sip:gandalf@example.net>;tag=34589882
+ To: <sip:boromir@example.com>
+ Call-ID: 9242892442211117@example.net
+ CSeq: 388 MESSAGE
+ Accept: message/external-body, text/html, text/plain,
+ image/*, text/x-emoticon
+ MIME-Version: 1.0
+ Content-Type: multipart/mixed; boundary=zz993453
+
+ --zz993453
+ Content-Type: message/external-body;
+ access-type="URL";
+ expiration="Mon, 24 June 2002 09:00:00 GMT";
+ URL="http://www.example.net/company_picnic/image1.png";
+ size=234422
+
+ Content-Type: image/png
+ Content-ID: <9535035333@example.net>
+ Content-Disposition: render
+ Content-Description: Kevin getting dunked in the wading pool
+
+ --zz993453
+
+
+
+
+
+Burger Standards Track [Page 12]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+ Content-Type: message/external-body;
+ access-type="URL";
+ expiration="Mon, 24 June 2002 09:00:00 GMT";
+ URL="http://www.example.net/company_picnic/image2.png";
+ size=233811
+
+ Content-Type: image/png
+ Content-ID: <1134299224244@example.net>
+ Content-Disposition: render
+ Content-Description: Peter on his tricycle
+
+ --zz993453--
+
+7. Security Considerations
+
+ Any content indirection mechanism 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:
+
+ o 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 that results in a Basic authentication challenge).
+
+ o 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).
+
+ o Content indirection could be 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.
+
+ o 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
+ and those that are sent. Integrity and confidentiality protection of
+ the indirect content URI can prevent additional attacks as well.
+
+ For confidentiality, integrity, and authentication, this content
+ indirection mechanism relies on the security mechanisms outlined in
+
+
+
+Burger Standards Track [Page 13]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+ RFC 3261. In particular, the usage of S/MIME as defined in section
+ 23 of RFC 3261 provides the necessary mechanism to ensure integrity,
+ protection, and confidentiality of the indirect content URI and
+ associated parameters.
+
+ Securing the transfer of the indirect content is the responsibility
+ of the underlying protocol used for this transfer. If HTTP is used,
+ applications implementing this content indirection method SHOULD
+ support the HTTPS URI scheme for secure transfer of content and MUST
+ support the upgrading of connections to TLS, by using starttls. Note
+ that a failure to complete HTTPS or starttls (for example, due to
+ certificate or encryption mismatch) after having accepted the
+ indirect content in the SIP request is not the same as rejecting the
+ SIP request, and it may require additional user-user communication
+ for correction.
+
+ Note that this document does not advocate the use of transitive
+ trust. That is, just because the UAS receives a URI from a UAC that
+ the UAS trusts, the UAS SHOULD NOT implicitly trust the object
+ referred to by the URI without establishing its own trust
+ relationship with the URI provider.
+
+ Access control to the content referenced by the URI is not defined by
+ this specification. Access control mechanisms may be defined by the
+ protocol for the scheme of the indirect content URI.
+
+ If the UAC knows the content in advance, the UAC SHOULD include a
+ hash parameter in the content indirection. The hash parameter is a
+ hexadecimal-encoded SHA-1 [8] hash of the indirect content. If a
+ hash value is included, the recipient MUST check the indirect content
+ against that hash and indicate any mismatch to the user.
+
+ In addition, if the hash parameter is included and the target URI
+ involves setting up a security context using certificates, the UAS
+ MUST ignore the results of the certificate validation procedure, and
+ instead verify that the hash of the (canonicalized) content received
+ matches the hash presented in the content-indirection hash parameter.
+
+ If the hash parameter is NOT included, the sender SHOULD use only
+ schemes that offer message integrity (such as https:). When the hash
+ parameter is not included and security using certificates is used,
+ the UAS MUST verify any server certificates, by using the UAS's list
+ of trusted top-level certificate authorities.
+
+ If hashing of indirect content is not used, the content returned to
+ the recipient by exercise of the indirection might have been altered
+ from that intended by the sender.
+
+
+
+
+Burger Standards Track [Page 14]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+8. Contributions
+
+ Sean Olson, seanol@microsoft.com, provided the vast majority of the
+ content of this document, including editorship through the first IESG
+ review. Dean Willis touched it next.
+
+ Eric Burger edited the document and addressed IESG comments,
+ including the access protocol negotiation mechanism.
+
+9. Acknowledgements
+
+ Cullen Jennings and Nancy Greene provided a through review and
+ valuable comments and suggestions.
+
+10. References
+
+10.1. Normative References
+
+ [1] Freed, N. and K. Moore, "Definition of the URL MIME External-
+ Body Access-Type", RFC 2017, October 1996.
+
+ [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+ [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046, November
+ 1996.
+
+ [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
+ Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+ 2068, January 1997.
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [6] Daniel, R., "A Trivial Convention for using HTTP in URN
+ Resolution", RFC 2169, June 1997.
+
+ [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986,
+ January 2005.
+
+ [8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
+ RFC 3174, September 2001.
+
+
+
+
+
+
+Burger Standards Track [Page 15]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+ [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+ Session Initiation Protocol", RFC 3261, June 2002.
+
+ [10] Burger, E., "Critical Content Multi-purpose Internet Mail
+ Extensions (MIME) Parameter", RFC 3459, January 2003.
+
+ [11] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
+ User Agent Capabilities in the Session Initiation Protocol
+ (SIP)", RFC 3840, August 2004.
+
+ [12] Braden, R., "Requirements for Internet Hosts - Application and
+ Support", STD 3, RFC 1123, October 1989.
+
+10.2. Informative Reference
+
+ [13] Levinson, E., "The MIME Multipart/Related Content-type", RFC
+ 2387, August 1998.
+
+Author's Address
+
+ Eric Burger (editor)
+ Cantata Technolgy, Inc.
+
+ EMail: eburger@cantata.com
+ URI: http://www.cantata.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 16]
+
+RFC 4483 Content Indirection in SIP Messages May 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Burger Standards Track [Page 17]
+