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
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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この文書では、SDPは、転送するファイルの属性を記述するために拡張され、RFC 3264で指定されたセッション記述プロトコル（SDP）オファー/アンサーモデルを使用して2つのエンドポイント間の1つのまたは複数のファイルの転送を交渉するためのメカニズムを提供します。オファー側はそれを送信したいファイルまたはそれを受け取りたいファイルのいずれかを記述することができます。回答は、いずれかの個々のファイルに対して個別に申し出を受け入れるか拒否することができます。 1つのまたは複数のファイルの転送が成功した交渉の後に開始されます。メッセージセッションリレープロトコル（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
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]は、2つのエンドポイントは、それらの間のマルチメディアセッションの共通のビューに到達するための機構を提供します。これらのセッションは、多くの場合、音声やビデオなどのリアルタイムメディアストリームを含むが、それに限定されるものではありません。基本的に、任意のメディアコンポーネントタイプは限り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）を送信するためのプロトコルです。プロトコル仕様は、MSRPセッションを確立するためのSDPの使用を記載しています。プレーンテキストメッセージに加えて、MSRPは、画像やビデオクリップのように、任意の（バイナリ）多目的インターネットメール拡張（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:
しかし、ベースラインMSRPは容易にマルチメディアセッション内のファイル転送サービスのためのすべての要件を満たしていません。 4つの主要な不足している機能があります。
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節では、ファイルセレクタの概念を導入しています。詳細な構文と新しいSDP属性や既存のものが使用されている方法についての規則のセマンティクスは第6節第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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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
郵便
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.
操作を引い：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オファー側は、オファー側が送信または受信したい1つのまたは複数のファイルの記述が含まれている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は=」の行は、一度に1つのファイルを転送するために使用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.
各ファイルを記述する属性が直接MIMEから借りてきたそのほとんどが新しいSDP属性のセットでSDPで提供されています。このように、ユーザエージェントは、ファイル名、サイズ、説明、ハッシュ、アイコン（例えば、ファイルの場合絵）、等に基づいて、指定されたファイル転送を受け入れるか否かを決定することができます
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 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.).
SDP方向属性が（例えば、「sendonlyの」、「がrecvonly」）SDP提供者は、ファイルを送信または受信する意思があるかどうか、すなわち、転写の方向を示すために使用されます。回答は、ファイル転送を受け入れると仮定すると、ファイルの実際の転送は、通常のMSRPで行われます。 「sendonlyの」と「がrecvonly」属性は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.
原理的には、ファイル転送は、エンドポイントがそのエンドポイントをSDP回答者とファイル受信側の両方である特定の場合において、本明細書で定義される拡張機能を理解せずにのみ正規MSRPを支持しても動作することができます。それは、拡張属性に注意を払うことなく、任意の通常の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オファーが明確にファイル送信者に要求されたファイルを特定する必要があります。ファイルの名前、サイズ、種類、およびハッシュ：この目的のために、私たちは以下の個々のセレクタの一つ以上で構成されるタプルでファイルセレクタの概念を導入します。ファイルセレクタは、ので、それらのすべての4つは常に存在している必要はありません、セレクタの任意の数を含めることができます。
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, 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.
ファイルの選択プロセスは、ホストで使用可能なすべてのファイルに適用されます。プロセスは「ファイルセレクタ」属性に存在する各セレクタに一致するファイルを選択します。結果は、SDPに記載されたセレクタの存在に依存し、ホストで利用可能なファイルに応じて、ゼロ、1つ、または複数のファイルとすることができます。この文書で指定されたファイル転送機構は、ファイルセレクタが最終的に選択される単一のファイルに最大で生じることを必要とします。ハッシュセレクタが既知である場合、典型的には、正確にゼロまたは1つのファイルを指すファイル・セレクタを生成するのに十分です。しかし、ユニークなファイルを選択し、ファイルセレクタは、常に、オファーで知られていません。時々だけ名前、サイズ、ファイルの種類が知られているので、ファイルセレクタが望ましくない場合である複数のファイルを選択する際に生じ得ます。逆も真である：ファイルセレクタはハッシュセレクタと名前セレクタが含まれている場合、その計算されたハッシュファイルは、ハッシュ・セレクタが存在するファイルに等しいが、リモートホストが、その場合には、ファイルの名前を変更しているおそれがあります名前は、名前のセレクタのそれと一致していません。したがって、この場合には、ファイルの選択プロセスは、ゼロのファイルの選択になります。
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].
私たちは、MSRPでファイルの転送を記述するために必要な情報を提供する新しいSDP [RFC4566]属性の数を定義します。これらはすべて、メディアレベルのみの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
属性= /ファイルセレクタATTR /ファイルDISP-ATTR /ファイル-TR-ID-ATTR /ファイル日付ATTR /ファイルアイコンATTR /ファイルレンジATTR。属性は、RFC 4566で定義されています
file-selector-attr = "file-selector" [":" selector *(SP selector)] selector = filename-selector / filesize-selector / filetype-selector / hash-selector
ファイルセレクタATTR =「ファイルセレクタ」[「：」セレクタ*（SPセレクタ）]セレクタ=ファイル名セレクタ/ファイルサイズセレクタ/ファイルタイプセレクタ/ハッシュセレクタ
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
ファイル名セレクタ=「名前：」DQUOTEファイル名の文字列DQUOTE。 RFC 5234ファイル名の文字列= 1 *（ファイル名文字/パーセントエンコードされた）ファイル名チャー=％x01-09 /％X0B-0C /％のx0E-21 /％x23-24 /％X26-FFで定義さDQUOTE。 NUL、CR、LF、以外の任意のバイト。二重引用符、またはパーセントパーセントエンコード=「％」HEXDIG HEXDIG。 RFC 5234で定義されてHEXDIG
filesize-selector = "size:" filesize-value filesize-value = integer ;integer defined in RFC 4566
ファイルサイズセレクタ=「サイズ：」ファイルサイズ値ファイルサイズ値=整数、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
ファイルタイプセレクタ= "タイプ：" タイプ "/" サブタイプ*（ ";" FT-パラメータ）FT-パラメータ=属性 "=" DQUOTE値ストリングDQUOTE。属性は、RFC 2045で定義されています。リニアホワイトスペースの自由な挿入はありません。このコンテキストで許可。 ;注：値は、文字列は、再エンコードする必要があります。これとの間で変換するとき。 Content-Typeヘッダ。値は文字列=ファイル名の文字列
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
ハッシュセレクタ=「ハッシュ」ハッシュアルゴリズム「：」ハッシュ値のハッシュアルゴリズム=トークン。 IANAハッシュ関数を参照してください。テキスト名のレジストリ。 "SHA-1" は、現在サポートされているハッシュ値= 2HEXDIG *（ "：" 2HEXDIG）のみ。分離された大文字ヘクス、各バイト。コロンによります。 ; RFC 5234で定義されてHEXDIG
file-tr-id-attr = "file-transfer-id:" file-tr-id-value file-tr-id-value = token
ファイル-TR-ID-ATTR = "ファイル転送-ID：" ファイル-TR-ID値ファイル-TR-ID値=トークン
file-disp-attr = "file-disposition:" file-disp-value file-disp-value = token
ファイル・DISP-のattr = "ファイル処分：" ファイル・DISP-値ファイル-DISP-値=トークン
file-date-attr = "file-date:" date-param *(SP date-param)
ファイル日付のattr = "ファイルの日付：" 日付のparam *（SP日-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.
日付PARAM = C-日付PARAM / M-日付PARAM / R-日付PARAM C-日付PARAM = "創造：" DQUOTE日時DQUOTEのM-日付PARAM = "変形" DQUOTE日時DQUOTE R-日付のparam = "読み：" DQUOTE日時DQUOTEを。日時は、RFC 5322で定義されています。数値タイムゾーン（+ HHMMまたは-HHMM）;使用する必要があります。 RFC 5234個のファイルで定義されてDQUOTE。
file-icon-attr = "file-icon:" file-icon-value file-icon-value = cid-url ; cid-url defined in RFC 2392
ファイル・アイコンのattr = "ファイルのアイコン：" ファイルのアイコン値ファイルのアイコン値= CID-URL; RFC 2392で定義されたCID-URL
file-range-attr = "file-range:" start-offset "-" stop-offset start-offset = integer ; integer defined in RFC 4566 stop-offset = integer / "*"
ファイル・レンジATTR =「ファイル範囲：」開始オフセット「 - 」停止 - 開始オフセットオフセット=整数。整数RFC 4566ストップ・オフセット=整数/「*」で定義されています
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申し出か答えで使用する場合、「ファイル・セレクタ」属性には、少なくとも1つのセレクタを含まなければなりません。セレクタは、転送するファイルを特徴付けます。 「名前」、「サイズ」、「タイプ」、および「ハッシュ」：この属性には4つのセレクタがあります。
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]の「ファイル名」パラメータと同じでなければなりません。ファイル名は二重引用符や構文は、「名前」セレクタでは許可しないことを他の文字が含まれている場合、彼らはパーセントエンコードする必要があります。 「名前」セレクタは、ローカル・オペレーティング・システムによって、ディレクトリ構造として解釈できる文字を含めることはできません。そのような文字がファイル名に存在する場合、それらはパーセントエンコードする必要があります。
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]の「サイズ」パラメータと同じでなければなりません。 「サイズ」セレクタは、単にファイルのサイズを有しており、そのようなメッセージ/ 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メディアとsubmedia種類が含まれています。一般に、Content-Typeヘッダフィールドで表現することができるものは、（RFC 2045 [RFC2045]を参照）も、「タイプ」セレクタで表すことができます。可能なMIMEメディアタイプの値は、MIMEメディアタイプ[IANA]のための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').
Content-Typeヘッダと「タイプ」セレクタからパラメータを変換パラメータは、従来「タイプ」セレクタのパラメータ（「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アルゴリズムのアドレス空間は、2つのエンドポイント間でハッシュ計算における任意の衝突を回避するのに十分な大きさです。ファイルを転送する場合は受信したファイルの検証が常に成功する必要がありますので、実際のファイル転送プロトコルは、データの信頼性の高い伝送を提供する必要があります。エンドポイントは、ファイルの整合性を保護する必要がある場合は、彼らはこのメモで指定された「ハッシュ」セレクタ以外の何らかのメカニズムを使用する必要があります。
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レジストリに定義されたものです。実装は、この仕様に従って「ハッシュ」セレクタが存在する場合、ハッシュアルゴリズム1（SHA1）[RFC3174]をセキュア米国の計算から得られた160ビットの文字列を追加しなければなりません。必要が生じた場合は、拡張子は、いくつかのハッシュアルゴリズムをサポートするために起草することができます。したがって、本明細書に記載の実装は、「ファイル選択」属性に単一の「ハッシュ」セレクタ以上を含む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.
「ファイル・処分」属性は、ファイルの意図した処分について、他のエンドポイントへの提案を提供します。セクション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.
「創造」パラメータは、ファイルが作成された日付を示します。値は、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.
「読み取り」パラメータは、ファイルが最後に読み込まれた日付を示します。値は、ファイルが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でのバイト-Rangeヘッダを混同してはなりません。前者は、アプリケーションが読み込まれ、輸送のための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
IP4 host.atlanta.example.com S = C IN = IP4 host.atlanta.example.comトン= 0 0メートル=メッセージ7654 TCP / MSRP、V IN = 0 0 =アリス2890844526 2890844526 * I =これは私の最新画像Aであります= sendonlyで=-型を受け入れる：メッセージ/ CPIM aは=受け入れる-ラップタイプ：* =パス：メーカー希望小売価格：//atlanta.example.com：7654 / jshA7we; TCP A =ファイルセレクタ：名前：「私のクールpicture.jpg」タイプ：image / jpegのサイズ：32349ハッシュ：SHA-1：72：24：5F：E8：65：3D：DA：F3：71：36：2F：86：D4：71：91：3E： E4：A2：CE：2EのA =ファイル転送-ID：vBnG916bdberum2fFEABR1FR3ExZMUrd A =ファイル処分：添付A =ファイル日付：創造： "月、2006年5月15日15時01分31秒0300" A =ファイルのアイコン：CID：id2@alicepc.example.com A =ファイル範囲：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.
注：上図の「ファイル・セレクタ」属性は、書式設定の目的のために3列に分割されています。実際の実装では、単一の行でそれをエンコードします。
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.
ファイル転送操作のための関心の2人のコンテンツ処分があります。一方では、ファイルの送信者は、単にファイルをファイル受信側の機器ですぐにレンダリングすることができます。一方、ファイルの送信者は、単にファイルは、ファイルの受信でレンダリングされるべきではないと、ファイル受信機に指示することもできます。受信者のユーザーエージェントは、ファイルの処分に関してユーザと対話することをお勧めしますか、ユーザーがアクションを起こすまでには、ファイルを保存することがあります。いずれにしても、正確なアクションは実装に依存しています。
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で新しい「ファイル・処分」属性のContent-処分タイプの既存の「添付ファイル」の値を使用しています。デフォルト値は、すなわち、SDPの「ファイル・処分」属性が存在しない場合は、「レンダリング」と同じ意味を持ち、「レンダリング」です。
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:
私たちは、オファー側は、ファイルの送信者またはファイルの受信機であるかどうかに応じて、2つの使用例を区別することができます：
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パラメータは、以前のオファー/アンサー交換に関して変更されていない状況で相手に再び送信されることを、例えば、必要とされます。さんがセッションをリフレッシュする再INVITEリクエストを使用してSIPセッションタイマー（RFC 4028）[RFC4028]を、考えてみましょう。 RFC 4028は、セッションをリフレッシュするために、INVITEの再に変更されていないSDPを送信することをお勧めします。これは再INVITEファイル転送操作を記述した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.
2つのエンドポイントが正常にエンドポイントの1つは、既存のセッションに追加のメディアストリームを追加したいとき、現在行われているファイル転送、上合意した場合にも、同様のシナリオが発生します。この場合、エンドポイントは、SDPを含ん再INVITE要求を送信します。 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の繰り返しであるかどうかを判断するために、両方のエンドポイントに役立ちます。新しいファイル転送が受諾の場合には、ファイルの実際の転送を引き起こすだろう、1です。これは、通常、エンドポイントは、既存のファイル転送を中止し、もう一度ファイル転送を再開したいと考え、新たなオファー/アンサー交換、または例中の場合です。一方、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アンサーは「ファイル転送-ID」の値を反映しなければならない含まれる属性SDPオファーインチこれは事実上ゼロにメディアストリームを設定すると「ファイル転送-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」属性は、現在進行中のファイル転送を中止し、もう一度再起動するために使用することができます。 2つのエンドポイントは、ファイル転送に同意し、ファイルの実際の転送が行われていることを前提としています。ファイル転送の途中である時点で、一方のエンドポイントは、新しいグローバルに固有のランダムな値である「ファイル転送-ID」属性の値を除いて、最初の1に等しい新しいSDPのオファーを送信します。これは、オファー側は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.
エンドポイントが「ファイル転送-ID」属性値が以前いずれかを送信に対して変化しないSDPオファーが、新しいファイルが選択されているように、ファイル選択の変更を作成する場合、これはエラーとみなされ、 SDPの回答は、（例えば、SDPアンサーにゼロにポート番号を設定することにより）ファイル転送操作を中止しなければなりません。エンドポイントは「ファイル選択」選択されたファイル（例えば、ハッシュ・セレクタを追加することによって）変更されない限り、属性を変更してもよいことに留意されたいです。しかし、前のSDPオファー/アンサー交換で説明したのと同じファイルを転送するために要求された場合、エンドポイントは、「ファイル・セレクタ」属性の値を変更しないことをお勧めします。
Figure 3 summarizes the relation of the 'file-transfer-id' attribute with the file selector in subsequent SDP exchanges.
図3はその後のSDP交換のファイルセレクタと「ファイル転送-ID」属性の関係をまとめたものです。
\ | | |
\ 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：その後のSDP交換におけるファイルの選択と「ファイル転送-ID」属性の関係
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 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を送信したいです。 SDPオファーは、ファイル転送に対応するメディア記述行を維持するSDPファイル記述を作成します。 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.
回答へまたはから1つまたは複数のファイルを送信または受信したいオファー側は、ファイルごとに1つの「M =」行を含むセッションのSDP [RFC4566]の記述を構築する必要があります。 MSRPは、転送メカニズムとして使用される場合、各「M =」行はまたMSRP [RFC4975]の手順に従って、単一のMSRPセッションを記述する。既に前のSDP交換において存在していた可能性のある「M =」行は、通常、非修飾保持されます。新しい「M =」行は（「M =」ラインが再利用される場合、セクション8.6の場合について説明し）、その後追加されます。すべてのメディア・ラインが指定され、MSRPによって必要とされる[RFC4975]（例えば、「=パス」、「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オファーを作成します。ファイル送信者は、「タイプ」、「サイズ」、またはそれぞれ、ファイルの種類、サイズ、またはハッシュを表すの「ハッシュ」セレクタの少なくとも1つを含むメディア行属性「ファイルセレクタ」を追加しなければなりません。ファイルの送信者が新しいファイル転送を開始したい場合は、ファイルの送信者は、新しいグローバルに固有のランダムな識別子の値を含む「ファイル転送-ID」属性を追加する必要があります。また、ファイルの送信者は、セッションまたはSDPオファーにメディア「sendonlyの」属性を追加しなければなりません。次に、ファイルの送信者は、ファイルの受信機に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.
ファイルの送信者は、属性、および「ファイル・アイコン」、「ファイル・処分」、および「ファイル日付が」はさらに、転送するファイルを記述した属性「ファイルセレクタ」で「名前」セレクタを追加するかもしれません。 「ファイル・処分」属性は、プレゼンテーションの提案提供します（たとえば：ファイル送信者は、ファイル受信者がファイルかどうかをレンダリングしたいと思います）。 3つの日付属性は、ファイルの年齢の目安と回答を提供します。ファイルの送信者は、開始を示す「ファイル・レンジ」属性を追加し、ファイルのオフセットを停止することがあります。
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 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 =」の行を生成します。このように、回答者は、通常のSDP [RFC4566]の手順に従って、ゼロにそれらに関連する「M =」行のポート番号を設定することにより、個々のファイルを拒否することができます。同様に、回答はゼロ以外の値にそれに関連する「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セッションを使用して転送されていることを意味します。 RFC 4975 [RFC4975]のセクション8.1で説明したようにしかし、これらすべてのMSRPセッションは、単一のTCP接続を介して実行するように設定することができます。同じ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 =」行のポート番号を設定します。拒否された答えは、その値がSDPオファーの対応する値を反映「ファイルセレクタ」と「ファイル転送-ID」属性を含まなければなりません。
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 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.
ポート番号がゼロとは異なっているとSDPオファーは新しい「ファイル転送-ID」属性が含まれている場合、それは、新しいファイル転送の要求をシグナリングしています。 SDPの回答は、ファイルを記述する属性とパラメータを抽出し、通常はファイルの受信を受け入れるか拒否するユーザーからの許可を要求します。ファイル転送操作が受け付けられた場合、ファイル受信機は、RFC 3264 [RFC3264]で指定された手順に従ってSDPアンサーを作成する必要があります。オファーは「名前」、「タイプ」、または「ファイル・セレクタ」属性の「サイズ」セレクタが含まれている場合、回答は答えにそれらをコピーする必要があります。ファイルの受信をコピー「ファイル転送-ID」の値は、SDPアンサーに属性。次に、ファイル受信機は、RFC 3264 [RFC3264]で指定された手順に従って、セッション又はメディア「がrecvonly」属性を追加しなければなりません。ファイル受信機は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 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.
ファイルの送信者は、常に、RFC 3264 [RFC3264]で指定されたSDPオファー/アンサー手順に従ってSDP回答を作成する必要があります。ファイル送信者は、「ファイル選択」メディア属性行で符号化された受信されたSDPオファーのファイルセレクタを検査します。次に、ファイルの送信者は、彼らがあれば（「名前」、「タイプ」、「サイズ」で一つ一つに一致するファイルを選択する意味ファイルセレクタを適用し、「ファイル選択」属性ラインの「ハッシュ」セレクタ存在しています）。ファイルセレクタは、ゼロ以上の候補のファイルが送信されるように識別します。ファイルセレクタが任意のファイルを識別することができない場合、場合、回答はゼロにポート番号を設定することにより、ファイル転送のための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応答の「ファイルセレクタ」属性行で「タイプ」セレクタを含むかもしれません。アンサーはまた、「ファイル・アイコン」と「ファイル・処分」はさらにファイルを記述するための属性を含むかもしれません。アンサーはまた、「名前」と「ファイル・セレクタ」属性の「サイズ」セレクタ、および「ファイル日付」属性が含まれるかもしれないが、実際のファイル転送プロトコル場合はSDPアンサーにそれらを含めるしないことをお勧めします（例えば、MSRP [RFC4975]）は等価パラメータでのContent-Dispositionヘッダーフィールド[RFC2183]を収容することができます。
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 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.
SDPのオファーは「ファイルレンジ」属性が含まれていると、ファイルの送信者はそこで宣言されたオクテットの範囲を送信するために受諾した場合、ファイルの送信者は、同じ値の範囲を持つSDP答えで「ファイルレンジ」属性を含まなければなりません。ファイルの送信者がオクテットの範囲を送信受け入れない場合は、ファイルの転送を拒否すべきです。
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 SEND要求が送信されると仮定する。ファイル送信者はMSRPの手順に従ってSEND要求のエンドラインの継続フィールドに「＃」文字、（RFC 4975のセクション7.1 [RFC4975]を参照）を含むことにより、MSRPメッセージを中止します。ファイルは、1つのMSRPメッセージとして送信されるため、効果的にMSRPメッセージを中断すると、ファイル転送を中止します。ファイル受信機は200応答でMSRP SEND要求を認めます。次に、ファイル送信者は、ファイル転送を（RFC 3264のセクション8.2 [RFC3264]を参照）について説明係る「M =」行にゼロにポート番号を設定し、新しいSDPオファーを作成することによって、MSRPセッションを閉じる必要があります。この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 |
|----------------------->|
| |
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 SEND要求の失敗、レポートヘッダーの値に応じて、2つの可能なシナリオがあります。今MSRP SEND要求が「NO」とは異なる値に設定障害、レポートヘッダを含む図5に示されたシナリオを想定。ファイル受信機は進行中のファイル転送を中止したい場合、ファイル受信機は現在のMSRP SEND要求にMSRP 413応答を生成する（RFC 4975 [RFC4975]のセクション10.5を参照）。次に、ファイル受信機は、ファイル転送を（RFC 3264のセクション8.2 [RFC3264]を参照）について説明係る「M =」行にゼロにポート番号を設定し、新しいSDPオファーを生成することによって、MSRPセッションを閉じる必要があります。この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 |
|<-----------------------|
| |
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 SEND要求は、値「なし」に設定障害、レポートヘッダーが含まれている場所を取っています。ファイル受信が進行中の転送を中止したい場合には、ファイル転送を記述する関連する「M =」行にゼロにポート番号を設定し、新しいSDPオファーを生成することによって、MSRPセッションを閉じる必要があります（RFC 3264のセクション8.2を参照してください[RFC3264]）。この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 |
|<-----------------------|
| |
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.
進行中のMSRP SEND要求が送信されている場合は、ファイル転送のための関連の「M =」行にゼロにポート番号を設定SDPオファーを受信するファイル送信者は、まず、中に「＃」文字を含めることにより、MSRPメッセージをアボートMSRP手順に従ってSEND要求のエンドラインの継続フィールド（RFC 4975のセクション7.1 [RFC4975]を参照）。ファイルは、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のセクション9 [RFC3264]を参照）、別のエンドポイントへの能力を示すための設備を提供します。機構は、（例えばSIP OPTIONS要求など）機能クエリを提供するようなSIPのような高レベルのプロトコル、[RFC3261]を、想定しています。 RFC 3264 [RFC3264]は、このような機能クエリに対する応答に含まれるSDPを構築する方法を示します。このように、RFC 3264は、エンドポイントが含まれているSDPボディを構築したことを示し
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 =メッセージ」行のための「ファイル選択」のメディア属性を追加すべきである実装エンドポイント。 'ファイルセレクタのメディア属性は、すなわち、それがどのセレクタを含んではならない、空でなければなりません。エンドポイントは、この仕様で定義されている他のファイル属性のいずれかを追加してはなりません。
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 =」行を使用しています。したがって、各MSRPセッションは、1つのファイルを転送するために使用されるセクション8.2およびセクション8.3の手順に従って確立されました。だから、送信者にのみSDPオファーまたは回答で説明したファイルを送信するために、専用のMSRPセッションを使用しなければなりません。つまり、送信者が同じ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 SENDの要求を送信するために有効です。 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メッセージのオクテットの最大数を示す、ファイルを指定MSRP「M =」の行に「最大サイズ」属性を追加するかもしれません。ファイルの送信者は、得られたセッションに送信されたメッセージの「最大サイズ」の制限を超えてはなりません。
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]を実装します。ラッパーの使用は、（RFC 4975でセクション8.6 [RFC4975]を参照）SDPで交渉されます。最後に、ファイル送信側アプリケーションは、輸送のためにMSRPするコンテンツ（例えば、メッセージ/ CPIM体）を提供します。 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は、ファイルを転送するために使用されるとき、セクション7に示すように、MSRPコンテンツ-Dispositionヘッダーはまた、値「アタッチメント」を取ることができます。
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 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.
ファイル転送が完了すると、ファイル送信者は、MSRPセッションを閉じる必要とMSRPセッションを閉じることに対するMSRP [RFC4975]の手順に従って動作しなければなりません。 MSRPセッション管理は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.
アイコン：この仕様は、ファイルの送信者は、画像ファイルの小さなプレビューを含めることができます。 「ファイルアイコン」属性は、実際のアイコンが含まれている追加の体を指すのContent-ID（CID）URL [RFC2392]を含んでいます。アイコンがSDP本体に沿って別体として送信されるため、ファイル送信者は、SDPボディとMIMEマルチパート/関連する体内のアイコン体をラップしなければなりません。したがって、本明細書に記載の実施態様は、マルチパート/関連するMIMEタイプ[RFC2387]を実装しなければなりません。マルチパート/関連するMIMEラッパーを作成する場合、SDP本体は、RFC 2387によると、[RFC2387]マルチパート/関連するMIMEラッパーに第1の本体として識別されるか、または明示的に「開始」パラメータによって識別されるルート体でなければなりません。 RFC 2387 [RFC2387]によれば、「タイプ」パラメータは、ルート体、すなわち、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ボディを実現し、どちらもすることをリモートエンドポイントにファイルを送信しようとしていることを前提としています。ファイルの送信者は、SDP身体の部分とアイコン本体部と、マルチパート/関連MIMEボディが含まれているSDPのオファーを送ります。マルチパートMIMEタイプをサポートしないファイル受信機は、より高いプロトコル機構（例えば、SIP）を介して、SDPオファーを拒否します。この場合、ファイルの送信者が、アイコン本体部を除去（即ち、マルチパートMIMEなし）単一SDPボディを作成し、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の詳細は簡単に簡潔にするために示されているがSIP [RFC3261]は、SDPオファー/アンサー交換を輸送するために使用されることを想定しています。
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提供者は、ボブ（回答）に画像ファイルを送信することを望みます。アリスのユーザエージェントクライアント（UAC）は、彼女がボブのユーザエージェントサーバ（UAS）に送信したいファイルの記述が含まれている一方向のSDPオファーを作成します。説明は、転送されるファイルの内容を表すアイコンを含みます。シーケンスフローは、図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 |
|<-----------------------|
| |
| |
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：アリスが送信するファイルのSDP記述を構築し、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]
<bob@example.com SIP>：アリス<SIP：alice@example.com>にbob@example.com SIP / 2.0：ボブSIPのINVITE;タグは= 1928301774のCall-ID：a84b4c76e66710のCSeq：MAX-をINVITE 1フォワード：70日：日、2006年5月21日午後01時02分03秒GMT連絡先：<SIP：alice@alicepc.example.com>のContent-Type：関連/マルチパート。 =「アプリケーション/ SDP」と入力。境界= "boundary71" のContent-Length：[長さ]
--boundary71 Content-Type: application/sdp Content-Length: [length of SDP]
--boundary71コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：[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 0 =アリス2890844526 2890844526、IN IP4 alicepc.example.com S = C IN = IP4 alicepc.example.comトン= 0 0メートル=メッセージ7654 TCP / MSRP *私は=これは私の最新の写真です= sendonlyで、A =メッセージ/ CPIM aは=受け入れる-ラップタイプ：-型を受け入れる* =パス：メーカー希望小売価格：//alicepc.example.com：7654 / jshA7we; TCP A =ファイルセレクタ：名前： "私のクールpicture.jpg"タイプ：image / jpegのサイズ：4092ハッシュ：SHA-1：72：24：5F：E8：65：3D：DA：F3：71：36：2F：86：D4：71：91：3E：E4：A2： CE：2E A =ファイル転送-ID：Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE A =ファイル処分：=ファイルの日付を描画：創造： "月、2006年5月15日15時01分31秒0300" A =ファイルのアイコン：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コンテンツタイプ：image / jpegのコンテンツ転送エンコード：バイナリコンテンツID：<id2@alicepc.example.com>のContent-Length：コンテンツの廃棄[画像の長さ]：アイコン
[...small preview icon of the file...]
[...ファイルの小さなプレビューアイコン...]
--boundary71--
--boundary71--
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.
注：Content-Typeヘッダフィールドと上図の「ファイル・セレクタ」属性は、書式設定の目的のために複数の行に分割されています。実際の実装では、単一の行でそれをエンコードします。
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：ボブは、INVITE要求を受信したSDPオファーを調べ、アイコン本体を抽出し、作成日時、ファイルサイズをチェックし、ファイル転送を受け入れることを決定します。だから、ボブは以下の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 0 =ボブ2890844656 2890844656 IN IP4 bobpc.example.com S = C = IN IP4 bobpc.example.com T = 0、M =メッセージ8888 TCP / MSRP * A = recvonlyで=受け入れる-種類：メッセージ/ CPIM =受け入れる-ラップタイプ：* =パス：メーカー希望小売価格：//bobpc.example.com：8888 / 9di4ea; TCP A =ファイルセレクタ：名前： "私のクールpicture.jpg" タイプ：image / jpegのサイズ： 4092ハッシュ：SHA-1：72：24：5F：E8：65：3D：DA：F3：71：36：2F：86：D4：71：91：3E：E4：A2：CE：2E A = [ファイル]転送-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.
注：上図の「ファイル・セレクタ」属性は、書式設定の目的のために3列に分割されています。実際の実装では、単一の行でそれをエンコードします。
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：アリスはボブへのTCP接続を開き、MSRP SEND要求を作成します。このSEND要求は、ファイルの最初のチャンクが含まれています。
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-パスSENDのd93kswow：メーカー希望小売価格：//bobpc.example.com：8888 / 9di4ea;からパスTCP：メーカー希望小売価格：//alicepc.example.com：7654 / iau39; TCPメッセージ-ID：12339sdqwerバイト範囲： 1-2048 / 4385のContent-Type：メッセージ/ 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
... first set of bytes of the JPEG image ...
-------d93kswow+
Figure 10: MSRP SEND request containing the first chunk of actual file
図10：実際のファイルの最初のチャンクを含むMSRP SEND要求
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：アリスは、第2及び最後のチャンクを送信します。 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
メーカー希望小売価格は、TO-パスSENDのop2nc9a：メーカー希望小売価格：//bobpc.example.com：8888 / 9di4ea;からパスTCP：メーカー希望小売価格：//alicepc.example.com：7654 / iau39; TCPメッセージ-ID：12339sdqwerバイト範囲： 2049-4385 / 4385のContent-Type：メッセージ/ CPIM
... second set of bytes of the JPEG image ...
-------op2nc9a$
Figure 11: MSRP SEND request containing the second chunk of actual file
図11：実際のファイルの2番目のチャンクを含むMSRP SEND要求
F6: Bob acknowledges the reception of the first chunk.
F6：ボブは最初のチャンクの受信を認めています。
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 OK応答
F7: Bob acknowledges the reception of the second chunk.
F7：ボブが第二のチャンクの受信を認めています。
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 OK応答
F8: Alice terminates the SIP session by sending a SIP BYE request.
F8：アリスはSIP BYEリクエストを送信することにより、SIPセッションを終了します。
F9: Bob acknowledges the reception of the BYE request and sends a 200 (OK) response.
F9：ボブは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オファーは、最初のボブ、SDPの回答からファイルをフェッチすることを望みます。アリスはボブが、彼女がダウンロードしたい特定のファイルを持っていることを知っています。彼女はいくつかのアウトオブバンドメカニズムにより、ファイルのハッシュを学習しました。ハッシュ選択は、特定のファイルを指すファイル・セレクタを生成するのに十分です。だから、アリスは、ファイルディスクリプタが含まれているSDPオファーを作成します。ボブは、ファイル転送を受け入れ、アリスにファイルを送信します。アリスは完全にボブのファイルを受信したとき、彼女はボブに新しいイメージファイルを送信しよう。したがって、アリスは異なる属性を持つ既存のSDPメディア行を再利用し、彼女はボブのユーザエージェントサーバ（UAS）に送信しようと、新しいファイルの説明を更新します。これが新しいファイル転送動作であるので、特に、アリスは、新しいファイル転送識別子を作成します。図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 |
|----------------------->|
| |
| |
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：アリスは受信したいファイルのSDP記述を構築し、要求がボブ宛のSIP INVITEに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]
<bob@example.com SIP>：アリス<SIP：alice@example.com>にbob@example.com SIP / 2.0：ボブSIPのINVITE;タグは= 1928301774のCall-ID：a84b4c76e66710のCSeq：MAX-をINVITE 1フォワード：70日：日、2006年5月21日午後01時02分03秒GMT連絡先：<SIP：alice@alicepc.example.com>のContent-Type：アプリケーション/ SDPのContent-Length：[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 0 =アリス2890844526 2890844526 IN IP4 alicepc.example.com S = C = IN IP4 alicepc.example.com T = 0、M =メッセージ7654 TCP / MSRP * A = recvonlyで=受け入れる-種類：メッセージ/ CPIM =受け入れるラップ・タイプ：* =パス：MSRP：//alicepc.example.com：7654 / jshA7we;のTCP A =ファイルセレクタ：ハッシュ：SHA-1：72：24：5F：E8：65： 3D：DA：F3：71：36：2F：86：D4：71：91：3E：E4：A2：CE：2EのA =ファイル転送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.
注：上図の「ファイル・セレクタ」属性は、書式設定の目的のために2行に分割されます。実際の実装では、単一の行でそれをエンコードします。
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: 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
F2：ボブは、INVITEリクエストを受信したSDPオファーを調べ、ファイル記述子を計算し、そのハッシュSDPに示されている1に等しいローカルファイルを見つけます。次のようにボブは、ファイル転送を受け付け、SDPアンサーを作成します。v = 0 0 =ボブ2890844656 2890855439 IN IP4 bobpc.example.com S = C = IN IP4 bobpc.example.com T = 0、M =メッセージ8888 TCP / MSRP * A = sendonlyのA =-タイプを受け入れる：メッセージ/ CPIMのA =受け入れるラップ・タイプ：* =パス：MSRP：//bobpc.example.com：8888 / 9di4ea; TCP A =ファイルセレクタ：タイプ：image / JPEGハッシュ：SHA-1：72：24：5F：E8：65：3D：DA：F3：71：36：2F：86：D4：71：91：3E：E4：A2：CE：2EのA =ファイル-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.
注：上図の「ファイル・セレクタ」属性は、書式設定の目的のために2行に分割されます。実際の実装では、単一の行でそれをエンコードします。
F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP SEND request that contains the file.
F4：アリスはボブへのTCP接続を開きます。ボブは、ファイルが含まれているMSRP SEND要求を作成します。
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-パスSENDのd93kswow：メーカー希望小売価格：//alicepc.example.com：7654 / jshA7we;からパスTCP：メーカー希望小売価格：//bobpc.example.com：8888 / 9di4ea; TCPメッセージ-ID：12339sdqwerバイト範囲： 1-2027 / 2027のContent-Type：メッセージ/ 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
...binary JPEG image...
-------d93kswow$
Figure 17: MSRP SEND request containing the actual file
図17：実際のファイルを含むMSRP SEND要求
F5: Alice acknowledges the reception of the SEND request.
F5：アリスはSEND要求の受信を認めています。
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 OK応答
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：アリスはボブ宛て送信されるファイルの説明を挿入し、既存のSDPメディア行を再利用し、SIP再INVITE要求にこれを取り付けます。アリスは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]
bob@example.com SIP / 2.0：ボブSIPのINVITE <SIP：bob@example.com>;タグ= 1928323431より：アリス<SIP：alice@example.com>;タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq： 2マックス前方にINVITE：70日：日、2006年5月21日の午前13時02分33秒GMT連絡先：<SIP：alice@alicepc.example.com>のContent-Type：マルチパート/関連; =「アプリケーション/ SDP」と入力。境界= "boundary71" のContent-Length：[マルチパートの長さ]
--boundary71 Content-Type: application/sdp Content-Length: [length of SDP]
--boundary71コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：[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 0 =アリス2890844526 2890844527、IN IP4 alicepc.example.com S = C IN = IP4 alicepc.example.comトン= 0 0メートル=メッセージ7654 TCP / MSRP *私は=これは私の最新の写真です= sendonlyで、A =名称： "sunset.jpg" タイプ：;メッセージ/ CPIMのA =受け入れるラップ・タイプ：* =パス：MSRP：//alicepc.example.com TCP A =ファイルセレクタ7654 / iau39を、型を受け入れます画像/ JPEGサイズ：4096ハッシュ：SHA-1：58：23：1F：E8：65：3B：BC：F3：71：36：2F：86：D4：71：91：3E：E4：B1：DF： 2FのA =ファイル転送-ID：ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO A =ファイル処分：=ファイルの日付を描画：創造： "日、2006年5月21日夜1時02分15秒0300" A =ファイルのアイコン：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コンテンツタイプ：image / jpegのコンテンツ転送エンコード：バイナリコンテンツID：<id3@alicepc.example.com>のContent-Length：コンテンツの廃棄[画像の長さ]：アイコン
[..small preview icon...]
[..smallプレビューアイコン...]
--boundary71--
--boundary71--
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.
注：Content-Typeヘッダフィールドと上図の「ファイル・セレクタ」属性は、書式設定の目的のために複数の行に分割されています。実際の実装では、単一の行でそれをエンコードします。
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：ボブは、再INVITE要求を受信したSDPオファーを検査し、アイコンのボディを抽出し、作成日やファイルサイズをチェックし、ファイル転送を受け入れることにしました。だから、ボブは、彼が同じTCPポート番号を再利用するSDP回答を作成しますが、この仕様書の手順に従って、彼の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 0 =ボブ2890844656 2890855440 IN IP4 bobpc.example.com S = C = IN IP4 bobpc.example.com T = 0、M =メッセージ8888 TCP / MSRP * A = recvonlyで=受け入れる-種類：メッセージ/ CPIM =受け入れるラップ・タイプ：* =パス：MSRP：//bobpc.example.com：8888 / eh10dsk; TCP A =ファイルセレクタ：名： "sunset.jpg" タイプ：image / jpegのサイズ：4096ハッシュ36：：：SHA-1：58：23：1F：E8：65：3B：BC：F3：71 2F：86：D4：71：91：3E：E4：B1：DF：2階A =ファイルtransfer- ID：ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCOのA =ファイル処分：レンダリング
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.
注：上図の「ファイル・セレクタ」属性は、書式設定の目的のために3列に分割されています。実際の実装では、単一の行でそれをエンコードします。
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：ボブへのTCP接続がすでに開いている場合、アリスは、TCP接続がファイルを含むMSRP SEND要求を送信することを再利用します。
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-パスSENDのd95ksxox：メーカー希望小売価格：//bobpc.example.com：8888 / eh10dsk;からパスTCP：メーカー希望小売価格：//alicepc.example.com：7654 / iau39; TCPメッセージ-ID：13449sdqwerバイト範囲： 1-2027 / 2027のContent-Type：メッセージ/ 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
...binary JPEG image...
-------d95ksxox+
Figure 21: MSRP SEND request containing the actual file
図21：実際のファイルを含むMSRP SEND要求
F10: Bob acknowledges the reception of the SEND request.
F10：ボブはSEND要求の受信を認めています。
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 OK応答
F11: Then Bob terminates the SIP session by sending a SIP BYE request.
F11：その後、ボブはSIP BYEリクエストを送信することにより、SIPセッションを終了します。
F12: Alice acknowledges the reception of the BYE request and sends a 200 (OK) response.
F12：アリスが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.
アリスは、（この要求は、SDPが含まれていない）ボブにOPTIONSリクエストを送信します。ボブは、SDPは、他のMIMEタイプを含むことができるCPIMメッセージのサポートを示す図24に示すSDPを含む200（OK）応答で応答します。エンドポイントが受信できる最大MSRPメッセージのサイズが20000オクテットです。 「ファイルセレクタ」属性の存在は、ファイル転送オファー/アンサー・メカニズムのサポートを示します。
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 0 =ボブ2890844656 2890855439 IN IP4 bobpc.example.com S = - C = IN IP4 bobpc.example.com T = 0、M = 0メッセージTCP / MSRP * A =受け入れる-種類：メッセージ/ CPIM Aが= -ラップタイプを受け入れる：* A =最大サイズ：20000 =ファイルセレクタ
Figure 24: SDP of the 200 (OK) response to an OPTIONS request
図24：OPTIONS要求への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属性は、2つのエンドポイント間で転送されるべきファイルを識別する。エンドポイントは、他のエンドポイントからファイルを受信するために、他のエンドポイントまたは要求にファイルを送信するために提供することができます。前者の場合には、それらの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>
連絡先：ミゲル・ガルシア<miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
電話：+34 91 339 1000
Attribute name: file-selector
属性名：ファイルセレクタ
Long-form attribute name: File Selector
長編属性名：ファイル・セレクタ
Type of attribute: media level only This attribute is subject to the charset attribute
属性の種類：メディアレベルのみこの属性は、charset属性の対象となります
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
仕様：RFC 5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
連絡先：ミゲル・ガルシア<miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
電話：+34 91 339 1000
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
属性の種類：メディアレベルのみこの属性は、charset属性の対象となります
Description: This attribute contains a unique identifier of the file transfer operation within the session.
説明：この属性は、セッション内でファイル転送操作の一意の識別子が含まれています。
Specification: RFC 5547
仕様：RFC 5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
連絡先：ミゲル・ガルシア<miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
電話：+34 91 339 1000
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
仕様：RFC 5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
連絡先：ミゲル・ガルシア<miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
電話：+34 91 339 1000
Attribute name: file-date
属性名：ファイルの日付
Long-form attribute name:
長い形式の属性名：
Type of attribute: media level only This attribute is not subject to the charset attribute
属性の種類：メディアレベルのみこの属性は、charset属性の対象ではありません
Description: This attribute indicates the dates on which the file was created, modified, or last read.
説明：この属性は変更され、ファイルが作成された日付を示し、または最後の読み取り。
Specification: RFC 5547
仕様：RFC 5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
連絡先：ミゲル・ガルシア<miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
電話：+34 91 339 1000
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
属性の種類：メディアレベルのみこの属性は、charset属性の対象ではありません
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
仕様：RFC 5547
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
連絡先：ミゲル・ガルシア<miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
電話：+34 91 339 1000
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
属性の種類：メディアレベルのみこの属性は、charset属性の対象ではありません
Description: This attribute contains the range of transferred octets of the file.
説明：この属性は、ファイルの転送オクテットの範囲が含まれています。
Specification: RFC 5547
仕様：RFC 5547
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.
作者はこのメモで説明した初期のコンセプトを議論するためにマットスティル、ナンシー・グリーン、Adamuはるな、とのArto Leppisaariに感謝したいと思います。このドキュメントの初期バージョンを見直し、有益なコメントを提供するためのペッカKuureに感謝します。イェルク・オット、Jiwey王、Amitkumar Goelさん、Sudha Vsであり、ダン・ウィング、Juuso Lehtinenの、レミデニス・Courmont、コリンパーキンス、Sudhakarアン、ピーター・サン・アンドレ、ジョナサン・ローゼンバーグ、エリックレスコラ、ビクラムChhibber、ベン・キャンベル、リチャード・バーンズ、およびクリス・ニューマンが議論され、このドキュメントにコメントや改善を提供します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年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.、ドルナー、S.、およびK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、RFC 2183、1997年8月。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2387]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、RFC 2387、1998年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2392、1998年8月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレイク、D.とP.ジョーンズは、 "米国は、ハッシュアルゴリズム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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC3862] Klyne、G.、およびD.アトキンス、 "一般的なプレゼンスとインスタントメッセージング（CPIM）：メッセージの形式"、RFC 3862、2004年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4028]、RFC 4028 "セッション開始プロトコル（SIP）におけるセッションタイマー" ドノヴァン、S.およびJ.ローゼンバーグ、2005年4月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483]バーガー、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]ジェニングス、C.、マーイ、R.、およびA.ローチ、RFC 4976、2007年9月の "メッセージセッションリレープロトコル（MSRP）のためのリレー拡張機能"。
[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]ルビー、M.、Lehtonenの、R.、ロカ、V.、およびT. Paila、 "FLUTE - 単方向トランスポート上でファイル配信"、進歩、2008年9月の作業。
Appendix A. Alternatives Considered
付録A.代替を検討します
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.
要件はありません、実際のファイル転送メカニズムに、セッションの説明と交渉に関連しています。したがって、MSRP自体は拡張を必要とせず、そのまま使用することができる一方で、それらを満たすために、SDPに属性の拡張および使用規則を定義するのに十分であることは当然です。これは事実上、この仕様で撮影したアプローチです。もう一つの目標はやや低下した機能とはいえ、いくつかのケースでは可能性はまだそれをサポートしていない通常のMSRP終点は、ファイル転送セッションにおけるエンドポイントとして機能するように、SDP拡張子を指定することでした。
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.
上記の議論に基づくと、この文書は、セッション内の転送プロトコルとしてMSRPを使用して、SDPオファー/アンサーモデルとファイル転送サービスの要件を満たすために必要なSDP属性の拡張機能や使用規則を定義します。
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を交換することが可能です。必要が生じた場合には仕様のこの種は、別の文書として記述することができます。本質的に、そのようなプロトコルは、（RFC 3264 [RFC3264]）SDPオファー/アンサー交換で交渉されることができ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 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.
この仕様は、2つのエンドポイント間で転送されるファイルを記述するSDP属性のセットを定義します。ファイルを記述するために必要な情報は、潜在的に、いくつかの異なる方法でエンコードすることができます。 MMUSICワーキンググループは、特定のセクション6に記載の符号化を使用することを決定する前に、いくつかの代替的なアプローチを検討し、ワーキンググループは、MIME「外部ボディ」型と単一の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ワーキンググループは、実装がこれらの実装は、非サポートSDPパラメータを無視するために、定期的なSDPルールを使用することができるであろうセクション6で定義されたパラメータのサブセットのみをサポートすることが予想されるため、このアプローチに追従しないことを決定しました。すべての情報が単一のSDP属性でエンコードされた場合、互換性を後方に関連これらの規則は、そのパラメータのために特別に再定義される必要があるであろう。
Authors' Addresses
著者のアドレス
Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid, ES 28033 Spain
ミゲルA.ガルシア・マーティン・エリクソン・ストリート経由・デ・ロス・Poblados 13マドリード、ES 28033スペイン
EMail: miguel.a.garcia@ericsson.com
メールアドレス：miguel.a.garcia@ericsson.com
Markus Isomaki Nokia Keilalahdentie 2-4 Espoo 02150 Finland
マルクスIsomäkiノキアKeilalahdentie 2-4 02150エスポーフィンランド
EMail: markus.isomaki@nokia.com
メールアドレス：markus.isomaki@nokia.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
サルヴァトーレ・ロレートエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Salvatore.Loreto@ericsson.com
メールアドレス：Salvatore.Loreto@ericsson.com
Paul H. Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
ポールH. Kyzivatシスコシステムズ1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: pkyzivat@cisco.com
メールアドレス：pkyzivat@cisco.com