Network Working Group E. Burger, Ed.
Request for Comments: 4483 Cantata Technolgy, Inc.
Category: Standards Track May 2006
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
会话中的内容初始化（SIP）机制
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文档定义了URL MIME外部主体访问类型的扩展，以满足会话启动协议（SIP）的内容间接寻址要求。这些扩展旨在允许通过URI间接引用SIP消息中的任何MIME部分。
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
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
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
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
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.
会话启动协议[9]（SIP）的目的是创建、修改或终止与一个或多个参与者的会话。SIP消息，如HTTP，在语法上由起始行、一个或多个头和可选主体组成。与HTTP不同，SIP不是作为通用数据传输协议设计的。
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.
间接指定SIP消息体的内容可能有许多原因。对于带宽有限的应用，例如蜂窝无线，间接寻址提供了用元数据注释（间接）内容的方法，接收者可以使用元数据来确定是否通过资源有限的链路检索内容。
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.
要传输的内容大小也可能会压倒中间信令代理，从而不必要地增加网络延迟。对于时间敏感的SIP应用程序，这可能是不可接受的。间接内容可以通过将该内容的传输移出SIP信令网络并移入可能独立的数据传输信道来解决这一问题。
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.
还可能存在需要传输的会话相关数据（主体）不直接驻留在端点或用户代理上的场景。在这样的场景中，希望具有一种机制，使得SIP消息可以包含对所需内容的间接引用。然后，接收方将使用此间接引用通过非SIP传输通道（如HTTP、FTP或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
内容间接寻址的目的纯粹是为SIPMIME主体部分提供一种替代传输机制。除运输机构外，间接车身部件
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.
以前解决内容间接寻址问题的尝试使用了text/urilist[6]MIME类型。虽然它的简单性（由行结束标记分隔的URI列表）很有吸引力，但它并没有满足SIP中更通用的内容间接寻址机制的许多要求。最明显的不足是在每个URI的基础上指定各种属性的能力。这些属性可能包括版本信息、引用内容的MIME类型等。
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.
RFC 2017为文本/uri列表MIME类型定义了一个强有力的替代品。RFC 2017[1]定义了对最初在RFC2046[3]中定义的消息/外部正文MIME类型的扩展。RFC 2017的扩展允许通用URI指定内容的位置，而不是RFC2046中最初定义的FTP等协议特定参数。尽管RFC 2017提供了SIP内容间接寻址机制所需的大部分功能，但它本身并不是一个完整的解决方案。本文件规定了满足内容间接寻址要求所需的RFC 2017的使用。
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.
这些需求可以分类为应用于URI（它间接引用所需的内容）或应用于内容本身。在可能的情况下，使用现有的MIME参数和实体头来满足这些要求。MIME（内容类型）参数是描述URI的首选方式，而实体头是描述（间接）内容的首选方式。请参阅RFC 2045[2]，了解大多数实体头和MIME参数的说明。
RFC 2119 [5] defines the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
RFC 2119[5]定义了关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”。
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.
有几个使用内容间接寻址机制的示例。这些只是示例，并不打算限制该机制的范围或适用性。
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.
状态文档中包含的信息可能超过SIP（NOTIFY）请求的建议大小，特别是当文档包含来自多个端点的聚合信息时。在这种情况下，最好使用指向状态文档的间接指针发送NOTIFY请求，然后可以通过HTTP等方式检索该文档。
Watcher Presence Server
| |
| SUBSCRIBE |
|-------------------------->|
| 200 OK |
|<--------------------------|
| |
| NOTIFY |
|<--------------------------|
| 200 OK |
|-------------------------->|
| |
| NOTIFY (w/URI) |
|<--------------------------|
| 200 |
|-------------------------->|
| |
| HTTP GET |
|-------------------------->|
| |
| application/cpim-pidf+xml |
|<--------------------------|
| |
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.
在本例中，状态服务器返回一个HTTP URI，指向状态服务器上的状态文档，然后观察者可以使用HTTP GET获取该文档。
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.
在即时消息传递会话期间，一个有用的服务是文档共享，其中一方发送一个IM（消息请求），其中包含指向远程方要呈现的文档的间接指针。在消息请求中直接携带这样的文档不是对信令信道的适当使用。此外，要共享的文档可以驻留在与发起方完全独立的服务器上。
UAC UAS Web Server
(User Agent (User Agent |
Client) Server) |
| | |
| MESSAGE w/URI | |
|------------------->| |
| 200 | |
|<-------------------| |
| | |
| | HTTP GET |
| |--------------->|
| | image/jpeg |
| |<---------------|
| | |
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.
在本例中，用户UAC希望与与其进行IM对话的用户UAS交换存储在web服务器上的JPEG图像。她打算在IM对话中内联渲染JPEG。消息请求的收件人向web服务器启动HTTP GET请求以检索JPEG图像。
o It MUST be possible to specify the location of content via a URI. Such URIs MUST conform with RFC2396 [7].
o 必须能够通过URI指定内容的位置。此类URI必须符合RFC2396[7]。
o It MUST be possible to specify the length of the indirect content.
o 必须能够指定间接内容的长度。
o It MUST be possible to specify the type of the indirect content.
o 必须能够指定间接内容的类型。
o It MUST be possible to specify the disposition of each URI independently.
o 必须能够独立地指定每个URI的配置。
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.
o 必须能够标记每个URI，以确定该URI引用的内容是否以及何时发生了更改。此机制的应用程序可以多次发送相同的URI。此要求的目的是允许接收方确定URI引用的内容是否已更改，而无需检索该内容。可以是URI的版本号，也可以是URI的版本号。当与HTTP一起使用时，RFC2068[4]中定义的实体标记（ETAG）机制可能是合适的。请注意，我们标记的不是URI本身，而是URI所引用的内容，因此标签实际上是内容本身的“元数据”。
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 必须能够指定给定URI有效的时间跨度。这可能与内容本身的生存期相同，也可能不同。
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 UAC和UAS必须能够表示支持此内容间接寻址机制。当其中一方无法支持内容间接寻址时，应指定回退机制。
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 在使用内容间接寻址机制时，UAC和UAS必须能够协商间接内容的类型。
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 UAC和UAS必须能够协商对内容间接寻址机制中使用的任何URI方案的支持。除此之外，还可以协商内容类型。
o It SHOULD be possible to ensure the integrity and confidentiality of the URI when it is received by the remote party.
o 当远程方接收到URI时，应该能够确保URI的完整性和机密性。
o It MUST be possible to process the content indirection without human intervention.
o 必须能够在无需人工干预的情况下间接处理内容。
o It MUST allow for indirect transference of content in any SIP message that would otherwise carry that content as a body.
o 它必须允许间接传输任何SIP消息中的内容，否则该消息将作为一个主体承载该内容。
The following text describes the application of RFC 2017 to the requirements for content indirection.
以下文本描述了RFC 2017在内容间接寻址需求中的应用。
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.
UAC/UAS通过在Accept标头中包含message/external body MIME类型来表示对内容间接寻址的支持。UAC/UAS可在Accept标头中提供附加值，以指示其愿意直接或通过内容间接接受的内容类型。支持内容间接寻址的用户代理必须支持应用程序/sdp MIME类型的内容间接寻址。
For example:
例如：
Accept: message/external-body, image/*, application/sdp
Accept: message/external-body, image/*, application/sdp
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.
使用此内容间接寻址机制的应用程序必须支持HTTP URI方案。可以使用其他URI方案，但如果UAC/UAS宣传支持内容间接寻址，则必须支持接收间接内容的HTTP URI。
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].
如RFC 3840[11]所述，UAS可在UAS对UAC的会话建立请求（例如，邀请、订阅）的响应中，在联系人报头的schemes参数中公布备用接入方案。
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.
如果UAS接收到包含内容间接有效负载的SIP请求，并且UAS不能或不希望支持此类内容类型，则必须使用SIP[9]第21.4.13节中定义的415不支持的媒体类型响应拒绝该请求。具体而言，UAC应注意此响应的Accept标头中不存在消息/外部主体MIME类型，以表明UAS不支持内容间接寻址，或不存在请求注释的特定MIME类型，以表明UAS不支持特定媒体类型。
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].
间接内容的URI在message/external body MIME类型的“URI”参数中指定。访问类型参数表示外部内容由URI引用。HTTP URI规范必须符合RFC 2396[7]。
For example:
例如：
Content-Type: message/external-body; access-type="URL";
URL="http://www.example.com/the-indirect-content"
Content-Type: message/external-body; access-type="URL";
URL="http://www.example.com/the-indirect-content"
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.
如果提取或转换失败，某些内容对通信上下文并不重要。内容间接寻址机制使用RFC 3459[10]中描述的关键内容机制。特别是，如果UAS无法获取或呈现可选的身体部位，则服务器不得向UAC返回错误。
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.
为了确定URI间接引用的内容是否已更改，使用内容ID实体头。RFC 2045[2]中定义了此标头的语法。URI引用的基础内容的更改必须导致与该URI关联的内容ID的更改。承载引用相同内容的URI的多个SIP消息应重用相同的内容ID，以允许接收方缓存此内容并避免不必要的检索。内容ID应该是全局唯一的，并且在SIP对话框中应该是临时唯一的。
For example:
例如：
Content-ID: <4232423424@www.example.com>
Content-ID: <4232423424@www.example.com>
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.
内容类型标头提供的URI无需在无限期内可访问或有效。相反，URI的提供者必须指定此URI有效且可访问的时间段。这是通过内容类型的“EXPIRATION”参数完成的。此过期参数的格式为RFC 1123[12]日期时间值。在本应用程序中，这进一步限制为仅使用GMT时间，与SIP中的Date:标头一致。这是一个强制参数。请注意，日期时间值的范围从分钟到天甚至年。
For example:
例如：
Content-Type: message/external-body;
expiration="Mon, 24 June 2002 09:00:00 GMT"
Content-Type: message/external-body;
expiration="Mon, 24 June 2002 09:00:00 GMT"
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.
为了支持用于内容类型协商的现有SIP机制，实体（有效负载）本身中应该存在一个内容类型实体头。如果URI的协议（方案）支持其自己的内容协商机制（例如HTTP），则可以省略该报头。但是，如果接收方无法使用URI方案的基础协议协商适当的MIME类型，则发送方必须为接收方拒绝间接内容做好准备。
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>
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>
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.
如果预先知道间接内容的大小（以字节为单位），则应通过内容类型标头上的大小参数提供。这是RFC 2017的扩展，但与RFC 2046中为消息/外部主体MIME类型定义的其他访问类型一致。内容大小有助于接收方确定是否检索内容。与直接提供的内容一样，如果内容大小过大，UAS可能会返回513错误响应。大小是一个可选参数。
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
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
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
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
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.
如果需要为内容间接寻址发送多个URI，则应使用适当的多部分MIME类型[3]。每个URI必须包含在单个实体中。间接成分可与直接提供的成分混合。这对于多部分/可选MIME类型特别有用。
NOTE: This specification does not change the meanings of the various multipart flavors, particularly multipart/related, as described in RFC 2387 [13].
注：本规范不改变RFC 2387[13]中所述的各种多部分风格的含义，尤其是多部分/相关的。
For example:
例如：
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary42
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
--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
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
Content-Type: text/html
Content-Disposition: render
--boundary42--
--边界42--
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.
如果发送方知道间接寻址引用的特定内容，并且如果发送方希望接收方能够验证该内容没有被发送方更改，则发送方将包含该内容的SHA-1[8]散列。如果包含，则通过扩展MIME语法[3]对哈希进行编码，以包含内容类型“message/external body”的“hash”参数，其值是哈希的十六进制编码。
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
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
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
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
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.
SIP[9]定义了三个标头，提供有关会话、特定错误响应或警报的附加信息。这三个头都允许UAC或UAS通过URI指示附加信息。它们可以被视为一种间接的内容形式。本文档中定义的内容间接寻址机制无意替代这些标题。相反，SIP中定义的头必须优先于此机制使用（如果适用），因为这些头具有定义良好的语义。
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
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>
Content-Type: application/sdp
Content-Disposition: session
Content-ID: <4e5562cd1214427d@example.net>
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
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
--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
Content-Type: image/png
Content-ID: <9535035333@example.net>
Content-Disposition: render
Content-Description: Kevin getting dunked in the wading pool
--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/image2.png";
size=233811
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
Content-Type: image/png
Content-ID: <1134299224244@example.net>
Content-Disposition: render
Content-Description: Peter on his tricycle
--zz993453--
--zz993453--
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 内容间接寻址允许启动器为内容传输选择安全性较弱或存在已知漏洞的替代协议（例如，要求收件人发出导致基本身份验证质询的HTTP请求）。
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 内容间接寻址允许发起者要求收件人在信息传输和内容处理中使用额外的资源，这可能会造成拒绝服务攻击的途径（例如，一个活动的FTP URL为每个间接内容消息使用2个连接）。
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 内容间接寻址可以用作端口扫描攻击的一种形式，其中间接内容URL实际上是指向收件人内部资源的伪造URL。对内容间接寻址请求的响应可能会显示有关这些内部资源上的开放（和易受攻击）端口的信息。
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.
o 内容间接URL可能会泄露有关启动器的敏感信息，例如内部用户名（作为HTTP URL的一部分）或可能的地理位置信息。
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.
幸运的是，通过仔细筛选接收和发送的间接内容URI，可以缓解所有这些潜在威胁。间接内容URI的完整性和机密性保护也可以防止额外的攻击。
For confidentiality, integrity, and authentication, this content indirection mechanism relies on the security mechanisms outlined in
对于机密性、完整性和身份验证，此内容间接寻址机制依赖于中概述的安全机制
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.
RFC3261。特别是，RFC 3261第23节中定义的S/MIME的使用提供了必要的机制，以确保间接内容URI和相关参数的完整性、保护和机密性。
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.
保护间接内容的传输是用于此传输的基础协议的责任。如果使用HTTP，则实现此内容间接寻址方法的应用程序应支持用于安全传输内容的HTTPS URI方案，并且必须支持通过使用starttls升级到TLS的连接。请注意，在接受SIP请求中的间接内容后未能完成HTTPS或starttls（例如，由于证书或加密不匹配），这与拒绝SIP请求不同，可能需要额外的用户通信进行更正。
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.
请注意，本文档不提倡使用传递信任。也就是说，仅仅因为UAS从UAC接收到UAS信任的URI，UAS不应该在不与URI提供者建立自己的信任关系的情况下隐式信任URI引用的对象。
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.
此规范未定义对URI引用的内容的访问控制。访问控制机制可以由协议为间接内容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.
如果UAC事先知道内容，则UAC应在内容间接寻址中包含哈希参数。散列参数是间接内容的十六进制编码SHA-1[8]散列。如果包含散列值，则收件人必须对照该散列检查间接内容，并向用户指出任何不匹配的内容。
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.
此外，如果包含哈希参数，并且目标URI涉及使用证书设置安全上下文，则UAS必须忽略证书验证过程的结果，而是验证所接收（规范化）内容的哈希是否与内容间接哈希参数中显示的哈希相匹配。
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.
如果未包含哈希参数，则发送方应仅使用提供消息完整性的方案（如https:）。如果未包含哈希参数，并且使用了使用证书的安全性，UAS必须使用UAS的受信任顶级证书颁发机构列表来验证任何服务器证书。
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.
如果不使用间接内容的散列，则通过执行间接寻址返回给收件人的内容可能已与发件人的预期内容有所不同。
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.
肖恩·奥尔森，seanol@microsoft.com，提供了本文件的绝大多数内容，包括通过IESG第一次审查的编辑。迪安·威利斯接着摸了摸。
Eric Burger edited the document and addressed IESG comments, including the access protocol negotiation mechanism.
Eric Burger编辑了该文件并发表了IESG评论，包括访问协议协商机制。
Cullen Jennings and Nancy Greene provided a through review and valuable comments and suggestions.
卡伦·詹宁斯（Cullen Jennings）和南希·格林（Nancy Greene）提供了全面的评论和宝贵的意见和建议。
[1] Freed, N. and K. Moore, "Definition of the URL MIME External-Body Access-Type", RFC 2017, October 1996.
[1] Freed，N.和K.Moore，“URL MIME外部实体访问类型的定义”，RFC 2017，1996年10月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[2] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[3] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[4] 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，尼尔森，H.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[6] Daniel，R.，“在URN解析中使用HTTP的简单约定”，RFC 2169，1997年6月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[8] Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC3174，2001年9月。
[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.
[9] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[10] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[10] Burger，E.“关键内容多用途互联网邮件扩展（MIME）参数”，RFC 3459，2003年1月。
[11] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[11] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[12] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[12] Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[13] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[13] Levinson，E.，“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
Author's Address
作者地址
Eric Burger (editor) Cantata Technolgy, Inc.
埃里克·伯格（编辑）康塔塔科技公司。
EMail: eburger@cantata.com
URI: http://www.cantata.com
EMail: eburger@cantata.com
URI: http://www.cantata.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。