Network Working Group M. Garcia-Martin
Request for Comments: 5547 Ericsson
Category: Standards Track M. Isomaki
Nokia
G. Camarillo
S. Loreto
Ericsson
P. Kyzivat
Cisco Systems
May 2009
Network Working Group M. Garcia-Martin
Request for Comments: 5547 Ericsson
Category: Standards Track M. Isomaki
Nokia
G. Camarillo
S. Loreto
Ericsson
P. Kyzivat
Cisco Systems
May 2009
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
一种支持文件传输的会话描述协议（SDP）提供/应答机制
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document.
本文档提供了一种机制，通过使用RFC 3264中指定的会话描述协议（SDP）提供/应答模型，在两个端点之间协商一个或多个文件的传输。SDP被扩展以描述要传输的文件的属性。报价人可以描述其想要发送的文件或想要接收的文件。回答者可以分别接受或拒绝每个文件的报价。一个或多个文件的传输在协商成功后启动。消息会话中继协议（MSRP）被定义为在端点之间实际传输文件的默认机制。本文件还提供了关于如何使用MSRP进行文件传输的约定。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Definitions .....................................................4
4. Overview of Operation ...........................................5
5. File Selector ...................................................6
6. Extensions to SDP ...............................................7
7. File Disposition Types .........................................13
8. Protocol Operation .............................................13
8.1. The 'file-transfer-id' Attribute ..........................14
8.2. Offerer's Behavior ........................................17
8.2.1. The Offerer Is a File Sender .......................17
8.2.2. The Offerer Is a File Receiver .....................18
8.2.3. SDP Offer for Several Files ........................18
8.3. Answerer's Behavior .......................................19
8.3.1. The Answerer Is a File Receiver ....................19
8.3.2. The Answerer Is a File Sender ......................20
8.4. Aborting an Ongoing File Transfer Operation ...............22
8.5. Indicating File Transfer Offer/Answer Capability ..........25
8.6. Reusage of Existing "m=" Lines in SDP .....................26
8.7. MSRP Usage ................................................26
8.8. Considerations about the 'file-icon' Attribute ............28
9. Examples .......................................................28
9.1. Offerer Sends a File to the Answerer ......................28
9.2. Offerer Requests a File from the Answerer and
Second File Transfer ......................................33
9.3. Example of a Capability Indication ........................40
10. Security Considerations .......................................41
11. IANA Considerations ...........................................42
11.1. Registration of New SDP Attributes .......................42
11.1.1. Registration of the file-selector Attribute .......43
11.1.2. Registration of the file-transfer-id Attribute ....43
11.1.3. Registration of the file-disposition Attribute ....43
11.1.4. Registration of the file-date Attribute ...........44
11.1.5. Registration of the file-icon Attribute ...........44
11.1.6. Registration of the file-range Attribute ..........45
12. Acknowledgments ...............................................45
13. References ....................................................45
13.1. Normative References .....................................45
13.2. Informative References ...................................46
Appendix A. Alternatives Considered ..............................48
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Definitions .....................................................4
4. Overview of Operation ...........................................5
5. File Selector ...................................................6
6. Extensions to SDP ...............................................7
7. File Disposition Types .........................................13
8. Protocol Operation .............................................13
8.1. The 'file-transfer-id' Attribute ..........................14
8.2. Offerer's Behavior ........................................17
8.2.1. The Offerer Is a File Sender .......................17
8.2.2. The Offerer Is a File Receiver .....................18
8.2.3. SDP Offer for Several Files ........................18
8.3. Answerer's Behavior .......................................19
8.3.1. The Answerer Is a File Receiver ....................19
8.3.2. The Answerer Is a File Sender ......................20
8.4. Aborting an Ongoing File Transfer Operation ...............22
8.5. Indicating File Transfer Offer/Answer Capability ..........25
8.6. Reusage of Existing "m=" Lines in SDP .....................26
8.7. MSRP Usage ................................................26
8.8. Considerations about the 'file-icon' Attribute ............28
9. Examples .......................................................28
9.1. Offerer Sends a File to the Answerer ......................28
9.2. Offerer Requests a File from the Answerer and
Second File Transfer ......................................33
9.3. Example of a Capability Indication ........................40
10. Security Considerations .......................................41
11. IANA Considerations ...........................................42
11.1. Registration of New SDP Attributes .......................42
11.1.1. Registration of the file-selector Attribute .......43
11.1.2. Registration of the file-transfer-id Attribute ....43
11.1.3. Registration of the file-disposition Attribute ....43
11.1.4. Registration of the file-date Attribute ...........44
11.1.5. Registration of the file-icon Attribute ...........44
11.1.6. Registration of the file-range Attribute ..........45
12. Acknowledgments ...............................................45
13. References ....................................................45
13.1. Normative References .....................................45
13.2. Informative References ...................................46
Appendix A. Alternatives Considered ..............................48
The Session Description Protocol (SDP) offer/answer [RFC3264] provides a mechanism for two endpoints to arrive at a common view of a multimedia session between them. These sessions often contain real-time media streams such as voice and video, but are not limited to that. Basically, any media component type can be supported, as long as there is a specification how to negotiate it within the SDP offer/answer exchange.
会话描述协议（SDP）提供/应答[RFC3264]为两个端点提供了一种机制，以获得它们之间多媒体会话的公共视图。这些会话通常包含实时媒体流，如语音和视频，但不限于此。基本上，可以支持任何媒体组件类型，只要有在SDP提供/应答交换中协商的规范。
The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for transmitting instant messages (IMs) in the context of a session. The protocol specification describes the usage of SDP for establishing an MSRP session. In addition to plain text messages, MSRP is able to carry arbitrary (binary) Multipurpose Internet Mail Extensions (MIME) [RFC2045] compliant content, such as images or video clips.
消息会话中继协议（MSRP）[RFC4975]是用于在会话上下文中传输即时消息（IMs）的协议。协议规范描述了SDP用于建立MSRP会话的用法。除纯文本信息外，MSRP还能够携带任意（二进制）多用途Internet邮件扩展（MIME）[RFC2045]兼容内容，如图像或视频剪辑。
There are many cases where the endpoints involved in a multimedia session would like to exchange files within the context of that session. With MSRP, it is possible to embed files as MIME objects inside the stream of instant messages. MSRP also has other features that are useful for file transfer. Message chunking enables the sharing of the same transport connection between the transfer of a large file and interactive IM exchange without blocking the IM. MSRP relays [RFC4976] provide a mechanism for Network Address Translator (NAT) traversal. Finally, Secure MIME (S/MIME) [RFC3851] can be used for ensuring the integrity and confidentiality of the transferred content.
在许多情况下，多媒体会话中涉及的端点希望在该会话的上下文中交换文件。使用MSRP，可以将文件作为MIME对象嵌入即时消息流中。MSRP还有其他对文件传输有用的功能。消息分块允许在大文件传输和交互式IM交换之间共享相同的传输连接，而不会阻塞IM。MSRP中继[RFC4976]为网络地址转换器（NAT）遍历提供了一种机制。最后，安全MIME（S/MIME）[RFC3851]可用于确保传输内容的完整性和机密性。
However, the baseline MSRP does not readily meet all the requirements for file transfer services within multimedia sessions. There are four main missing features:
然而，基线管理系统更新项目并不容易满足多媒体会话中文件传输服务的所有要求。缺少四个主要功能：
o The recipient must be able to distinguish "file transfer" from "file attached to IM", allowing the recipient to treat the cases differently.
o 收件人必须能够区分“文件传输”和“附在IM上的文件”，以便收件人以不同的方式处理这些情况。
o It must be possible for the sender to send the request for a file transfer. It must be possible for the recipient to accept or decline it, using the meta information in the request. The actual transfer must take place only after acceptance by the recipient.
o 发件人必须能够发送文件传输请求。收件人必须能够使用请求中的元信息接受或拒绝请求。实际转让必须在接收方接受后进行。
o It must be possible for the sender to pass some meta information on the file before the actual transfer. This must be able to include at least content type, size, hash, and name of the file, as well as a short (human readable) description.
o 在实际传输之前，发送方必须能够在文件上传递一些元信息。这必须至少包括文件的内容类型、大小、哈希和名称，以及简短的（人类可读的）描述。
o It must be possible for the recipient to request a file from the sender, providing meta information about the file. The sender must be able to decide whether to send a file matching the request.
o 收件人必须能够向发件人请求文件，并提供有关该文件的元信息。发件人必须能够决定是否发送与请求匹配的文件。
The rest of this document is organized as follows. Section 3 defines a few terms used in this document. Section 4 provides the overview of operation. Section 5 introduces the concept of the file selector. The detailed syntax and semantics of the new SDP attributes and conventions on how the existing ones are used are defined in Section 6. Section 7 discusses the file disposition types. Section 8 describes the protocol operation involving SDP and MSRP. Finally, some examples are given in Section 9.
本文件其余部分的组织如下。第3节定义了本文件中使用的几个术语。第4节提供了操作概述。第5节介绍了文件选择器的概念。第6节定义了新SDP属性的详细语法和语义以及如何使用现有属性的约定。第7节讨论了文件处理类型。第8节描述了涉及SDP和MSRP的协议操作。最后，第9节给出了一些示例。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
For the purpose of this document, the following definitions specified in RFC 3264 [RFC3264] apply:
就本文件而言，RFC 3264[RFC3264]中规定的以下定义适用：
o Answer
o 答复
o Answerer
o 回答者
o Offer
o 提供
o Offerer
o 报价人
Additionally, we define the following terms:
此外，我们定义了以下术语：
File sender: The endpoint that is willing to send a file to the file receiver.
文件发送方：愿意向文件接收方发送文件的端点。
File receiver: The endpoint that is willing to receive a file from the file sender.
文件接收方：愿意从文件发送方接收文件的端点。
File selector: A tuple of file attributes that the SDP offerer includes in the SDP in order to select a file at the SDP answerer. This is described in more detail in Section 5.
文件选择器：SDP报价人在SDP中包含的文件属性元组，用于在SDP应答人处选择文件。第5节对此进行了更详细的描述。
Push operation: A file transfer operation where the SDP offerer takes the role of the file sender and the SDP answerer takes the role of the file receiver.
推送操作：一种文件传输操作，其中SDP提供方担任文件发送方，SDP应答方担任文件接收方。
Pull operation: A file transfer operation where the SDP offerer takes the role of the file receiver and the SDP answerer takes the role of the file sender.
Pull操作：一种文件传输操作，其中SDP提供方担任文件接收方，SDP应答方担任文件发送方。
An SDP offerer creates an SDP body that contains the description of one or more files that the offerer wants to send or receive. The offerer sends the SDP offer to the remote endpoint. The SDP answerer can accept or reject the transfer of each of those files separately.
SDP报价人创建SDP正文，其中包含报价人希望发送或接收的一个或多个文件的描述。报价人向远程端点发送SDP报价。SDP应答器可以分别接受或拒绝这些文件的传输。
The actual file transfer is carried out using the Message Session Relay Protocol (MSRP) [RFC4975]. Each SDP "m=" line describes an MSRP media stream used to transfer a single file at a time. That is, the transfer of multiple simultaneous files requires multiple "m=" lines and corresponding MSRP media streams. It should be noted that multiple MSRP media streams can share a single transport layer connection, so this mechanism will not lead to excessive use of transport resources.
实际文件传输使用消息会话中继协议（MSRP）[RFC4975]执行。每个SDP“m=”行描述用于一次传输单个文件的MSRP媒体流。也就是说，同时传输多个文件需要多个“m=”行和相应的MSRP媒体流。应注意，多个MSRP媒体流可以共享单个传输层连接，因此该机制不会导致过度使用传输资源。
Each "m=" line for an MSRP media stream is accompanied with a few attributes describing the file to be transferred. If the file sender generates the SDP offer, the attributes describe a local file to be sent (push), and the file receiver can use this information to either accept or reject the transfer. However, if the SDP offer is generated by the file receiver, the attributes are intended to characterize a particular file that the file receiver is willing to get (pull) from the file sender. It is possible that the file sender does not have a matching file or does not want to send the file, in which case the offer is rejected.
MSRP媒体流的每一“m=”行都附带一些描述要传输的文件的属性。如果文件发送方生成SDP提供，则属性描述要发送的本地文件（推送），文件接收方可以使用此信息接受或拒绝传输。但是，如果SDP提供是由文件接收者生成的，则这些属性旨在描述文件接收者愿意从文件发送者处获取（拉取）的特定文件。文件发送者可能没有匹配的文件或不想发送文件，在这种情况下，报价被拒绝。
The attributes describing each file are provided in SDP by a set of new SDP attributes, most of which have been directly borrowed from MIME. This way, user agents can decide whether or not to accept a given file transfer based on the file's name, size, description, hash, icon (e.g., if the file is a picture), etc.
描述每个文件的属性在SDP中由一组新的SDP属性提供，其中大部分直接从MIME中借用。这样，用户代理可以根据文件的名称、大小、描述、哈希、图标（例如，如果文件是图片）等决定是否接受给定的文件传输。
SDP direction attributes (e.g., 'sendonly', 'recvonly') are used to indicate the direction of the transfer, i.e., whether the SDP offerer is willing to send or receive the file. Assuming that the answerer accepts the file transfer, the actual transfer of the files takes
SDP方向属性（例如，“sendonly”、“RecvoOnly”）用于指示传输方向，即SDP提供方是否愿意发送或接收文件。假设应答者接受文件传输，则文件的实际传输需要
place with ordinary MSRP. Note that the 'sendonly' and 'recvonly' attributes refer to the direction of MSRP SEND requests and do not preclude other protocol elements (such as 200 responses, REPORT requests, etc.).
使用普通MSRP放置。请注意，“sendonly”和“RecvoOnly”属性指的是MSRP发送请求的方向，并不排除其他协议元素（例如200个响应、报告请求等）。
In principle the file transfer can work even with an endpoint supporting only regular MSRP without understanding the extensions defined herein, in a particular case where that endpoint is both the SDP answerer and the file receiver. The regular MSRP endpoint answers the offer as it would answer any ordinary MSRP offer without paying attention to the extension attributes. In such a scenario, the user experience would, however, be reduced, since the recipient would not know (by any protocol means) the reason for the session and would not be able to accept/reject it based on the file attributes.
原则上，文件传输甚至可以与仅支持常规MSRP的端点一起工作，而不理解本文定义的扩展名，在该端点既是SDP应答器又是文件接收器的特定情况下。常规的MSRP端点响应报价，就像它响应任何普通MSRP报价一样，而不关注扩展属性。然而，在这种情况下，用户体验会减少，因为接收者不知道（通过任何协议手段）会话的原因，并且不能基于文件属性接受/拒绝会话。
When the file receiver generates the SDP offer, this SDP offer needs to unambiguously identify the requested file at the file sender. For this purpose, we introduce the notion of a file selector, which is a tuple composed of one or more of the following individual selectors: the name, size, type, and hash of the file. The file selector can include any number of selectors, so all four of them do not always need to be present.
当文件接收方生成SDP提供时，此SDP提供需要在文件发送方明确标识请求的文件。为此，我们引入了文件选择器的概念，它是由以下一个或多个选择器组成的元组：文件的名称、大小、类型和哈希。文件选择器可以包括任意数量的选择器，因此它们并不总是都需要存在。
The purpose of the file selector is to provide enough information about the file to the remote entity, so that both the local and the remote entity can refer to the same file. The file selector is encoded in a 'file-selector' media attribute in SDP. The formal syntax of the 'file-selector' media attribute is described in Figure 1.
文件选择器的作用是向远程实体提供有关文件的足够信息，以便本地实体和远程实体都可以引用同一文件。文件选择器编码在SDP中的“文件选择器”媒体属性中。图1描述了“文件选择器”媒体属性的形式语法。
The file selection process is applied to all the available files at the host. The process selects those files that match each of the selectors present in the 'file-selector' attribute. The result can be zero, one, or more files, depending on the presence of the mentioned selectors in the SDP and depending on the available files in a host. The file transfer mechanism specified in this document requires that a file selector eventually results at most in a single file to be chosen. Typically, if the hash selector is known, it is enough to produce a file selector that points to exactly zero or one file. However, a file selector that selects a unique file is not always known by the offerer. Sometimes only the name, size, or type of file is known, so the file selector may result in selecting more than one file, which is an undesired case. The opposite is also true: if the file selector contains a hash selector and a name selector, there is a risk that the remote host has renamed the file,
文件选择过程将应用于主机上的所有可用文件。该过程选择与“文件选择器”属性中的每个选择器匹配的文件。结果可以是零个、一个或多个文件，具体取决于SDP中所述选择器的存在以及主机中的可用文件。本文档中指定的文件传输机制要求文件选择器最终最多只能选择一个文件。通常，如果已知哈希选择器，则生成一个正好指向零或一个文件的文件选择器就足够了。但是，选择唯一文件的文件选择器并不总是为报价人所知。有时，只知道文件的名称、大小或类型，因此文件选择器可能会导致选择多个文件，这是不希望出现的情况。反之亦然：如果文件选择器包含哈希选择器和名称选择器，则存在远程主机重命名该文件的风险，
in which case, although a file whose computed hash equals the hash selector exists, the file name does not match that of the name selector. Thus, in this case, the file selection process will result in the selection of zero files.
在这种情况下，尽管存在计算出的哈希等于哈希选择器的文件，但文件名与名称选择器的文件名不匹配。因此，在这种情况下，文件选择过程将导致选择零个文件。
This specification uses the Secure Hash Algorithm 1, SHA-1 [RFC3174]. If future needs require adding support for different hashing algorithms, they will be specified as extensions to this document.
本规范使用安全哈希算法1，SHA-1[RFC3174]。如果将来需要添加对不同散列算法的支持，则将它们指定为本文档的扩展。
Implementations according to this specification MUST implement the 'file-selector' attribute and MAY implement any of the other attributes specified in this specification. SDP offers and answers for file transfer MUST contain a 'file-selector' media attribute that selects the file to be transferred and MAY contain any of the other attributes specified in this specification.
根据本规范的实现必须实现“文件选择器”属性，并且可以实现本规范中指定的任何其他属性。SDP文件传输提供和应答必须包含选择要传输的文件的“文件选择器”媒体属性，并且可能包含本规范中指定的任何其他属性。
The 'file-selector' media attribute is also useful when learning the support of the file transfer offer/answer capability that this document specifies. This is further explained in Section 8.5.
“文件选择器”媒体属性在学习本文档指定的文件传输提供/应答功能支持时也很有用。第8.5节对此作了进一步解释。
We define a number of new SDP [RFC4566] attributes that provide the required information to describe the transfer of a file with MSRP. These are all media-level-only attributes in SDP. The following is the formal ABNF syntax [RFC5234] of these new attributes. It is built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183 [RFC2183], RFC 2392 [RFC2392], and RFC 5322 [RFC5322].
我们定义了许多新的SDP[RFC4566]属性，这些属性提供了描述使用MSRP传输文件所需的信息。这些都是SDP中仅媒体级别的属性。以下是这些新属性的正式ABNF语法[RFC5234]。它构建在SDP[RFC4566]语法、RFC 2045[RFC2045]、RFC 2183[RFC2183]、RFC 2392[RFC2392]和RFC 5322[RFC5322]之上。
attribute =/ file-selector-attr / file-disp-attr /
file-tr-id-attr / file-date-attr /
file-icon-attr / file-range-attr
; attribute is defined in RFC 4566
attribute =/ file-selector-attr / file-disp-attr /
file-tr-id-attr / file-date-attr /
file-icon-attr / file-range-attr
; attribute is defined in RFC 4566
file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector = filename-selector / filesize-selector /
filetype-selector / hash-selector
file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector = filename-selector / filesize-selector /
filetype-selector / hash-selector
filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE defined in RFC 5234
filename-string = 1*(filename-char/percent-encoded)
filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF
; any byte except NUL, CR, LF,
; double quotes, or percent
percent-encoded = "%" HEXDIG HEXDIG
; HEXDIG defined in RFC 5234
filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE defined in RFC 5234
filename-string = 1*(filename-char/percent-encoded)
filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF
; any byte except NUL, CR, LF,
; double quotes, or percent
percent-encoded = "%" HEXDIG HEXDIG
; HEXDIG defined in RFC 5234
filesize-selector = "size:" filesize-value
filesize selector=“size:”文件大小值
filesize-value = integer ;integer defined in RFC 4566
filesize值=整数；RFC 4566中定义的整数
filetype-selector = "type:" type "/" subtype *(";" ft-parameter)
ft-parameter = attribute "=" DQUOTE value-string DQUOTE
; attribute is defined in RFC 2045
; free insertion of linear-white-space is not
; permitted in this context.
; note: value-string has to be re-encoded
; when translating between this and a
; Content-Type header.
value-string = filename-string
filetype-selector = "type:" type "/" subtype *(";" ft-parameter)
ft-parameter = attribute "=" DQUOTE value-string DQUOTE
; attribute is defined in RFC 2045
; free insertion of linear-white-space is not
; permitted in this context.
; note: value-string has to be re-encoded
; when translating between this and a
; Content-Type header.
value-string = filename-string
hash-selector = "hash:" hash-algorithm ":" hash-value
hash-algorithm = token ; see IANA Hash Function
; Textual Names registry
; only "sha-1" currently supported
hash-value = 2HEXDIG *(":" 2HEXDIG)
; Each byte in upper-case hex, separated
; by colons.
; HEXDIG defined in RFC 5234
hash-selector = "hash:" hash-algorithm ":" hash-value
hash-algorithm = token ; see IANA Hash Function
; Textual Names registry
; only "sha-1" currently supported
hash-value = 2HEXDIG *(":" 2HEXDIG)
; Each byte in upper-case hex, separated
; by colons.
; HEXDIG defined in RFC 5234
file-tr-id-attr = "file-transfer-id:" file-tr-id-value file-tr-id-value = token
file tr id attr=“file transfer id:”file tr id value file tr id value=token
file-disp-attr = "file-disposition:" file-disp-value file-disp-value = token
file disp attr=“file disposition:“file disp value file disp value=token”
file-date-attr = "file-date:" date-param *(SP date-param)
file-date-attr = "file-date:" date-param *(SP date-param)
date-param = c-date-param / m-date-param / r-date-param
c-date-param = "creation:" DQUOTE date-time DQUOTE
m-date-param = "modification:" DQUOTE date-time DQUOTE
r-date-param = "read:" DQUOTE date-time DQUOTE
; date-time is defined in RFC 5322
; numeric timezones (+HHMM or -HHMM)
; must be used
; DQUOTE defined in RFC 5234 files.
date-param = c-date-param / m-date-param / r-date-param
c-date-param = "creation:" DQUOTE date-time DQUOTE
m-date-param = "modification:" DQUOTE date-time DQUOTE
r-date-param = "read:" DQUOTE date-time DQUOTE
; date-time is defined in RFC 5322
; numeric timezones (+HHMM or -HHMM)
; must be used
; DQUOTE defined in RFC 5234 files.
file-icon-attr = "file-icon:" file-icon-value
file-icon-value = cid-url ; cid-url defined in RFC 2392
file-icon-attr = "file-icon:" file-icon-value
file-icon-value = cid-url ; cid-url defined in RFC 2392
file-range-attr = "file-range:" start-offset "-" stop-offset
start-offset = integer ; integer defined in RFC 4566
stop-offset = integer / "*"
file-range-attr = "file-range:" start-offset "-" stop-offset
start-offset = integer ; integer defined in RFC 4566
stop-offset = integer / "*"
Figure 1: Syntax of the SDP extension
图1:SDP扩展的语法
When used for capability query (see Section 8.5), the 'file-selector' attribute MUST NOT contain any selector, because its presence merely indicates compliance to this specification.
当用于能力查询时（参见第8.5节），“文件选择器”属性不得包含任何选择器，因为其存在仅表明符合本规范。
When used in an SDP offer or answer, the 'file-selector' attribute MUST contain at least one selector. Selectors characterize the file to be transferred. There are four selectors in this attribute: 'name', 'size', 'type', and 'hash'.
在SDP报价或应答中使用时，“文件选择器”属性必须至少包含一个选择器。选择器表示要传输的文件的特征。此属性中有四个选择器：“名称”、“大小”、“类型”和“哈希”。
The 'name' selector in the 'file-selector' attribute contains the filename of the content enclosed in double quotes. The filename is encoded in UTF-8 [RFC3629]. Its value SHOULD be the same as the 'filename' parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer. If a file name contains double quotes or any other character that the syntax does not allow in the 'name' selector, they MUST be percent-encoded. The 'name' selector MUST NOT contain characters that can be interpreted as directory structure by the local operating system. If such characters are present in the file name, they MUST be percent-encoded.
“文件选择器”属性中的“名称”选择器包含用双引号括起来的内容的文件名。文件名以UTF-8[RFC3629]编码。其值应与实际文件传输发出信号的内容处置头字段[RFC2183]的“filename”参数相同。如果文件名包含双引号或“名称”选择器中语法不允许的任何其他字符，则必须对其进行百分比编码。“名称”选择器不得包含可被本地操作系统解释为目录结构的字符。如果文件名中存在此类字符，则必须对其进行百分比编码。
Note that the 'name' selector might still contain characters that, although not meaningful for the local operating system, might still be meaningful to the remote operating system (e.g., '\', '/', ':'). Therefore, implementations are responsible for sanitizing the input received from the remote endpoint before doing a local operation in the local file system, such as the creation of a local file. Among other things, implementations can percent-encode characters that are meaningful to the local operating system before doing file system local calls.
请注意，“名称”选择器可能仍然包含对本地操作系统没有意义但对远程操作系统仍然有意义的字符（例如，“\”、“/”、“：”）。因此，在本地文件系统中执行本地操作（如创建本地文件）之前，实现负责清理从远程端点接收的输入。除此之外，在执行文件系统本地调用之前，实现可以对本地操作系统有意义的字符进行百分比编码。
The 'size' selector in the 'file-selector' attribute indicates the size of the file in octets. The value of this attribute SHOULD be the same as the 'size' parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer. Note that the 'size' selector merely includes the file size, and does not include any potential overhead added by a wrapper, such as message/cpim [RFC3862].
“文件选择器”属性中的“大小”选择器以八位字节表示文件的大小。此属性的值应与实际文件传输发出信号的内容处置头字段[RFC2183]的“大小”参数相同。请注意，“大小”选择器仅包括文件大小，不包括包装器（如message/cpim[RFC3862]）增加的任何潜在开销。
The 'type' selector in the 'file-selector' attribute contains the MIME media and submedia types of the content. In general, anything that can be expressed in a Content-Type header field (see RFC 2045 [RFC2045]) can also be expressed with the 'type' selectors. Possible MIME Media Type values are the ones listed in the IANA registry for MIME Media Types [IANA]. Zero or more parameters can follow. When
“文件选择器”属性中的“类型”选择器包含内容的MIME媒体和子媒体类型。通常，可以在内容类型标题字段中表示的任何内容（请参见RFC 2045[RFC2045]）也可以使用“类型”选择器表示。可能的MIME媒体类型值是在IANA注册表中列出的MIME媒体类型[IANA]的值。可以跟随零个或多个参数。什么时候
translating parameters from a Content-Type header and a 'type' selector, the parameter has to be re-encoded prior to its accommodation as a parameter of the 'type' selector (see the ABNF syntax of 'ft-parameter').
从内容类型标题和“类型”选择器转换参数时，必须对参数进行重新编码，然后才能将其作为“类型”选择器的参数（请参见“ft参数”的ABNF语法）。
The 'hash' selector in the 'file-selector' attribute provides a hash computation of the file to be transferred. This is commonly used by file transfer protocols. For example, FLUTE [FLUTE-REV] uses hashes (called message digests) to verify the contents of the transfer. The purpose of the 'hash' selector is two-fold: On one side, in pull operations, it allows the file receiver to identify a remote file by its hash rather than by its file name, providing that the file receiver has learned the hash of the remote file by some out-of-band mechanism. On the other side, in either push or pull operations, it allows the file receiver to verify the contents of the received file, or even avoid unnecessary transmission of an existing file.
“文件选择器”属性中的“哈希”选择器提供要传输的文件的哈希计算。这通常由文件传输协议使用。例如，FLUTE[FLUTE-REV]使用散列（称为消息摘要）来验证传输的内容。“散列”选择器的用途有两个：一方面，在拉操作中，它允许文件接收方通过其散列而不是文件名来识别远程文件，前提是文件接收方已通过一些带外机制了解了远程文件的散列。另一方面，在推或拉操作中，它允许文件接收器验证所接收文件的内容，甚至避免对现有文件进行不必要的传输。
The address space of the SHA-1 algorithm is big enough to avoid any collision in hash computations in between two endpoints. When transferring files, the actual file transfer protocol should provide reliable transmission of data, so verifications of received files should always succeed. However, if endpoints need to protect the integrity of a file, they should use some other mechanism than the 'hash' selector specified in this memo.
SHA-1算法的地址空间足够大，可以避免两个端点之间哈希计算中的任何冲突。传输文件时，实际的文件传输协议应提供可靠的数据传输，因此对接收到的文件的验证应始终成功。但是，如果端点需要保护文件的完整性，它们应该使用本备忘录中指定的“哈希”选择器以外的其他机制。
The 'hash' selector includes the hash algorithm and its value. Possible hash algorithms are those defined in the IANA registry of Hash Function Textual Names [IANA]. Implementations according to this specification MUST add a 160-bit string resulting from the computation of US Secure Hash Algorithm 1 (SHA1) [RFC3174] if the 'hash' selector is present. If need arises, extensions can be drafted to support several hashing algorithms. Therefore, implementations according to this specification MUST be prepared to receive SDP containing more than a single 'hash' selector in the 'file-selector' attribute.
“哈希”选择器包括哈希算法及其值。可能的哈希算法是在IANA哈希函数文本名称注册表[IANA]中定义的算法。如果存在“哈希”选择器，则根据本规范的实现必须添加一个160位字符串，该字符串是由美国安全哈希算法1（SHA1）[RFC3174]的计算产生的。如果需要，可以起草扩展来支持几种散列算法。因此，根据本规范的实现必须准备好接收SDP，该SDP在“文件选择器”属性中包含多个“散列”选择器。
The value of the 'hash' selector is the byte string resulting from applying the hash algorithm to the content of the whole file, even when the file transfer is limited to a number of octets (i.e., the 'file-range' attribute is indicated).
“散列”选择器的值是将散列算法应用于整个文件的内容而产生的字节字符串，即使文件传输限制为若干个八位字节（即，指示“文件范围”属性）。
The 'file-transfer-id' attribute provides a randomly chosen globally unique identification to the actual file transfer. It is used to distinguish a new file transfer request from a repetition of the SDP (or the fraction of the SDP that deals with the file description). This attribute is described in much greater detail in Section 8.1.
“文件传输id”属性为实际文件传输提供随机选择的全局唯一标识。它用于区分新的文件传输请求和重复的SDP（或处理文件描述的SDP部分）。该属性在第8.1节中有更详细的描述。
The 'file-disposition' attribute provides a suggestion to the other endpoint about the intended disposition of the file. Section 7 provides further discussion of the possible values. The value of this attribute SHOULD be the same as the disposition type parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer protocol.
“file disposition”属性向另一个端点提供关于文件的预期处置的建议。第7节进一步讨论了可能的值。此属性的值应与实际文件传输协议发出信号的内容处置头字段[RFC2183]的处置类型参数相同。
The 'file-date' attribute indicates the dates on which the file was created, modified, or last read. This attribute MAY contain a combination of the 'creation', 'modification', and 'read' parameters, but MUST NOT contain more than one of each type .
“文件日期”属性表示创建、修改或上次读取文件的日期。此属性可以包含“创建”、“修改”和“读取”参数的组合，但每种类型不能包含一个以上的参数。
The 'creation' parameter indicates the date on which the file was created. The value MUST be a quoted string that contains a representation of the creation date of the file in RFC 5322 [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. The value of this parameter SHOULD be the same as the 'creation-date' parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer protocol.
“creation”参数表示创建文件的日期。该值必须是带引号的字符串，其中包含RFC 5322[RFC5322]“日期-时间”格式的文件创建日期表示形式。必须使用数字时区（+HHMM或-HHMM）。此参数的值应与实际文件传输协议发出信号的内容处置头字段[RFC2183]的“创建日期”参数相同。
The 'modification' parameter indicates the date on which the file was last modified. The value MUST be a quoted string that contains a representation of the last modification date to the file in RFC 5322 [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. The value of this parameter SHOULD be the same as the 'modification-date' parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer protocol.
“修改”参数表示上次修改文件的日期。该值必须是带引号的字符串，其中包含RFC 5322[RFC5322]“日期-时间”格式的文件最后修改日期的表示形式。必须使用数字时区（+HHMM或-HHMM）。此参数的值应与实际文件传输协议发出信号的内容处置头字段[RFC2183]的“修改日期”参数相同。
The 'read' parameter indicates the date on which the file was last read. The value MUST be a quoted string that contains a representation of the last date the file was read in RFC 5322 [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. The value of this parameter SHOULD be the same as the 'read-date' parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer protocol.
“read”参数表示上次读取文件的日期。该值必须是带引号的字符串，其中包含以RFC 5322[RFC5322]“日期-时间”格式读取文件的最后日期的表示形式。必须使用数字时区（+HHMM或-HHMM）。此参数的值应与实际文件传输协议发出信号的内容处置头字段[RFC2183]的“读取日期”参数相同。
The 'file-icon' attribute can be useful with certain file types such as images. It allows the file sender to include a pointer to a body that includes a small preview icon representing the contents of the file to be transferred, which the file receiver can use to determine whether it wants to receive such file. The 'file-icon' attribute contains a Content-ID URL, which is specified in RFC 2392 [RFC2392]. Section 8.8 contains further considerations about the 'file-icon' attribute.
“文件图标”属性对于某些文件类型（如图像）非常有用。它允许文件发送方包含指向正文的指针，正文中包含一个表示要传输的文件内容的小预览图标，文件接收方可以使用该图标确定是否要接收此类文件。“文件图标”属性包含RFC 2392[RFC2392]中指定的内容ID URL。第8.8节包含关于“文件图标”属性的进一步考虑。
The 'file-range' attribute provides a mechanism to signal a chunk of a file rather than the complete file. This enables use cases where a file transfer can be interrupted and resumed, even perhaps changing one of the endpoints. The 'file-range' attribute contains the "start offset" and "stop offset" of the file, separated by a dash "-". The "start offset" value refers to the octet position of the file where the file transfer should start. The first octet of a file is denoted by the ordinal number "1". The "stop offset" value refers to the octet position of the file where the file transfer should stop, inclusive of this octet. The "stop offset" value MAY contain a "*" if the total size of the file is not known in advance. The absence of this attribute indicates a complete file, i.e., as if the 'file-range' attribute would have been present with a value "1-*". The 'file-range' attribute must not be confused with the Byte-Range header in MSRP. The former indicates the portion of a file that the application would read and pass onto the MSRP stack for transportation. From the point of view of MSRP, the portion of the file is viewed as a whole message. The latter indicates the number of bytes of that message that are carried in a chunk and the total size of the message. Therefore, MSRP starts counting the delivered message at octet number 1, independently of the position of that octet in the file.
“文件范围”属性提供了一种机制，用于向文件块而不是整个文件发送信号。这使得文件传输可以中断和恢复，甚至可能更改一个端点。“文件范围”属性包含文件的“开始偏移量”和“停止偏移量”，用破折号“-”分隔。“开始偏移量”值是指文件传输应开始的八位字节位置。文件的第一个八位字节由序号“1”表示。“停止偏移量”值指文件传输应停止的八位位元位置，包括该八位位元。如果事先不知道文件的总大小，“停止偏移量”值可能包含“*”。缺少此属性表示文件完整，即“文件范围”属性的值为“1-*”。“文件范围”属性不得与MSRP中的字节范围标头混淆。前者表示应用程序将读取并传递到MSRP堆栈以进行传输的文件部分。从MSRP的角度来看，文件的部分被视为一个完整的消息。后者表示该消息在块中承载的字节数和消息的总大小。因此，MSRP开始在第1个八位元处计算传递的消息，与该八位元在文件中的位置无关。
The following is an example of an SDP body that contains the extensions defined in this memo:
以下是包含本备忘录中定义的扩展的SDP正文示例：
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:32349 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=file-disposition:attachment
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com
a=file-range:1-32349
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:32349 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=file-disposition:attachment
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com
a=file-range:1-32349
Figure 2: Example of SDP describing a file transfer
图2：描述文件传输的SDP示例
NOTE: The 'file-selector' attribute in the above figure is split in three lines for formatting purposes. Real implementations will encode it in a single line.
注意：上图中的“文件选择器”属性分为三行，用于格式化。真正的实现将在一行中对其进行编码。
The SDP offer/answer for file transfer allows the file sender to indicate a preferred disposition of the file to be transferred in a new 'file-disposition' attribute. In principle, any value listed in the IANA registry for Mail Content Disposition Values [IANA] is acceptable; however, most of them may not be applicable.
文件传输的SDP提供/应答允许文件发送者在新的“文件处置”属性中指示要传输的文件的首选处置。原则上，IANA注册表中列出的邮件内容处置值[IANA]的任何值都是可以接受的；但是，其中大多数可能不适用。
There are two content dispositions of interest for file transfer operations. On one hand, the file sender may just want the file to be rendered immediately in the file receiver's device. On the other hand, the file sender may just want to indicate to the file receiver that the file should not be rendered at the reception of the file. The recipient's user agent may want to interact with the user regarding the file disposition or it may save the file until the user takes an action. In any case, the exact actions are implementation dependent.
文件传输操作有两种感兴趣的内容处理。一方面，文件发送方可能只希望文件立即在文件接收方的设备中呈现。另一方面，文件发送方可能只想向文件接收方指示不应在接收文件时呈现文件。收件人的用户代理可能希望与用户就文件处置进行交互，或者可能会在用户采取操作之前保存文件。在任何情况下，具体操作都取决于实现。
To indicate that a file should be automatically rendered, this memo uses the existing 'render' value of the Content Disposition type in the new 'file-disposition' attribute in SDP. To indicate that a file should not be automatically rendered, this memo uses the existing 'attachment' value of the Content-Disposition type in the new 'file-disposition' attribute in SDP. The default value is 'render', i.e., the absence of a 'file-disposition' attribute in the SDP has the same semantics as 'render'.
为了指示应自动呈现文件，此备忘录使用SDP中新的“文件处置”属性中内容处置类型的现有“呈现”值。为了指示不应自动呈现文件，此备忘录使用SDP中新的“文件处置”属性中内容处置类型的现有“附件”值。默认值为“render”，即SDP中没有“file disposition”属性的语义与“render”相同。
The disposition value 'attachment' is specified in RFC 2183 [RFC2183] with the following definition:
处置值“附件”在RFC 2183[RFC2183]中有以下定义：
"Body parts can be designated 'attachment' to indicate that they are separate from the main body of the mail message, and that their display should not be automatic, but contingent upon some further action of the user."
正文部分可以指定为“附件”，以表明它们与邮件正文是分开的，并且它们的显示不应该是自动的，而是取决于用户的进一步操作
In the case of this specification, the 'attachment' disposition type is used to indicate that the display of the file should not be automatic, but contingent upon some further action of the user.
在本规范中，“附件”处置类型用于指示文件的显示不应是自动的，而是取决于用户的某些进一步操作。
This section discusses how to use the parameters defined in Section 6 in the context of an offer/answer [RFC3264] exchange. Additionally, this section also discusses the behavior of the endpoints using MSRP.
本节讨论如何在要约/应答[RFC3264]交换的上下文中使用第6节中定义的参数。此外，本节还讨论了使用MSRP的端点的行为。
A file transfer session is initiated by the offerer sending an SDP offer to the answerer. The answerer either accepts or rejects the file transfer session and sends an SDP answer to the offerer.
文件传输会话由报价人向应答人发送SDP报价发起。应答者接受或拒绝文件传输会话，并向报价人发送SDP应答。
We can differentiate two use cases, depending on whether the offerer is the file sender or file receiver:
根据提供方是文件发送方还是文件接收方，我们可以区分两种用例：
1. The offerer is the file sender, i.e., the offerer wants to transmit a file to the answerer. Consequently, the answerer is the file receiver. In this case, the SDP offer contains a 'sendonly' attribute, and accordingly the SDP answer contains a 'recvonly' attribute.
1. 报价人是文件发送者，即报价人希望向应答人发送文件。因此，应答者就是文件接收者。在这种情况下，SDP提供包含“sendonly”属性，因此SDP应答包含“recvonly”属性。
2. The offerer is the file receiver, i.e., the offerer wants to fetch a file from the answerer. Consequently, the answerer is the file sender. In this case, the SDP offer contains a session or media 'recvonly' attribute, and accordingly the SDP answer contains a session or media 'sendonly' attribute.
2. 报价人是文件接收人，即报价人希望从应答人处获取文件。因此，应答者就是文件发送者。在这种情况下，SDP选项包含会话或媒体“recvonly”属性，因此SDP应答包含会话或媒体“sendonly”属性。
This specification creates an extension to the SDP offer/answer model [RFC3264], and because of that, it is assumed that the existing SDP behavior is kept intact. The SDP behavior requires, for example, that SDP is sent again to the remote party in situations where the media description or perhaps other SDP parameters have not changed with respect to a previous offer/answer exchange. Let's consider the SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITE requests to refresh sessions. RFC 4028 recommends to send unmodified SDP in a re-INVITE to refresh the session. Should this re-INVITE contain SDP describing a file transfer operation and occur while the file transfer was still going on, there would be no means to detect whether the SDP creator wanted to abort the current file transfer operation and initiate a new one or the SDP file description was included in the SDP due to other reasons (e.g., session timer refresh).
本规范创建了SDP提供/应答模型[RFC3264]的扩展，因此，假定现有SDP行为保持不变。例如，SDP行为要求在媒体描述或其他SDP参数相对于先前的提供/应答交换没有改变的情况下，将SDP再次发送给远程方。让我们考虑SIP会话定时器（RFC 4028）[RFC4028 ]，它使用重新邀请请求刷新会话。RFC 4028建议在重新邀请中发送未修改的SDP以刷新会话。如果此重新邀请包含描述文件传输操作的SDP，并且在文件传输仍在进行时发生，则无法检测SDP创建者是否希望中止当前文件传输操作并启动新的文件传输操作，或者SDP文件描述由于其他原因包含在SDP中（例如，会话计时器刷新）。
A similar scenario occurs when two endpoints have successfully agreed on a file transfer, which is currently taking place when one of the endpoints wants to add additional media streams to the existing session. In this case, the endpoint sends a re-INVITE request that contains the SDP. The SDP needs to maintain the media descriptions for the current ongoing file transfer and add the new media descriptions. The problem is that the other endpoint is not able to determine whether or not a new file transfer is requested.
当两个端点成功地就文件传输达成一致意见时，也会出现类似的情况。当前，当其中一个端点希望向现有会话添加其他媒体流时，会发生这种情况。在这种情况下，端点发送一个包含SDP的重新邀请请求。SDP需要维护当前正在进行的文件传输的介质描述，并添加新的介质描述。问题是另一个端点无法确定是否请求新的文件传输。
In other cases, a file transfer was successfully completed. Then, if an endpoint resends the SDP offer with the media stream for the file transfer, then the other endpoint wouldn't be able to determine whether or not a new file transfer should start.
在其他情况下，文件传输已成功完成。然后，如果一个端点使用文件传输的媒体流重新发送SDP提供，那么另一个端点将无法确定是否应该开始新的文件传输。
To address these scenarios, this specification defines the 'file-transfer-id' attribute, which contains a globally unique random identifier allocated to the file transfer operation. The file transfer identifier helps both endpoints to determine whether the SDP offer is requesting a new file transfer or it is a repetition of the SDP. A new file transfer is one that, in case of acceptance, will provoke the actual transfer of a file. This is typically the case of new offer/answer exchanges, or in cases where an endpoint wants to abort the existing file transfer and restart the file transfer once more. On the other hand, the repetition of the SDP does not lead to any actual file to be transferred, potentially because the file transfer is still going on or because it has already finished. This is the case of repeated offer/answer exchanges, which can be due to a number of reasons (session timer, addition/removal of other media types in the SDP, update in SDP due to changes in other session parameters, etc.).
为了解决这些情况，本规范定义了“文件传输id”属性，该属性包含分配给文件传输操作的全局唯一随机标识符。文件传输标识符帮助两个端点确定SDP提供是请求新的文件传输还是重复SDP。新的文件传输是指，在接受的情况下，将引发文件的实际传输。这通常是新的提供/应答交换的情况，或者端点希望中止现有文件传输并再次重新启动文件传输的情况。另一方面，重复SDP不会导致传输任何实际文件，这可能是因为文件传输仍在进行或已经完成。这是重复提供/应答交换的情况，这可能是由于多种原因造成的（会话计时器、SDP中其他媒体类型的添加/删除、由于其他会话参数的更改而在SDP中更新等）。
Implementations according to this specification MUST include a 'file-transfer-id' attribute in SDP offers and answers. The SDP offerer MUST select a file transfer identifier according to the syntax and add it to the 'file-transfer-id' attribute. The SDP answerer MUST copy the value of the 'file-transfer-id' attribute in the SDP answer.
根据本规范的实现必须在SDP报价和应答中包含“文件传输id”属性。SDP报价人必须根据语法选择文件传输标识符，并将其添加到“文件传输id”属性中。SDP应答器必须复制SDP应答中“文件传输id”属性的值。
The file transfer identifier MUST be unique within the current session (never used before in this session), and it is RECOMMENDED to be unique across different sessions. It is RECOMMENDED to select a relatively big random identifier (e.g., 32 characters) to avoid duplications. The SDP answerer MUST keep track of the proposed file transfer identifiers in each session and copy the value of the received file transfer identifier in the SDP answer.
文件传输标识符在当前会话中必须是唯一的（在此会话中以前从未使用过），建议在不同会话中保持唯一。建议选择相对较大的随机标识符（例如32个字符），以避免重复。SDP应答者必须在每个会话中跟踪建议的文件传输标识符，并在SDP应答中复制接收到的文件传输标识符的值。
If a file transfer is suspended and resumed at a later time, the resumption is considered a new file transfer (even when the file to be transferred is the same); therefore, the SDP offerer MUST choose a new file transfer identifier.
如果文件传输被暂停并在以后恢复，则恢复被视为新的文件传输（即使要传输的文件相同）；因此，SDP提供方必须选择新的文件传输标识符。
If an endpoint sets the port number to zero in the media description of a file transfer, for example, because it wants to reject the file transfer operation, then the SDP answer MUST mirror the value of the 'file-transfer-id' attribute included in the SDP offer. This effectively means that setting a media stream to zero has higher precedence than any value that the 'file-transfer-id' attribute can take.
如果端点在文件传输的媒体描述中将端口号设置为零，例如，因为它想要拒绝文件传输操作，那么SDP应答必须镜像SDP提供中包含的“文件传输id”属性的值。这实际上意味着将媒体流设置为零的优先级高于“文件传输id”属性可以采用的任何值。
As a side effect, the 'file-transfer-id' attribute can be used for aborting and restarting again an ongoing file transfer. Assume that two endpoints agree on a file transfer and the actual transfer of the file is taking place. At some point in time in the middle of the file transfer, one endpoint sends a new SDP offer, equal to the initial one except for the value of the 'file-transfer-id' attribute, which is a new globally unique random value. This indicates that the offerer wants to abort the existing transfer and start a new one, according to the SDP parameters. The SDP answerer SHOULD abort the ongoing file transfer, according to the procedures of the file transfer protocol (e.g., MSRP), and start sending file once more from the initial requested octet. Section 8.4 further discusses aborting a file transfer.
作为副作用，“文件传输id”属性可用于中止并重新启动正在进行的文件传输。假设两个端点同意文件传输，并且文件的实际传输正在进行。在文件传输中间的某个时间点，一个端点发送一个新的SDP要约，等于初始文件，除了“文件传输ID”属性的值，这是一个新的全局唯一随机值。这表示报价人希望根据SDP参数中止现有的传输并开始新的传输。SDP应答器应根据文件传输协议（如MSRP）的程序中止正在进行的文件传输，并从最初请求的八位字节再次开始发送文件。第8.4节进一步讨论了中止文件传输。
If an endpoint creates an SDP offer where the 'file-transfer-id' attribute value does not change with respect to a previously sent one, but the file selector changes so that a new file is selected, then this is considered an error, and the SDP answerer MUST abort the file transfer operation (e.g., by setting the port number to zero in the SDP answer). Note that endpoints MAY change the 'file-selector' attribute as long as the selected file does not change (e.g., by adding a hash selector); however, it is RECOMMENDED that endpoints do not change the value of the 'file-selector' attribute if it is requested to transfer the same file described in a previous SDP offer/answer exchange.
如果端点创建SDP提供，其中“文件传输id”属性值相对于以前发送的文件没有更改，但文件选择器更改，从而选择了新文件，则这被视为错误，SDP应答器必须中止文件传输操作（例如，通过在SDP应答中将端口号设置为零）。请注意，只要所选文件不变，端点可能会更改“文件选择器”属性（例如，通过添加哈希选择器）；但是，如果请求端点传输先前SDP提供/应答交换中描述的相同文件，则建议端点不要更改“文件选择器”属性的值。
Figure 3 summarizes the relation of the 'file-transfer-id' attribute with the file selector in subsequent SDP exchanges.
图3总结了“file transfer id”属性与后续SDP交换中的文件选择器的关系。
\ | | |
\ file selector | different | same |
'file-transfer-id' \ | file | file |
==================================+=============+===============+
| new file | new file |
changed | transfer | transfer |
| operation | operation |
----------------------------------+-------------+---------------+
| | existing file |
unchanged | error | transfer |
| | operation |
----------------------------------+-------------+---------------+
\ | | |
\ file selector | different | same |
'file-transfer-id' \ | file | file |
==================================+=============+===============+
| new file | new file |
changed | transfer | transfer |
| operation | operation |
----------------------------------+-------------+---------------+
| | existing file |
unchanged | error | transfer |
| | operation |
----------------------------------+-------------+---------------+
Figure 3: Relation of the 'file-transfer-id' attribute with the selector of the file in a subsequent SDP exchange
图3：“文件传输id”属性与后续SDP交换中文件选择器的关系
In another scenario, an endpoint that has successfully transferred a file wants to send an SDP due to other reasons than the transfer of a file. The SDP offerer creates an SDP file description that maintains
在另一种情况下，已成功传输文件的端点由于文件传输以外的其他原因希望发送SDP。SDP报价人创建一个SDP文件描述，用于维护
the media description line corresponding to the file transfer. The SDP offerer MUST then set the port number to zero and MUST keep the same value of the 'file-transfer-id' attribute that the initial file transfer got.
与文件传输相对应的介质描述行。然后，SDP提供者必须将端口号设置为零，并且必须保持初始文件传输获得的“文件传输id”属性的相同值。
An offerer who wishes to send or receive one or more files to or from an answerer MUST build an SDP [RFC4566] description of a session containing one "m=" line per file. When MSRP is used as the transfer mechanism, each "m=" line also describes a single MSRP session, according to the MSRP [RFC4975] procedures. Any "m=" lines that may have already been present in a previous SDP exchange are normally kept unmodified; the new "m=" lines are added afterwards (Section 8.6 describes cases when "m=" lines are reused). All the media line attributes specified and required by MSRP [RFC4975] (e.g., "a=path", "a=accept-types", etc.) MUST be included as well.
希望向应答者发送或接收一个或多个文件或从应答者接收一个或多个文件的报价人必须构建会话的SDP[RFC4566]描述，每个文件包含一行。当MSRP用作传输机制时，根据MSRP[RFC4975]程序，每个“m=”行还描述单个MSRP会话。以前SDP交换中可能已经存在的任何“m=”行通常保持不变；之后添加新的“m=”行（第8.6节描述了“m=”行被重用的情况）。还必须包括MSRP[RFC4975]指定和要求的所有媒体行属性（例如，“a=路径”、“a=接受类型”等）。
In a push operation, the file sender creates an SDP offer describing the file to be sent. The file sender MUST add a 'file-selector' attribute media line containing at least one of the 'type', 'size', or 'hash' selectors in indicating the type, size, or hash of the file, respectively. If the file sender wishes to start a new file transfer, the file sender MUST add a 'file-transfer-id' attribute containing a new globally unique random identifier value. Additionally, the file sender MUST add a session or media 'sendonly' attribute to the SDP offer. Then the file sender sends the SDP offer to the file receiver.
在推送操作中，文件发送者创建描述要发送的文件的SDP提供。文件发送者必须添加“文件选择器”属性媒体行，其中至少包含一个“类型”、“大小”或“哈希”选择器，分别指示文件的类型、大小或哈希。如果文件发送方希望开始新的文件传输，则文件发送方必须添加一个“文件传输id”属性，该属性包含一个新的全局唯一随机标识符值。此外，文件发送者必须将会话或媒体“sendonly”属性添加到SDP服务中。然后，文件发送方将SDP报价发送给文件接收方。
Not all the selectors in the 'file-selector' attribute might be known when the file sender creates the SDP offer, for example, because the host is still processing the file.
例如，当文件发送方创建SDP提供时，“文件选择器”属性中的所有选择器可能都未知，因为主机仍在处理该文件。
The 'hash' selector in the 'file-selector' attribute contains valuable information for the file receiver to identify whether the file is already available and need not be transmitted.
“文件选择器”属性中的“哈希”选择器包含有价值的信息，可供文件接收者识别文件是否已可用且无需传输。
The file sender MAY also add a 'name' selector in the 'file-selector' attribute, and 'file-icon', 'file-disposition', and 'file-date' attributes further describing the file to be transferred. The 'file-disposition' attribute provides a presentation suggestion (for example: the file sender would like the file receiver to render the file or not). The three date attributes provide the answerer with an indication of the age of the file. The file sender MAY also add a 'file-range' attribute indicating the start and stop offsets of the file.
文件发送者还可以在“文件选择器”属性中添加“名称”选择器，以及进一步描述要传输的文件的“文件图标”、“文件处置”和“文件日期”属性。“文件处置”属性提供了表示建议（例如：文件发送者希望文件接收者呈现文件或不呈现文件）。这三个日期属性为应答者提供了文件年龄的指示。文件发送方还可以添加“文件范围”属性，指示文件的开始和停止偏移量。
When the file sender receives the SDP answer, if the port number of the answer for a file request is non-zero, the file sender starts the transfer of the file according to the negotiated parameters in SDP.
当文件发送方收到SDP应答时，如果文件请求应答的端口号为非零，则文件发送方将根据SDP中协商的参数开始文件传输。
In a pull operation, the file receiver creates the SDP offer and sends it to the file sender. The file receiver MUST include a 'file-selector' attribute and MUST include, at least, one of the selectors defined for such attribute (i.e., 'name', 'type', 'size', or 'hash'). In many cases, if the hash of the file is known, that is enough to identify the file; therefore, the offerer can include only a 'hash' selector. However, particularly in cases where the hash of the file is unknown, the file name, size, and type can provide a description of the file to be fetched. If the file receiver wishes to start a new file transfer, it MUST add a 'file-transfer-id' attribute containing a new globally unique random value. The file receiver MAY also add a 'file-range' attribute indicating the start and stop offsets of the file. There is no need for the file receiver to include further file attributes in the SDP offer; thus, it is RECOMMENDED that SDP offerers do not include any other file attribute defined by this specification (other than the mandatory ones). Additionally, the file receiver MUST add a session or media 'recvonly' attribute in the SDP offer. Then, the file receiver sends the SDP offer to the file sender.
在拉操作中，文件接收方创建SDP提供并将其发送给文件发送方。文件接收方必须包括“文件选择器”属性，并且必须至少包括为该属性定义的选择器之一（即，“名称”、“类型”、“大小”或“哈希”）。在许多情况下，如果已知文件的散列，就足以识别该文件；因此，报价人只能包含一个“散列”选择器。但是，特别是在文件的哈希未知的情况下，文件名、大小和类型可以提供要获取的文件的描述。如果文件接收方希望开始新的文件传输，则必须添加一个“文件传输id”属性，该属性包含一个新的全局唯一随机值。文件接收器还可以添加“文件范围”属性，指示文件的开始和停止偏移。文件接收者不需要在SDP提供中包括进一步的文件属性；因此，建议SDP提供程序不包括本规范定义的任何其他文件属性（强制属性除外）。此外，文件接收器必须在SDP提供中添加会话或媒体“recvonly”属性。然后，文件接收方将SDP报价发送给文件发送方。
When the file receiver receives the SDP answer, if the port number of the answer for a file request is non-zero, then the file receiver should receive the file using the protocol indicated in the "m=" line. If the SDP answer contains a supported hashing algorithm in the 'hash' selectors of the 'file-selector' attribute, then the file receiver SHOULD compute the hash of the file after its reception and check it against the hash received in the answer. In case the computed hash does not match the one contained in the SDP answer, the file receiver SHOULD consider that the file transfer failed and SHOULD inform the user. Similarly, the file receiver SHOULD also verify that the other selectors declared in the SDP match the file properties, otherwise, the file receiver SHOULD consider that the file transfer failed and SHOULD inform the user.
当文件接收方收到SDP应答时，如果文件请求应答的端口号为非零，则文件接收方应使用“m=”行中指示的协议接收文件。如果SDP应答在“文件选择器”属性的“散列”选择器中包含受支持的散列算法，则文件接收方应在收到文件后计算该文件的散列，并对照应答中接收到的散列进行检查。如果所计算的散列与SDP应答中包含的一个不匹配，则文件接收器应该考虑文件传输失败并通知用户。类似地，文件接收器还应验证SDP中声明的其他选择器与文件属性匹配，否则，文件接收器应考虑文件传输失败，并应通知用户。
An offerer that wishes to send or receive more than one file generates an "m=" line per file along with the file attributes described in this specification. This way, the answerer can reject individual files by setting the port number of their associated "m=" lines to zero, as per regular SDP [RFC4566] procedures. Similarly, the answerer can accept each individual file separately by setting
希望发送或接收多个文件的报价人将为每个文件生成一个“m=”行，以及本规范中描述的文件属性。通过这种方式，应答者可以根据常规SDP[RFC4566]程序，通过将相关“m=”行的端口号设置为零来拒绝单个文件。同样，应答者可以通过设置
the port number of their associated "m=" lines to non-zero value. Each file has its own file transfer identifier, which uniquely identifies each file transfer.
将其关联的“m=”行的端口号设置为非零值。每个文件都有自己的文件传输标识符，它唯一地标识每个文件传输。
Using an "m=" line per file implies that different files are transferred using different MSRP sessions. However, all those MSRP sessions can be set up to run over a single TCP connection, as described in Section 8.1 of RFC 4975 [RFC4975]. The same TCP connection can also be reused for sequential file transfers.
每个文件使用“m=”行意味着使用不同的MSRP会话传输不同的文件。但是，所有这些MSRP会话都可以设置为通过单个TCP连接运行，如RFC 4975[RFC4975]第8.1节所述。同样的TCP连接也可以用于顺序文件传输。
If the answerer wishes to reject a file offered by the offerer, it sets the port number of the "m=" line associated with the file to zero, as per regular SDP [RFC4566] procedures. The rejected answer MUST contained a 'file-selector' and 'file-transfer-id' attributes whose values mirror the corresponding values of the SDP offer.
如果应答方希望拒绝报价方提供的文件，则按照常规SDP[RFC4566]程序，将与该文件关联的“m=”行的端口号设置为零。被拒绝的答案必须包含“文件选择器”和“文件传输id”属性，其值反映SDP报价的相应值。
If the answerer decides to accept the file, it proceeds as per regular MSRP [RFC4975] and SDP [RFC4566] procedures.
如果应答者决定接受该文件，则按照常规MSRP[RFC4975]和SDP[RFC4566]程序进行。
In a push operation, the SDP answerer is the file receiver. When the file receiver gets the SDP offer, it first examines the port number. If the port number is set to zero, the file transfer operation is closed, and no more data is expected over the media stream. Then, if the port number is different than zero, the file receiver inspects the 'file-transfer-id' attribute. If the value of the 'file-transfer-id' attribute has been previously used, then the existing session remains without changes; perhaps the file transfer is still in progress, or perhaps it has concluded, but there are no changes with respect to the current status. In any case, independently of the port number, the SDP answerer creates a regular SDP answer and sends it to the offerer.
在推送操作中，SDP应答器是文件接收器。当文件接收器获得SDP提供时，它首先检查端口号。如果端口号设置为零，则文件传输操作将关闭，并且媒体流上不需要更多数据。然后，如果端口号不同于零，则文件接收方将检查“文件传输id”属性。如果以前使用过“文件传输id”属性的值，则现有会话保持不变；也许文件传输仍在进行中，或者已经结束，但当前状态没有变化。在任何情况下，独立于端口号，SDP应答器创建常规SDP应答并将其发送给报价人。
If the port number is different than zero and the SDP offer contains a new 'file-transfer-id' attribute, then it is signaling a request for a new file transfer. The SDP answerer extracts the attributes and parameters that describe the file and typically requests permission from the user to accept or reject the reception of the file. If the file transfer operation is accepted, the file receiver MUST create an SDP answer according to the procedures specified in RFC 3264 [RFC3264]. If the offer contains 'name', 'type', or 'size' selectors in the 'file-selector' attribute, the answerer MUST copy them into the answer. The file receiver copies the value of the 'file-transfer-id' attribute to the SDP answer. Then the file receiver MUST add a session or media 'recvonly' attribute according
如果端口号不同于零，并且SDP提供包含一个新的“文件传输id”属性，那么它将发出新文件传输请求的信号。SDP应答器提取描述文件的属性和参数，通常请求用户允许接受或拒绝接收文件。如果接受文件传输操作，则文件接收器必须根据RFC 3264[RFC3264]中指定的步骤创建SDP应答。如果报价在“文件选择器”属性中包含“名称”、“类型”或“大小”选择器，则应答者必须将其复制到应答中。文件接收方将“文件传输id”属性的值复制到SDP应答。然后，文件接收器必须根据需要添加会话或媒体“recvonly”属性
to the procedures specified in RFC 3264 [RFC3264]. The file receiver MUST NOT include 'file-icon', 'file-disposition', or 'file-date' attributes in the SDP answer.
按照RFC 3264[RFC3264]中规定的程序进行。文件接收者不得在SDP应答中包含“文件图标”、“文件处置”或“文件日期”属性。
The file receiver can use the hash to find out if a local file with the same hash is already available, in which case, this could imply the reception of a duplicated file. It is up to the answerer to determine whether or not the file transfer is accepted in case of a duplicated file.
文件接收者可以使用散列来确定具有相同散列的本地文件是否已经可用，在这种情况下，这可能意味着接收到重复的文件。如果文件重复，则由应答者确定是否接受文件传输。
If the SDP offer contains a 'file-range' attribute and the file receiver accepts to receive the range of octets declared in there, the file receiver MUST include a 'file-range' attribute in the SDP answer with the same range of values. If the file receiver does not accept the reception of that range of octets, it SHOULD reject the transfer of the file.
如果SDP报价包含“文件范围”属性，并且文件接收方接受接收其中声明的八位字节范围，则文件接收方必须在SDP应答中包含具有相同值范围的“文件范围”属性。如果文件接收器不接受该范围的八位字节的接收，则应拒绝文件传输。
When the file transfer operation is complete, the file receiver computes the hash of the file and SHOULD verify that it matches the hash declared in the SDP. If they do not match, the file receiver SHOULD consider that the file transfer failed and SHOULD inform the user. Similarly, the file receiver SHOULD also verify that the other selectors declared in the SDP match the file properties; otherwise, the file receiver SHOULD consider that the file transfer failed and SHOULD inform the user.
文件传输操作完成后，文件接收方计算文件的哈希值，并应验证它是否与SDP中声明的哈希值匹配。如果它们不匹配，则文件接收器应考虑文件传输失败，并应通知用户。类似地，文件接收方还应验证SDP中声明的其他选择器是否与文件属性匹配；否则，文件接收方应考虑文件传输失败，并通知用户。
In a pull operation the answerer is the file sender. In this case, the SDP answerer MUST first inspect the value of the 'file-transfer-id' attribute. If it has not been previously used throughout the session, then acceptance of the file MUST provoke the transfer of the file over the negotiated protocol. However, if the value has been previously used by another file transfer operation within the session, then the file sender MUST NOT alert the user and MUST NOT start a new transfer of the file. No matter whether or not an actual file transfer is initiated, the file sender MUST create a proper SDP answer that contains the 'file-transfer-id' attribute with the same value received in the SDP offer, and then it MUST continue processing the SDP answer.
在拉操作中，应答者是文件发送者。在这种情况下，SDP应答器必须首先检查“文件传输id”属性的值。如果之前在整个会话中未使用过该文件，则接受该文件必须促使通过协商协议传输该文件。但是，如果该值以前已被会话中的另一个文件传输操作使用，则文件发送者不得通知用户，也不得开始新的文件传输。无论是否启动了实际的文件传输，文件发送方都必须创建一个正确的SDP应答，该应答包含“文件传输id”属性，该属性的值与SDP报价中接收到的值相同，然后必须继续处理SDP应答。
The file sender MUST always create an SDP answer according to the SDP offer/answer procedures specified in RFC 3264 [RFC3264]. The file sender inspects the file selector of the received SDP offer, which is encoded in the 'file-selector' media attribute line. Then the file sender applies the file selector, which implies selecting those files that match one by one with the 'name', 'type', 'size', and 'hash' selectors of the 'file-selector' attribute line (if they are
文件发送方必须始终根据RFC 3264[RFC3264]中指定的SDP提供/应答过程创建SDP应答。文件发送方检查收到的SDP提供的文件选择器，该文件选择器编码在“文件选择器”媒体属性行中。然后，文件发送方应用文件选择器，这意味着选择那些与“文件选择器”属性行的“名称”、“类型”、“大小”和“哈希”选择器一一匹配的文件（如果是
present). The file selector identifies zero or more candidate files to be sent. If the file selector is unable to identify any file, then the answerer MUST reject the MSRP stream for file transfer by setting the port number to zero, and then the answerer SHOULD also reject the SDP as per procedures in RFC 3264 [RFC3264], if this is the only stream described in the SDP offer.
现在）。文件选择器标识要发送的零个或多个候选文件。如果文件选择器无法识别任何文件，则应答器必须通过将端口号设置为零来拒绝用于文件传输的MSRP流，然后应答器还应根据RFC 3264[RFC3264]中的程序拒绝SDP，如果这是SDP报价中描述的唯一流。
If the file selector points to a single file and the file sender decides to accept the file transfer, the file sender MUST create an SDP answer that contains a 'sendonly' attribute, according to the procedures described in RFC 3264 [RFC3264]. The file sender SHOULD add a 'hash' selector in the answer with the locally computed SHA-1 hash over the complete file. If a hash value computed by the file sender differs from that specified by the file receiver, the file sender can either send the file without that hash value or reject the request by setting the port in the media stream to zero. The file sender MAY also include a 'type' selector in the 'file-selector' attribute line of the SDP answer. The answerer MAY also include 'file-icon' and 'file-disposition' attributes to further describe the file. Although the answerer MAY also include a 'name' and 'size' selectors in the 'file-selector' attribute, and a 'file-date' attribute, it is RECOMMENDED not to include them in the SDP answer if the actual file transfer protocol (e.g., MSRP [RFC4975]) can accommodate a Content-Disposition header field [RFC2183] with the equivalent parameters.
如果文件选择器指向单个文件，并且文件发送方决定接受文件传输，则文件发送方必须根据RFC 3264[RFC3264]中描述的过程创建包含“sendonly”属性的SDP应答。文件发送方应在答案中添加一个“哈希”选择器，在整个文件上使用本地计算的SHA-1哈希。如果文件发送方计算的哈希值与文件接收方指定的哈希值不同，则文件发送方可以发送没有该哈希值的文件，或者通过将媒体流中的端口设置为零来拒绝请求。文件发送方还可以在SDP应答的“文件选择器”属性行中包含“类型”选择器。回答者还可以包括“文件图标”和“文件处置”属性，以进一步描述文件。尽管应答者也可以在“文件选择器”属性和“文件日期”属性中包含“名称”和“大小”选择器，但如果实际的文件传输协议（例如MSRP[RFC4975]）可以容纳具有等效参数的内容处置头字段[RFC2183]，则建议不要在SDP应答中包含它们。
The whole idea of adding file descriptors to SDP is to provide a mechanism where a file transfer can be accepted prior to its start. Adding any SDP attributes that are otherwise signaled later in the file transfer protocol would just duplicate the information, but will not provide any information to the offerer to accept or reject the file transfer (note that the offerer is requesting a file).
向SDP添加文件描述符的整个想法是提供一种机制，在该机制中，文件传输可以在开始之前被接受。添加任何SDP属性（文件传输协议中稍后另行通知）只会复制信息，但不会向报价人提供任何信息以接受或拒绝文件传输（请注意，报价人正在请求文件）。
Last, if the file selector points to multiple candidate files, the answerer MAY use some local policy, e.g., consulting the user, to choose one of them to be defined in the SDP answer. If that choice cannot be done, the answerer SHOULD reject the MSRP media stream for file transfer (by setting the port number to zero).
最后，如果文件选择器指向多个候选文件，则应答者可以使用一些本地策略（例如，咨询用户）来选择SDP应答中定义的其中一个文件。如果无法进行选择，应答者应拒绝MSRP媒体流进行文件传输（通过将端口号设置为零）。
If the need arises, future specifications can provide a suitable mechanism that allows to either select multiple files or, e.g., resolve ambiguities by returning a list of files that match the file selector.
如果需要，未来的规范可以提供一种合适的机制，允许选择多个文件，或者，例如，通过返回与文件选择器匹配的文件列表来解决歧义。
If the SDP offer contains a 'file-range' attribute and the file sender accepts to send the range of octets declared in there, the file sender MUST include a 'file-range' attribute in the SDP answer
如果SDP报价包含“文件范围”属性，并且文件发送方接受发送其中声明的八位字节范围，则文件发送方必须在SDP应答中包含“文件范围”属性
with the same range of values. If the file sender does not accept sending that range of octets, it SHOULD reject the transfer of the file.
具有相同的值范围。如果文件发送方不接受发送该范围的八位字节，则应拒绝文件传输。
Either the file sender or the file receiver can abort an ongoing file transfer at any time. Unless otherwise noted, the entity that aborts an ongoing file transfer operation MUST follow the procedures at the media level (e.g., MSRP) and at the signaling level (SDP offer/ answer), as described below.
文件发送方或文件接收方可以随时中止正在进行的文件传输。除非另有说明，中止正在进行的文件传输操作的实体必须遵循媒体级（例如MSRP）和信令级（SDP提供/应答）的程序，如下所述。
Assume the scenario depicted in Figure 4 where a file sender wishes to abort an ongoing file transfer without initiating an alternative file transfer. Assume that an ongoing MSRP SEND request is being transmitted. The file sender aborts the MSRP message by including the '#' character in the continuation field of the end-line of a SEND request, according to the MSRP procedures (see Section 7.1 of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP message, aborting the MSRP message effectively aborts the file transfer. The file receiver acknowledges the MSRP SEND request with a 200 response. Then the file sender SHOULD close the MSRP session by creating a new SDP offer that sets the port number to zero in the related "m=" line that describes the file transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer MUST conform with the requirements of Section 8.2.1. The 'file-transfer-id' attribute MUST be the same attribute that identifies the ongoing transfer. Then the file sender sends this SDP offer to the file receiver.
假设图4所示的场景，其中文件发送者希望中止正在进行的文件传输，而不启动替代文件传输。假设正在传输正在进行的MSRP发送请求。根据MSRP程序（参见RFC 4975[RFC4975]第7.1节），文件发送方通过在发送请求的结束行的延续字段中包含“#”字符中止MSRP消息。由于文件作为一条MSRP消息传输，因此中止MSRP消息实际上会中止文件传输。文件接收器以200响应确认MSRP发送请求。然后，文件发送方应通过在描述文件传输的相关“m=”行中创建一个新的SDP选项将端口号设置为零来关闭MSRP会话（请参见RFC 3264[RFC3264]第8.2节）。该SDP报价必须符合第8.2.1节的要求。“文件传输id”属性必须与标识正在进行的传输的属性相同。然后，文件发送方将此SDP报价发送给文件接收方。
Rather than close the MSRP session by setting the port number to zero in the related "m=" line, the file sender could also tear down the whole session, e.g., by sending a SIP BYE request.
与其通过在相关的“m=”行中将端口号设置为零来关闭MSRP会话，文件发送方还可以中断整个会话，例如，通过发送SIP BYE请求。
Note that it is the responsibility of the file sender to tear down the MSRP session. Implementations should be prepared for misbehaviors and implement measures to avoid hang states. For example, upon expiration of a timer the file receiver can close the aborted MSRP session by using regular MSRP procedures.
请注意，文件发送者有责任中断MSRP会话。应为不当行为做好实施准备，并采取措施避免挂起状态。例如，在计时器过期时，文件接收器可以使用常规MSRP过程关闭中止的MSRP会话。
A file receiver that receives the above SDP offer creates an SDP answer according to the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This SDP answer MUST conform with the requirements of Section 8.3.1. Then the file receiver sends this SDP answer to the file sender.
接收上述SDP要约的文件接收器根据SDP要约/应答（RFC 3264[RFC3264]）的过程创建SDP应答。该SDP答案必须符合第8.3.1节的要求。然后，文件接收方将此SDP应答发送给文件发送方。
File sender File receiver
| |
|\ |
| \ |
| \ |
| \ |
| \ |
| \ |
abort->| \ MSRP SEND (#) |
| +--------------->|
| MSRP 200 |
|<-----------------------|
| re-INVITE (SDP offer) |
|----------------------->|
| SIP 200 OK (SDP answer)|
|<-----------------------|
| SIP ACK |
|----------------------->|
| |
File sender File receiver
| |
|\ |
| \ |
| \ |
| \ |
| \ |
| \ |
abort->| \ MSRP SEND (#) |
| +--------------->|
| MSRP 200 |
|<-----------------------|
| re-INVITE (SDP offer) |
|----------------------->|
| SIP 200 OK (SDP answer)|
|<-----------------------|
| SIP ACK |
|----------------------->|
| |
Figure 4: File sender aborts an ongoing file transfer
图4：文件发送方中止正在进行的文件传输
When the file receiver wants to abort the file transfer, there are two possible scenarios, depending on the value of the Failure-Report header in the ongoing MSRP SEND request. Assume now the scenario depicted in Figure 5 where the MSRP SEND request includes a Failure-Report header set to a value different than "no". When the file receiver wishes to abort the ongoing file transfer, the file receiver generates an MSRP 413 response to the current MSRP SEND request (see Section 10.5 of RFC 4975 [RFC4975]). Then the file receiver MUST close the MSRP session by generating a new SDP offer that sets the port number to zero in the related "m=" line that describes the file transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer MUST conform with the requirements expressed in Section 8.2.2. The 'file-transfer-id' attribute MUST be the same attribute that identifies the ongoing transfer. Then the file receiver sends this SDP offer to the file sender.
当文件接收者想要中止文件传输时，根据正在进行的MSRP发送请求中失败报告头的值，有两种可能的情况。现在假设图5中描述的场景，其中MSRP发送请求包括一个设置为不同于“否”的值的故障报告头。当文件接收方希望中止正在进行的文件传输时，文件接收方生成对当前MSRP发送请求的MSRP 413响应（参见RFC 4975[RFC4975]第10.5节）。然后，文件接收方必须通过在描述文件传输的相关“m=”行中生成一个新的SDP offer将端口号设置为零来关闭MSRP会话（请参见RFC 3264[RFC3264]第8.2节）。本SDP报价必须符合第8.2.2节中规定的要求。“文件传输id”属性必须与标识正在进行的传输的属性相同。然后，文件接收方将此SDP报价发送给文件发送方。
File sender File receiver
| |
|\ |
| \ MSRP SEND |
| \ Failure-Report: yes |
| \ |
| \ |
| \ |
| \ |
| \ |
| \ |
| MSRP 413 |<-abort
|<-----------------------|
| \ (#) |
| +----------->|
| re-INVITE (SDP offer) |
|<-----------------------|
| SIP 200 OK (SDP answer)|
|----------------------->|
| SIP ACK |
|<-----------------------|
| |
File sender File receiver
| |
|\ |
| \ MSRP SEND |
| \ Failure-Report: yes |
| \ |
| \ |
| \ |
| \ |
| \ |
| \ |
| MSRP 413 |<-abort
|<-----------------------|
| \ (#) |
| +----------->|
| re-INVITE (SDP offer) |
|<-----------------------|
| SIP 200 OK (SDP answer)|
|----------------------->|
| SIP ACK |
|<-----------------------|
| |
Figure 5: File receiver aborts an ongoing file transfer. Failure-Report set to a value different than "no" in MSRP
图5：文件接收器中止正在进行的文件传输。故障报告设置为与MSRP中的“否”不同的值
In another scenario, depicted in Figure 6, an ongoing file transfer is taking place, where the MSRP SEND request contains a Failure-Report header set to the value "no". When the file receiver wants to abort the ongoing transfer, it MUST close the MSRP session by generating a new SDP offer that sets the port number to zero in the related "m=" line that describes the file transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer MUST conform with the requirements expressed in Section 8.2.2. The 'file-transfer-id' attribute MUST be the same attribute that identifies the ongoing transfer. Then the file receiver sends this SDP offer to the file sender.
在另一个场景中，如图6所示，正在进行文件传输，其中MSRP发送请求包含一个设置为值“no”的故障报告头。当文件接收方想要中止正在进行的传输时，它必须通过在描述文件传输的相关“m=”行中生成一个新的SDP offer将端口号设置为零来关闭MSRP会话（参见RFC 3264[RFC3264]第8.2节）。本SDP报价必须符合第8.2.2节中规定的要求。“文件传输id”属性必须与标识正在进行的传输的属性相同。然后，文件接收方将此SDP报价发送给文件发送方。
File sender File receiver
| |
|\ |
| \ MSRP SEND |
| \ Failure-Report: no |
| \ |
| \ |
| \ |
| \ |
| \ |
| \ |
| re-INVITE (SDP offer) |<-abort
|<-----------------------|
| \ (#) |
| +----------->|
| MSRP 200 |
|<-----------------------|
| SIP 200 OK (SDP answer)|
|----------------------->|
| SIP ACK |
|<-----------------------|
| |
File sender File receiver
| |
|\ |
| \ MSRP SEND |
| \ Failure-Report: no |
| \ |
| \ |
| \ |
| \ |
| \ |
| \ |
| re-INVITE (SDP offer) |<-abort
|<-----------------------|
| \ (#) |
| +----------->|
| MSRP 200 |
|<-----------------------|
| SIP 200 OK (SDP answer)|
|----------------------->|
| SIP ACK |
|<-----------------------|
| |
Figure 6: File receiver aborts an ongoing file transfer. Failure-Report set to "no" in MSRP
图6：文件接收器中止正在进行的文件传输。MSRP中的故障报告设置为“否”
A file sender that receives an SDP offer setting the port number to zero in the related "m=" line for file transfer, first, if an ongoing MSRP SEND request is being transmitted, aborts the MSRP message by including the '#' character in the continuation field of the end-line of a SEND request, according to the MSRP procedures (see Section 7.1 of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP message, aborting the MSRP message effectively aborts the file transfer. Then the file sender creates an SDP answer according to the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This SDP answer MUST conform with the requirements of Section 8.3.2. Then the file sender sends this SDP answer to the file receiver.
接收SDP offer的文件发送方在文件传输的相关“m=”行中将端口号设置为零，首先，如果正在传输MSRP发送请求，则根据MSRP过程，通过在发送请求的结束行的延续字段中包含“#”字符来中止MSRP消息（参见RFC 4975[RFC4975]第7.1节）。由于文件作为一条MSRP消息传输，中止MSRP消息将有效中止文件传输。然后，文件发送方根据SDP提供/应答（RFC 3264[RFC3264]）的过程创建SDP应答。此SDP应答必须符合第8.3.2节的要求。然后，文件发送方将此SDP应答发送给文件接收方。
The SDP offer/answer model [RFC3264] provides provisions for indicating a capability to another endpoint (see Section 9 of RFC 3264 [RFC3264]). The mechanism assumes a high-level protocol, such as SIP [RFC3261], that provides a capability query (such as a SIP OPTIONS request). RFC 3264 [RFC3264] indicates how to build the SDP that is included in the response to such capability query. As such, RFC 3264 indicates that an endpoint builds an SDP body that contains
SDP提供/应答模型[RFC3264]提供了向另一个端点指示能力的规定（参见RFC 3264[RFC3264]第9节）。该机制采用高级协议，如SIP[RFC3261]，该协议提供能力查询（如SIP选项请求）。RFC 3264[RFC3264]指示如何构建包含在对此类功能查询的响应中的SDP。因此，RFC3264指示端点构建包含
an "m=" line containing the media type (message, for MSRP). An endpoint that implements the procedures specified in this document SHOULD also add a 'file-selector' media attribute for the "m=message" line. The 'file-selector' media attribute MUST be empty, i.e., it MUST NOT contain any selector. The endpoint MUST NOT add any of the other file attributes defined in this specification.
包含媒体类型的“m=”行（消息，用于MSRP）。实现本文档中指定过程的端点还应为“m=message”行添加“文件选择器”媒体属性。“文件选择器”媒体属性必须为空，即它不能包含任何选择器。端点不得添加本规范中定义的任何其他文件属性。
The SDP offer/answer model [RFC3264] provides rules that allow SDP offerers and answerers to modify an existing media line, i.e., reuse an existing media line with different attributes. The same is also possible when SDP signals a file transfer operation according to the rules of this memo. Therefore, the procedures defined in RFC 3264 [RFC3264], in particular those defined in Section 8.3, MUST apply for file transfer operations. An endpoint that wants to reuse an existing "m=" line to start the file transfer of another file creates a different 'file-selector' attribute and selects a new globally unique random value of the 'file-transfer-id' attribute.
SDP提供/应答模型[RFC3264]提供了允许SDP提供方和应答方修改现有媒体线路的规则，即使用具有不同属性的现有媒体线路。当SDP根据本备忘录的规则发出文件传输操作信号时，也可以进行同样的操作。因此，RFC 3264[RFC3264]中定义的程序，特别是第8.3节中定义的程序，必须适用于文件传输操作。要重用现有“m=”行以开始另一个文件的文件传输的端点将创建不同的“文件选择器”属性，并选择“文件传输id”属性的新全局唯一随机值。
If the file offerer resends an SDP offer with a port different than zero, then the 'file-transfer-id' attribute determines whether a new file transfer will start or whether the file transfer does not need to start. If the SDP answerer accepts the SDP, then file transfer starts from the indicated octet (if a 'file-range' attribute is present).
如果文件提供程序使用不同于零的端口重新发送SDP提供，则“文件传输id”属性确定是否将开始新的文件传输或是否不需要开始文件传输。如果SDP应答器接受SDP，则文件传输从指定的八位字节开始（如果存在“文件范围”属性）。
The file transfer service specified in this document uses "m=" lines in SDP to describe the unidirectional transfer of a file. Consequently, each MSRP session established following the procedures in Section 8.2 and Section 8.3 is only used to transfer a single file. So, senders MUST only use the dedicated MSRP session to send the file described in the SDP offer or answer. That is, senders MUST NOT send additional files over the same MSRP session.
本文档中指定的文件传输服务使用SDP中的“m=”行来描述文件的单向传输。因此，按照第8.2节和第8.3节中的程序建立的每个管理系统更新项目会话仅用于传输单个文件。因此，发件人只能使用专用的MSRP会话来发送SDP报价或应答中描述的文件。也就是说，发件人不得在同一MSRP会话中发送其他文件。
File transfer may be accomplished using a new multimedia session established for the purpose. Alternatively, a file transfer may be conducted within an existing multimedia session, without regard for the media in use within that session. Of particular note, file transfer may be done within a multimedia session containing an MSRP session used for regular instant messaging. If file transfer is initiated within an existing multimedia session, the SDP offerer MUST NOT reuse an existing "m=" line that is still being used by MSRP (either regular MSRP for instant messaging or an ongoing file transfer). Rather, it MUST add an additional "m=" line or else reuse an "m=" line that is no longer being used.
可以使用为此目的建立的新多媒体会话来完成文件传输。或者，可以在现有多媒体会话中进行文件传输，而不考虑该会话中使用的媒体。特别注意，文件传输可以在包含用于常规即时消息传递的MSRP会话的多媒体会话内完成。如果文件传输是在现有多媒体会话中启动的，SDP报价人不得重复使用MSRP仍在使用的现有“m=”行（即时消息的常规MSRP或正在进行的文件传输）。相反，它必须添加一个额外的“m=”行，或者重用不再使用的“m=”行。
Additionally, implementations according to this specification MUST include a single file in a single MSRP message. Notice that the MSRP specification defines "MSRP message" as a complete unit of MIME or text content, which can be split and delivered in more than one MSRP request; each of these portions of the complete message is called a "chunk". So, it is still valid to send a file in several chunks, but from the MSRP point of view, all the chunks together form an MSRP message: the Common Presence and Instant Messaging (CPIM) message that wraps the file. When chunking is used, it should be noticed that MSRP does not require to wait for a 200-class response for a chunk before sending the following one. Therefore, it is valid to send pipelined MSRP SEND requests containing chunks of the same MSRP message (the file). Section 9.1 contains an example of a file transfer using pipelined MSRP requests.
此外，根据本规范的实现必须在单个MSRP消息中包含单个文件。请注意，MSRP规范将“MSRP消息”定义为MIME或文本内容的完整单元，可以在多个MSRP请求中拆分和传递；完整消息的每一部分都称为“块”。因此，将一个文件分为多个区块发送仍然有效，但从MSRP的角度来看，所有区块共同构成一条MSRP消息：包装该文件的公共状态和即时消息（CPIM）消息。当使用分块时，应该注意到MSRP不需要在发送下一个分块之前等待200类响应。因此，发送包含相同MSRP消息（文件）块的流水线MSRP发送请求是有效的。第9.1节包含使用流水线MSRP请求进行文件传输的示例。
The MSRP specification [RFC4975] defines a 'max-size' SDP attribute. This attribute specifies the maximum number of octets of an MSRP message that the creator of the SDP is willing to receive (notice once more the definition of "MSRP message"). File receivers MAY add a 'max-size' attribute to the MSRP "m=" line that specifies the file, indicating the maximum number of octets of an MSRP message. File senders MUST NOT exceed the 'max-size' limit for any message sent in the resulting session.
MSRP规范[RFC4975]定义了“最大尺寸”SDP属性。此属性指定SDP创建者愿意接收的MSRP消息的最大八位字节数（请再次注意“MSRP消息”的定义）。文件接收者可以向指定文件的MSRP“m=”行添加“max size”属性，指示MSRP消息的最大八位字节数。对于结果会话中发送的任何邮件，文件发件人不得超过“最大大小”限制。
In the absence of a 'file-range' attribute in the SDP, the MSRP file transfer MUST start with the first octet of the file and end with the last octet (i.e., the whole file is transferred). If a 'file-range' attribute is present in SDP, the file sender application MUST extract the indicated range of octets from the file (start and stop offset octets, both inclusive). Then the file sender application MAY wrap those octets in an appropriate wrapper. MSRP mandates implementations to implement the message/cpim wrapper [RFC3862]. Usage of a wrapper is negotiated in the SDP (see Section 8.6 in RFC 4975 [RFC4975]). Last, the file sender application delivers the content (e.g., the message/cpim body) to MSRP for transportation. MSRP will consider the delivered content as a whole message, and will start numbering bytes with the number 1.
如果SDP中没有“文件范围”属性，则MSRP文件传输必须从文件的第一个八位字节开始，并以最后一个八位字节结束（即传输整个文件）。如果SDP中存在“文件范围”属性，则文件发送方应用程序必须从文件中提取指定的八位字节范围（包括开始和停止偏移八位字节）。然后，文件发送方应用程序可以将这些八位字节包装在适当的包装器中。MSRP要求实现消息/cpim包装器[RFC3862]。包装器的使用在SDP中协商（见RFC 4975[RFC4975]第8.6节）。最后，文件发送方应用程序将内容（例如，消息/cpim正文）交付给MSRP进行传输。MSRP将考虑传递的内容作为一个完整的消息，并将开始用编号1对字节进行编号。
Note that the default content disposition of MSRP bodies is 'render'. When MSRP is used to transfer files, the MSRP Content-Disposition header can also take the value 'attachment' as indicated in Section 7.
请注意，MSRP主体的默认内容配置为“呈现”。当MSRP用于传输文件时，MSRP内容处置标题也可以采用第7节中所示的值“附件”。
Once the file transfer is completed, the file sender SHOULD close the MSRP session and MUST behave according to the MSRP [RFC4975] procedures with respect to closing MSRP sessions. Note that MSRP
文件传输完成后，文件发送方应关闭MSRP会话，并且必须按照MSRP[RFC4975]有关关闭MSRP会话的程序进行操作。请注意，管理系统更新项目
session management is not related to TCP connection management. As a matter of fact, MSRP allows multiple MSRP sessions to share the same TCP connection.
会话管理与TCP连接管理无关。事实上，MSRP允许多个MSRP会话共享同一TCP连接。
This specification allows a file sender to include a small preview of an image file: an icon. A 'file-icon' attribute contains a Content-ID (CID) URL [RFC2392] pointing to an additional body that contains the actual icon. Since the icon is sent as a separate body along the SDP body, the file sender MUST wrap the SDP body and the icon bodies in a MIME multipart/related body. Therefore, implementations according to this specification MUST implement the multipart/related MIME type [RFC2387]. When creating a multipart/ related MIME wrapper, the SDP body MUST be the root body, which according to RFC 2387 [RFC2387] is identified as the first body in the multipart/related MIME wrapper or explicitly identified by the 'start' parameter. According to RFC 2387 [RFC2387], the 'type' parameter MUST be present and point to the root body, i.e., the SDP body.
此规范允许文件发送者包含图像文件的小预览：图标。“文件图标”属性包含一个内容ID（CID）URL[RFC2392]，指向包含实际图标的附加正文。由于图标作为单独的主体沿着SDP主体发送，因此文件发送者必须将SDP主体和图标主体包装在MIME多部分/相关主体中。因此，根据本规范的实现必须实现多部分/相关MIME类型[RFC2387]。创建多部分/相关MIME包装时，SDP主体必须是根主体，根据RFC 2387[RFC2387]的规定，根主体被标识为多部分/相关MIME包装中的第一个主体，或者由“start”参数显式标识。根据RFC 2387[RFC2387]，必须存在“type”参数并指向根主体，即SDP主体。
Assume that an endpoint behaving according to this specification tries to send a file to a remote endpoint that neither implements this specification nor implements multipart MIME bodies. The file sender sends an SDP offer that contains a multipart/related MIME body that includes an SDP body part and an icon body part. The file receiver, not supporting multipart MIME types, will reject the SDP offer via a higher protocol mechanism (e.g., SIP). In this case, it is RECOMMENDED that the file sender removes the icon body part, creates a single SDP body (i.e., without multipart MIME), and resends the SDP offer. This provides some backwards compatibility with file receives that do not implement this specification and increases the chances of getting the SDP accepted at the file receiver.
假设根据此规范运行的端点尝试将文件发送到既不实现此规范也不实现多部分MIME体的远程端点。文件发送方发送包含多部分/相关MIME正文的SDP要约，该正文包括SDP正文部分和图标正文部分。不支持多部分MIME类型的文件接收器将通过更高的协议机制（例如SIP）拒绝SDP提供。在这种情况下，建议文件发送方删除图标主体部分，创建单个SDP主体（即，不带多部分MIME），然后重新发送SDP提供。这提供了与未实现此规范的文件接收的向后兼容性，并增加了在文件接收端接受SDP的机会。
Since the icon is sent as part of the signaling, it is RECOMMENDED to keep the size of icons restricted to the minimum number of octets that provide significance.
由于图标是作为信号的一部分发送的，建议将图标的大小限制在提供重要性的最小八位字节数。
This section shows an example flow for a file transfer scenario. The example assumes that SIP [RFC3261] is used to transport the SDP offer/answer exchange, although the SIP details are briefly shown for the sake of brevity.
本节显示了文件传输场景的示例流程。该示例假设SIP[RFC3261]用于传输SDP提供/应答交换，尽管为了简洁起见简要显示了SIP详细信息。
Alice, the SDP offerer, wishes to send an image file to Bob (the answerer). Alice's User Agent Client (UAC) creates a unidirectional SDP offer that contains the description of the file that she wants to send to Bob's User Agent Server (UAS). The description also includes an icon representing the contents of the file to be transferred. The sequence flow is shown in Figure 7.
SDP报价人Alice希望向Bob（应答者）发送一个图像文件。Alice的用户代理客户端（UAC）创建一个单向SDP提供，其中包含她要发送到Bob的用户代理服务器（UAS）的文件的描述。描述还包括表示要传输的文件内容的图标。序列流如图7所示。
Alice's UAC Bob's UAS
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
| |
|(4) (MSRP) SEND (chunk) |
|----------------------->|
|(5) (MSRP) SEND (chunk) |
|----------------------->|
|(6) (MSRP) 200 OK |
|<-----------------------|
|(7) (MSRP) 200 OK |
|<-----------------------|
| |
|(8) (SIP) BYE |
|----------------------->|
|(9) (SIP) 200 OK |
|<-----------------------|
| |
| |
Alice's UAC Bob's UAS
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
| |
|(4) (MSRP) SEND (chunk) |
|----------------------->|
|(5) (MSRP) SEND (chunk) |
|----------------------->|
|(6) (MSRP) 200 OK |
|<-----------------------|
|(7) (MSRP) 200 OK |
|<-----------------------|
| |
|(8) (SIP) BYE |
|----------------------->|
|(9) (SIP) 200 OK |
|<-----------------------|
| |
| |
Figure 7: Flow diagram of an offerer sending a file to an answerer
图7：报价人向应答人发送文件的流程图
F1: Alice constructs an SDP description of the file to be sent and attaches it to a SIP INVITE request addressed to Bob.
F1:Alice构造要发送的文件的SDP描述，并将其附加到发送给Bob的SIP INVITE请求。
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
boundary="boundary71"
Content-Length: [length]
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
boundary="boundary71"
Content-Length: [length]
--boundary71
Content-Type: application/sdp
Content-Length: [length of SDP]
--boundary71
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:4092 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
a=file-disposition:render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com
v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:4092 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
a=file-disposition:render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
[...small preview icon of the file...]
[…文件的小预览图标…]
--boundary71--
--边界71--
Figure 8: INVITE request containing an SDP offer for file transfer
图8：包含SDP文件传输提议的INVITE请求
NOTE: The Content-Type header field and the 'file-selector' attribute in the above figure are split in several lines for formatting purposes. Real implementations will encode it in a single line.
注意：上图中的内容类型标题字段和“文件选择器”属性被拆分为几行，以便于格式化。真正的实现将在一行中对其进行编码。
From now on we omit the SIP details for the sake of brevity.
从现在起，为了简洁起见，我们省略了SIP细节。
F2: Bob receives the INVITE request, inspects the SDP offer and extracts the icon body, checks the creation date and file size, and decides to accept the file transfer. So Bob creates the following SDP answer:
F2:Bob接收INVITE请求，检查SDP报价并提取图标主体，检查创建日期和文件大小，并决定接受文件传输。因此，Bob创建了以下SDP答案：
v=0
o=bob 2890844656 2890844656 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:4092 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
v=0
o=bob 2890844656 2890844656 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:4092 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
Figure 9: SDP answer accepting the SDP offer for file transfer
图9:SDP应答接受SDP提供的文件传输
NOTE: The 'file-selector' attribute in the above figure is split in three lines for formatting purposes. Real implementations will encode it in a single line.
注意：上图中的“文件选择器”属性分为三行，用于格式化。真正的实现将在一行中对其进行编码。
F4: Alice opens a TCP connection to Bob and creates an MSRP SEND request. This SEND request contains the first chunk of the file.
F4:Alice打开与Bob的TCP连接并创建MSRP发送请求。此发送请求包含文件的第一个块。
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2048/4385
Content-Type: message/cpim
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2048/4385
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool picture.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300";
size=4092
Content-Type: image/jpeg
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool picture.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300";
size=4092
Content-Type: image/jpeg
... first set of bytes of the JPEG image ...
-------d93kswow+
... first set of bytes of the JPEG image ...
-------d93kswow+
Figure 10: MSRP SEND request containing the first chunk of actual file
图10:MSRP发送请求包含实际文件的第一个块
F5: Alice sends the second and last chunk. Note that MSRP allows to send pipelined chunks, so there is no need to wait for the 200 (OK) response from the previous chunk.
F5:Alice发送第二个也是最后一个块。请注意，MSRP允许发送管道化块，因此无需等待来自上一个块的200（OK）响应。
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 2049-4385/4385
Content-Type: message/cpim
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 2049-4385/4385
Content-Type: message/cpim
... second set of bytes of the JPEG image ...
-------op2nc9a$
... second set of bytes of the JPEG image ...
-------op2nc9a$
Figure 11: MSRP SEND request containing the second chunk of actual file
图11:MSRP发送请求，包含实际文件的第二个块
F6: Bob acknowledges the reception of the first chunk.
F6:Bob确认接收到第一个区块。
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4385
-------d93kswow$
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4385
-------d93kswow$
Figure 12: MSRP 200 OK response
图12:MSRP 200正常响应
F7: Bob acknowledges the reception of the second chunk.
F7:Bob确认接收到第二个区块。
MSRP op2nc9a 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 2049-4385/4385
-------op2nc9a$
MSRP op2nc9a 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 2049-4385/4385
-------op2nc9a$
Figure 13: MSRP 200 OK response
图13:MSRP 200正常响应
F8: Alice terminates the SIP session by sending a SIP BYE request.
F8:Alice通过发送SIP BYE请求来终止SIP会话。
F9: Bob acknowledges the reception of the BYE request and sends a 200 (OK) response.
F9:Bob确认收到BYE请求并发送200（OK）响应。
In this example, Alice, the SDP offerer, first wishes to fetch a file from Bob, the SDP answerer. Alice knows that Bob has a specific file she wants to download. She has learned the hash of the file by some out-of-band mechanism. The hash selector is enough to produce a file selector that points to the specific file. So, Alice creates an SDP offer that contains the file descriptor. Bob accepts the file transfer and sends the file to Alice. When Alice has completely received Bob's file, she intends to send a new image file to Bob. Therefore, Alice reuses the existing SDP media line with different attributes and updates the description of the new file she wants to send to Bob's User Agent Server (UAS). In particular, Alice creates a new file transfer identifier since this is a new file transfer operation. Figure 14 shows the sequence flow.
在本例中，SDP提供者Alice首先希望从SDP应答者Bob获取一个文件。Alice知道Bob有一个特定的文件要下载。她通过一些带外机制学会了文件的散列。哈希选择器足以生成指向特定文件的文件选择器。因此，Alice创建了一个包含文件描述符的SDP提供。Bob接受文件传输并将文件发送给Alice。当Alice完全收到Bob的文件后，她打算向Bob发送一个新的图像文件。因此，Alice重用具有不同属性的现有SDP媒体行，并更新要发送到Bob的用户代理服务器（UAS）的新文件的描述。特别是，Alice创建了一个新的文件传输标识符，因为这是一个新的文件传输操作。图14显示了序列流。
Alice's UAC Bob's UAS
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
| |
|(4) (MSRP) SEND (file) |
|<-----------------------|
|(5) (MSRP) 200 OK |
|----------------------->|
| |
|(6) (SIP) INVITE |
|----------------------->|
|(7) (SIP) 200 OK |
|<-----------------------|
|(8) (SIP) ACK |
|----------------------->|
| |
|(9) (MSRP) SEND (file) |
|----------------------->|
|(10) (MSRP) 200 OK |
|<-----------------------|
| |
|(11) (SIP) BYE |
|<-----------------------|
|(12) (SIP) 200 OK |
|----------------------->|
| |
| |
Alice's UAC Bob's UAS
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
| |
|(4) (MSRP) SEND (file) |
|<-----------------------|
|(5) (MSRP) 200 OK |
|----------------------->|
| |
|(6) (SIP) INVITE |
|----------------------->|
|(7) (SIP) 200 OK |
|<-----------------------|
|(8) (SIP) ACK |
|----------------------->|
| |
|(9) (MSRP) SEND (file) |
|----------------------->|
|(10) (MSRP) 200 OK |
|<-----------------------|
| |
|(11) (SIP) BYE |
|<-----------------------|
|(12) (SIP) 200 OK |
|----------------------->|
| |
| |
Figure 14: Flow diagram of an offerer requesting a file from the answerer and then sending a file to the answer
图14：报价人向应答人请求文件，然后向应答人发送文件的流程图
F1: Alice constructs an SDP description of the file she wants to receive and attaches the SDP offer to a SIP INVITE request addressed to Bob.
F1:Alice为她想要接收的文件构造SDP描述，并将SDP提供附加到发送给Bob的SIP INVITE请求。
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: application/sdp
Content-Length: [length of SDP]
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
Figure 15: INVITE request containing an SDP offer for file transfer
图15：包含SDP文件传输提议的INVITE请求
NOTE: The 'file-selector' attribute in the above figure is split in two lines for formatting purposes. Real implementations will encode it in a single line.
注意：上图中的“文件选择器”属性分为两行，以便于格式化。真正的实现将在一行中对其进行编码。
From now on we omit the SIP details for the sake of brevity.
从现在起，为了简洁起见，我们省略了SIP细节。
F2: Bob receives the INVITE request, inspects the SDP offer, computes the file descriptor, and finds a local file whose hash equals the one indicated in the SDP. Bob accepts the file transfer and creates an SDP answer as follows:
F2：Bob接收INVITE请求，检查SDP提供，计算文件描述符，并找到一个本地文件，其哈希值等于SDP中指示的哈希值。Bob接受文件传输并创建SDP应答，如下所示：
v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:type:image/jpeg hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:type:image/jpeg hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
Figure 16: SDP answer accepting the SDP offer for file transfer
图16:SDP应答接受SDP提供的文件传输
NOTE: The 'file-selector' attribute in the above figure is split in two lines for formatting purposes. Real implementations will encode it in a single line.
注意：上图中的“文件选择器”属性分为两行，以便于格式化。真正的实现将在一行中对其进行编码。
F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP SEND request that contains the file.
F4:Alice打开与Bob的TCP连接。Bob然后创建一个包含该文件的MSRP发送请求。
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool photo.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300";
modification-date="Mon, 15 May 2006 16:04:53 +0300";
read-date="Mon, 16 May 2006 09:12:27 +0300";
size=1931
Content-Type: image/jpeg
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool photo.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300";
modification-date="Mon, 15 May 2006 16:04:53 +0300";
read-date="Mon, 16 May 2006 09:12:27 +0300";
size=1931
Content-Type: image/jpeg
...binary JPEG image...
-------d93kswow$
...binary JPEG image...
-------d93kswow$
Figure 17: MSRP SEND request containing the actual file
图17：包含实际文件的MSRP发送请求
F5: Alice acknowledges the reception of the SEND request.
F5:Alice确认接收到发送请求。
MSRP d93kswow 200 OK
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
Byte-Range: 1-2027/2027
-------d93kswow$
MSRP d93kswow 200 OK
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
Byte-Range: 1-2027/2027
-------d93kswow$
Figure 18: MSRP 200 OK response
图18:MSRP 200正常响应
F6: Alice reuses the existing SDP media line inserting the description of the file to be sent and attaches it to a SIP re-INVITE request addressed to Bob. Alice reuses the TCP port number for the MSRP stream, but changes the MSRP session and the 'file-transfer-id' value according to this specification.
F6:Alice重用现有SDP媒体行，插入要发送的文件的描述，并将其附加到发送给Bob的SIP重新邀请请求。Alice重用MSRP流的TCP端口号，但根据此规范更改MSRP会话和“文件传输id”值。
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>;tag=1928323431
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 2 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:33 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
boundary="boundary71"
Content-Length: [length of multipart]
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>;tag=1928323431
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 2 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:33 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
boundary="boundary71"
Content-Length: [length of multipart]
--boundary71
Content-Type: application/sdp
Content-Length: [length of SDP]
--boundary71
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844527 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/iau39;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300"
a=file-icon:cid:id3@alicepc.example.com
v=0
o=alice 2890844526 2890844527 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/iau39;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300"
a=file-icon:cid:id3@alicepc.example.com
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id3@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id3@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
[..small preview icon...]
[…小预览图标…]
--boundary71--
--边界71--
Figure 19: Reuse of the SDP in a second file transfer
图19：在第二次文件传输中重用SDP
NOTE: The Content-Type header field and the 'file-selector' attribute in the above figure are split in several lines for formatting purposes. Real implementations will encode it in a single line.
注意：上图中的内容类型标题字段和“文件选择器”属性被拆分为几行，以便于格式化。真正的实现将在一行中对其进行编码。
F7: Bob receives the re-INVITE request, inspects the SDP offer and extracts the icon body, checks the creation date and the file size, and decides to accept the file transfer. So Bob creates an SDP answer where he reuses the same TCP port number, but changes his MSRP session, according to the procedures of this specification.
F7:Bob收到重新邀请请求，检查SDP报价并提取图标主体，检查创建日期和文件大小，并决定接受文件传输。因此Bob创建了一个SDP应答，在这里他重用了相同的TCP端口号，但根据本规范的过程更改了他的MSRP会话。
v=0
o=bob 2890844656 2890855440 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
v=0
o=bob 2890844656 2890855440 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
Figure 20: SDP answer accepting the SDP offer for file transfer
图20:SDP应答接受SDP提供的文件传输
NOTE: The 'file-selector' attribute in the above figure is split in three lines for formatting purposes. Real implementations will encode it in a single line.
注意：上图中的“文件选择器”属性分为三行，用于格式化。真正的实现将在一行中对其进行编码。
F9: If a TCP connection towards Bob is already open, Alice reuses that TCP connection to send an MSRP SEND request that contains the file.
F9：如果与Bob的TCP连接已打开，Alice将重用该TCP连接以发送包含该文件的MSRP发送请求。
MSRP d95ksxox SEND
To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 13449sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
MSRP d95ksxox SEND
To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 13449sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-21T13:02:15-03:00
Content-Disposition: render; filename="Sunset.jpg";
creation-date="Sun, 21 May 2006 13:02:15 -0300";
size=1931
Content-Type: image/jpeg
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-21T13:02:15-03:00
Content-Disposition: render; filename="Sunset.jpg";
creation-date="Sun, 21 May 2006 13:02:15 -0300";
size=1931
Content-Type: image/jpeg
...binary JPEG image...
-------d95ksxox+
...binary JPEG image...
-------d95ksxox+
Figure 21: MSRP SEND request containing the actual file
图21：包含实际文件的MSRP发送请求
F10: Bob acknowledges the reception of the SEND request.
F10:Bob确认接收到发送请求。
MSRP d95ksxox 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
Byte-Range: 1-2027/2027
-------d95ksxox$
MSRP d95ksxox 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
Byte-Range: 1-2027/2027
-------d95ksxox$
Figure 22: MSRP 200 OK response
图22:MSRP 200正常响应
F11: Then Bob terminates the SIP session by sending a SIP BYE request.
F11：然后Bob通过发送SIP BYE请求来终止SIP会话。
F12: Alice acknowledges the reception of the BYE request and sends a 200 (OK) response.
F12:Alice确认收到BYE请求并发送200（OK）响应。
Alice sends an OPTIONS request to Bob (this request does not contain SDP). Bob answers with a 200 (OK) response that contain the SDP shown in Figure 24. The SDP indicates support for CPIM messages that can contain other MIME types. The maximum MSRP message size that the endpoint can receive is 20000 octets. The presence of the 'file-selector' attribute indicates support for the file transfer offer/ answer mechanism.
Alice向Bob发送一个选项请求（该请求不包含SDP）。Bob的回答是200（OK），其中包含图24所示的SDP。SDP表示支持可以包含其他MIME类型的CPIM消息。端点可以接收的最大MSRP消息大小为20000个八位字节。“文件选择器”属性表示支持文件传输提供/应答机制。
Alice's UAC Bob's UAS
| |
|(1) (SIP) OPTIONS |
|----------------------->|
|(2) (SIP) 200 OK |
| with SDP |
|<-----------------------|
| |
| |
Alice's UAC Bob's UAS
| |
|(1) (SIP) OPTIONS |
|----------------------->|
|(2) (SIP) 200 OK |
| with SDP |
|<-----------------------|
| |
| |
Figure 23: Flow diagram of a capability request
图23：能力请求的流程图
v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=-
c=IN IP4 bobpc.example.com
t=0 0
m=message 0 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=max-size:20000
a=file-selector
v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=-
c=IN IP4 bobpc.example.com
t=0 0
m=message 0 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=max-size:20000
a=file-selector
Figure 24: SDP of the 200 (OK) response to an OPTIONS request
图24:200（OK）选项请求响应的SDP
The SDP attributes defined in this specification identify a file to be transferred between two endpoints. An endpoint can offer to send the file to the other endpoint or request to receive the file from the other endpoint. In the former case, an attacker modifying those SDP attributes could cheat the receiver making it think that the file to be transferred was a different one. In the latter case, the attacker could make the sender send a different file than the one requested by the receiver. Consequently, it is RECOMMENDED that integrity protection be applied to the SDP session descriptions carrying the attributes specified in this specification. Additionally, it is RECOMMENDED that senders verify the properties of the file against the selectors that describe it.
本规范中定义的SDP属性标识要在两个端点之间传输的文件。端点可以提供向另一个端点发送文件或请求从另一个端点接收文件。在前一种情况下，攻击者修改这些SDP属性可能会欺骗接收者，使其认为要传输的文件是另一个文件。在后一种情况下，攻击者可以让发送方发送与接收方请求的文件不同的文件。因此，建议将完整性保护应用于承载本规范中指定属性的SDP会话描述。此外，建议发件人根据描述文件的选择器验证文件的属性。
The descriptions of the files being transferred between endpoints may reveal information the endpoints may consider confidential. Therefore, it is RECOMMENDED that SDP session descriptions carrying the attributes specified in this specification are encrypted.
对端点之间传输的文件的描述可以揭示端点可以考虑保密的信息。因此，建议对携带本规范中指定属性的SDP会话描述进行加密。
TLS and S/MIME are the natural choices to provide offer/answer exchanges with integrity protection and confidentiality.
TLS和S/MIME是提供完整性保护和机密性的提供/应答交换的自然选择。
When an SDP offer contains the description of a file to be sent or received, the SDP answerer MUST first authenticate the SDP offerer and then it MUST authorize the file transfer operation, typically according to a local policy. Typically, these functions are integrated in the high-level protocol that carries SDP (e.g., SIP), and in the file transfer protocol (e.g., MSRP). If SIP [RFC3261] and MSRP [RFC4975] are used, the standard mechanisms for user authentication and authorization are sufficient.
当SDP报价包含要发送或接收的文件的描述时，SDP应答者必须首先验证SDP报价者，然后授权文件传输操作，通常根据本地策略。通常，这些功能集成在承载SDP的高级协议（例如SIP）和文件传输协议（例如MSRP）中。如果使用SIP[RFC3261]和MSRP[RFC4975]，则用户身份验证和授权的标准机制就足够了。
It is possible that a malicious or misbehaving implementation tries to exhaust the resources of the remote endpoint, e.g., the internal memory or the file system, by sending very large files. To protect from this attack, an SDP answer SHOULD first verify the identity of the SDP offerer, and perhaps only accept file transfers from trusted sources. Mechanisms to verify the identity of the file sender depend on the high-level protocol that carries the SDP, for example, SIP [RFC3261] and MSRP [RFC4975].
恶意或行为不端的实现可能试图通过发送非常大的文件来耗尽远程端点的资源，例如内部内存或文件系统。为了防止这种攻击，SDP应答应该首先验证SDP提供者的身份，并且可能只接受来自可信来源的文件传输。验证文件发送方身份的机制取决于承载SDP的高级协议，例如SIP[RFC3261]和MSRP[RFC4975]。
It is also RECOMMENDED that implementations take measures to avoid attacks on resource exhaustion, for example, by limiting the size of received files, verifying that there is enough space in the file system to store the file prior to its reception, or limiting the number of simultaneous file transfers.
还建议实现采取措施避免对资源耗尽的攻击，例如，通过限制接收文件的大小、验证文件系统中是否有足够的空间在接收文件之前存储该文件，或者限制同步文件传输的数量。
File receivers MUST also sanitize all input, such as the local file name, prior to making calls to the local file system to store a file. This is to prevent the existence of meaningful characters to the local operating system that could damage it.
在调用本地文件系统存储文件之前，文件接收者还必须清理所有输入，例如本地文件名。这是为了防止本地操作系统中存在可能损坏它的有意义字符。
Once a file has been transferred, the file receiver must take care of it. Typically, file transfer is a commonly used mechanism for transmitting computer virus, spyware, and other types of malware. File receivers should apply all possible security technologies (e.g., anti-virus, anti-spyware) to mitigate the risk of damage at their host.
一旦文件被传输，文件接收者必须处理好它。通常，文件传输是传播计算机病毒、间谍软件和其他类型恶意软件的常用机制。文件接收者应应用所有可能的安全技术（例如，反病毒、反间谍软件），以降低其主机上的损坏风险。
IANA has registered a number of SDP attributes according to the following.
IANA已根据以下内容注册了许多SDP属性。
IANA has registered a number of media-level-only attributes in the Session Description Protocol Parameters registry [IANA]. The registration data, according to RFC 4566 [RFC4566], follows.
IANA已在会话描述协议参数注册表[IANA]中注册了许多仅媒体级别的属性。根据RFC 4566[RFC4566]，注册数据如下。
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
电话：+34913391000
Attribute name: file-selector
属性名称：文件选择器
Long-form attribute name: File Selector
长格式属性名称：文件选择器
Type of attribute: media level only This attribute is subject to the charset attribute
属性类型：仅媒体级别此属性受字符集属性的约束
Description: This attribute unambiguously identifies a file by indicating a combination of the 4-tuple composed of the name, size, type, and hash of the file.
描述：此属性通过指示由文件的名称、大小、类型和哈希组成的4元组的组合来明确标识文件。
Specification: RFC 5547
规格：RFC5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
电话：+34913391000
Attribute name: file-transfer-id
属性名称：文件传输id
Long-form attribute name: File Transfer Identifier
长格式属性名称：文件传输标识符
Type of attribute: media level only This attribute is subject to the charset attribute
属性类型：仅媒体级别此属性受字符集属性的约束
Description: This attribute contains a unique identifier of the file transfer operation within the session.
描述：此属性包含会话中文件传输操作的唯一标识符。
Specification: RFC 5547
规格：RFC5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
电话：+34913391000
Attribute name: file-disposition
属性名称：文件处置
Long-form attribute name: File Disposition
长格式属性名称：文件处置
Type of attribute: media level only
属性类型：仅媒体级别
This attribute is not subject to the charset attribute
此属性不受charset属性的约束
Description: This attribute provides a suggestion to the other endpoint about the intended disposition of the file.
描述：此属性向另一个端点提供有关文件的预期处置的建议。
Specification: RFC 5547
规格：RFC5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
电话：+34913391000
Attribute name: file-date
属性名称：文件日期
Long-form attribute name:
长格式属性名称：
Type of attribute: media level only This attribute is not subject to the charset attribute
属性类型：仅媒体级别此属性不受字符集属性的约束
Description: This attribute indicates the dates on which the file was created, modified, or last read.
描述：此属性表示创建、修改或上次读取文件的日期。
Specification: RFC 5547
规格：RFC5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
电话：+34913391000
Attribute name: file-icon
属性名称：文件图标
Long-form attribute name: File Icon
长格式属性名称：文件图标
Type of attribute: media level only This attribute is not subject to the charset attribute
属性类型：仅媒体级别此属性不受字符集属性的约束
Description: For image files, this attribute contains a pointer to a body that includes a small preview icon representing the contents of the file to be transferred.
描述：对于图像文件，此属性包含指向正文的指针，正文中包含表示要传输的文件内容的小预览图标。
Specification: RFC 5547
规格：RFC5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
电话：+34913391000
Attribute name: file-range
属性名称：文件范围
Long-form attribute name: File Range
长格式属性名称：文件范围
Type of attribute: media level only This attribute is not subject to the charset attribute
属性类型：仅媒体级别此属性不受字符集属性的约束
Description: This attribute contains the range of transferred octets of the file.
描述：此属性包含文件传输的八位字节的范围。
Specification: RFC 5547
规格：RFC5547
The authors would like to thank Mats Stille, Nancy Greene, Adamu Haruna, and Arto Leppisaari for discussing initial concepts described in this memo. Thanks to Pekka Kuure for reviewing initial versions of this document and providing helpful comments. Joerg Ott, Jiwey Wang, Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis-Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, Richard Barnes, and Chris Newman discussed and provided comments and improvements to this document.
作者要感谢Mats Stille、Nancy Greene、Adamu Haruna和Arto Leppisaari讨论了本备忘录中描述的初始概念。感谢Pekka Kuure审查本文件的初始版本并提供有用的意见。Joerg Ott、Jiwey Wang、Amitkumar Goel、Sudha Vs、Dan Wing、Juuso Lehtinen、Remi Denis Courmon、Colin Perkins、Sudhakar An、Peter Saint Andre、Jonathan Rosenberg、Eric Rescorla、Vikram Chhibber、Ben Campbell、Richard Barnes和Chris Newman讨论了本文件，并提供了意见和改进。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，“在Internet消息中传递表示信息：内容处置头字段”，RFC 2183，1997年8月。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2387]Levinson，E.“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]Levinson，E.“内容ID和消息ID统一资源定位器”，RFC 2392，1998年8月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC3862]Klyne，G.和D.Atkins，“常见状态和即时消息（CPIM）：消息格式”，RFC 3862，2004年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]Campbell，B.，Mahy，R.，和C.Jennings，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4028]Donovan，S.和J.Rosenberg，“会话启动协议（SIP）中的会话计时器”，RFC4028，2005年4月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483]Burger，E.“会话初始化协议（SIP）消息中的内容间接寻址机制”，RFC 4483，2006年5月。
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.
[RFC4976]Jennings，C.，Mahy，R.，和A.Roach，“消息会话中继协议（MSRP）的中继扩展”，RFC 49762007年9月。
[IANA] IANA, "Internet Assigned Numbers Authority", <http://www.iana.org>.
[IANA]IANA，“互联网分配号码管理局”<http://www.iana.org>.
[FLUTE-REV] Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, September 2008.
[FLUTE-REV]Luby，M.，Lehtonen，R.，Roca，V.，和T.Paila，“长笛-单向运输上的文件交付”，正在进行的工作，2008年9月。
The requirements are related to the description and negotiation of the session, not to the actual file transfer mechanism. Thus, it is natural that in order to meet them it is enough to define attribute extensions and usage conventions to SDP, while MSRP itself needs no extensions and can be used as it is. This is effectively the approach taken in this specification. Another goal has been to specify the SDP extensions in such a way that a regular MSRP endpoint that does not support them could still in some cases act as an endpoint in a file transfer session, albeit with a somewhat reduced functionality.
这些要求与会话的描述和协商有关，而与实际的文件传输机制无关。因此，为了满足这些要求，为SDP定义属性扩展和使用约定就足够了，而MSRP本身不需要扩展，可以按原样使用。这实际上是本规范中采用的方法。另一个目标是指定SDP扩展，使不支持SDP扩展的常规MSRP端点在某些情况下仍可以充当文件传输会话中的端点，尽管功能有所减少。
In some ways, the aim of this specification is similar to the aim of content indirection mechanism in the Session Initiation Protocol (SIP) [RFC4483]. Both mechanisms allow a user agent to decide whether or not to download a file based on information about the file. However, there are some differences. With content indirection, it is not possible for the other endpoint to explicitly accept or reject the file transfer. Also, it is not possible for an endpoint to request a file from another endpoint. Furthermore, content indirection is not tied to the context of a media session, which is sometimes a desirable property. Finally, content indirection typically requires some server infrastructure, which may not always be available. It is possible to use content indirection directly between the endpoints too, but in that case there is no definition for how it works for endpoints behind NATs. The level of requirements in implementations decides which solution meets the requirements.
在某些方面，本规范的目的类似于会话发起协议（SIP）[RFC4483]中内容间接机制的目的。这两种机制都允许用户代理根据有关文件的信息决定是否下载文件。但是，也存在一些差异。对于内容间接寻址，另一个端点不可能显式接受或拒绝文件传输。此外，端点不可能从另一个端点请求文件。此外，内容间接寻址不与媒体会话的上下文相关联，这有时是一个理想的属性。最后，内容间接寻址通常需要一些服务器基础设施，这些基础设施可能并不总是可用的。也可以在端点之间直接使用内容间接寻址，但在这种情况下，对于NAT后面的端点如何使用内容间接寻址，没有定义。实现中的需求级别决定了哪个解决方案满足需求。
Based on the argumentation above, this document defines the SDP attribute extensions and usage conventions needed for meeting the requirements on file transfer services with the SDP offer/answer model, using MSRP as the transfer protocol within the session.
基于上述论证，本文档定义了SDP属性扩展和使用约定，以满足SDP提供/应答模型对文件传输服务的要求，使用MSRP作为会话内的传输协议。
In principle, it is possible to use the SDP extensions defined here and replace MSRP with any other similar protocol that can carry MIME objects. This kind of specification can be written as a separate document if the need arises. Essentially, such a protocol should be able to be negotiated on an SDP offer/answer exchange (RFC 3264 [RFC3264]), be able to describe the file to be transferred in SDP offer/answer exchange, be able to carry MIME objects between two endpoints, and use a reliable transport protocol (e.g., TCP).
原则上，可以使用此处定义的SDP扩展，并用任何其他可以承载MIME对象的类似协议替换MSRP。如果需要，这种规范可以作为单独的文件编写。本质上，这样的协议应该能够在SDP提供/应答交换（RFC 3264[RFC3264]）上协商，能够描述要在SDP提供/应答交换中传输的文件，能够在两个端点之间承载MIME对象，并且使用可靠的传输协议（例如TCP）。
This specification defines a set of SDP attributes that describe a file to be transferred between two endpoints. The information needed to describe a file could be potentially encoded in a few different
此规范定义了一组SDP属性，用于描述要在两个端点之间传输的文件。描述文件所需的信息可能以几种不同的方式编码
ways. The MMUSIC working group considered a few alternative approaches before deciding to use the encoding described in Section 6. In particular, the working group looked at the MIME 'external-body' type and the use of a single SDP attribute or parameter.
方式。MMUSIC工作组在决定使用第6节中描述的编码之前，考虑了一些替代方法。特别是，工作组研究了MIME“external body”类型和单个SDP属性或参数的使用。
A MIME 'external-body' could potentially be used to describe the file to be transferred. In fact, many of the SDP parameters this specification defines are also supported by 'external-body' body parts. The MMUSIC working group decided not to use 'external-body' body parts because a number of existing offer/answer implementations do not support multipart bodies.
MIME“外部主体”可能用于描述要传输的文件。事实上，本规范定义的许多SDP参数也由“外部车身”车身零件支持。MMUSIC工作组决定不使用“外部主体”主体部分，因为许多现有的提供/应答实现不支持多部分主体。
The information carried in the SDP attributes defined in Section 6 could potentially be encoded in a single SDP attribute. The MMUSIC working group decided not to follow this approach because it is expected that implementations support only a subset of the parameters defined in Section 6. Those implementations will be able to use regular SDP rules in order to ignore non-supported SDP parameters. If all the information was encoded in a single SDP attribute, those rules, which relate to backwards compatibility, would need to be redefined specifically for that parameter.
第6节中定义的SDP属性中包含的信息可能编码为单个SDP属性。MMUSIC工作组决定不采用这种方法，因为预期实现只支持第6节中定义的参数子集。这些实现将能够使用常规SDP规则来忽略不受支持的SDP参数。如果所有信息都编码在单个SDP属性中，则需要专门为该参数重新定义那些与向后兼容性相关的规则。
Authors' Addresses
作者地址
Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid, ES 28033 Spain
Miguel A.Garcia Martin Ericsson Calle Via de los Poblados 13西班牙东南部马德里28033
EMail: miguel.a.garcia@ericsson.com
EMail: miguel.a.garcia@ericsson.com
Markus Isomaki Nokia Keilalahdentie 2-4 Espoo 02150 Finland
Markus Isomaki诺基亚Keilahdentie 2-4 Espoo 02150芬兰
EMail: markus.isomaki@nokia.com
EMail: markus.isomaki@nokia.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
萨尔瓦托·洛雷托·爱立信·赫萨兰蒂11 Jorvas 02420芬兰
EMail: Salvatore.Loreto@ericsson.com
EMail: Salvatore.Loreto@ericsson.com
Paul H. Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Paul H.Kyzivat Cisco Systems美国马萨诸塞州Boxborough马萨诸塞大道1414号，邮编01719
EMail: pkyzivat@cisco.com
EMail: pkyzivat@cisco.com