[要約] RFC 5547は、ファイル転送を可能にするためのSDPオファー/アンサーメカニズムを提供するものであり、SDPセッションの記述と制御を行うためのプロトコルです。目的は、ファイル転送を効率的かつ信頼性の高い方法で実現することです。
Network Working Group M. Garcia-Martin
Request for Comments: 5547 Ericsson
Category: Standards Track M. Isomaki
Nokia
G. Camarillo
S. Loreto
Ericsson
P. Kyzivat
Cisco Systems
May 2009
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
セッション説明プロトコル（SDP）ファイル転送を有効にするためのオファー/回答メカニズム
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document.
このドキュメントは、RFC 3264で指定されたセッション説明プロトコル（SDP）オファー/回答モデルを使用して、2つのエンドポイント間で1つ以上のファイルの転送を交渉するメカニズムを提供します。SDPは、転送されるファイルの属性を記述するために拡張されます。オファーは、送信したいファイルまたは受信したいファイルのいずれかを説明できます。応答者は、個々のファイルごとにオファーを個別に受け入れるか拒否することができます。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）トラバーサルのメカニズムを提供します。最後に、Secure 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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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
o オファー担当者
Additionally, we define the following terms:
さらに、次の用語を定義します。
File sender: The endpoint that is willing to send a file to the file receiver.
ファイル送信者：ファイルレシーバーにファイルを送信することをいとわないエンドポイント。
File receiver: The endpoint that is willing to receive a file from the file sender.
ファイルレシーバー：ファイル送信者からファイルを受け取ることをいとわないエンドポイント。
File selector: A tuple of file attributes that the SDP offerer includes in the SDP in order to select a file at the SDP answerer. This is described in more detail in Section 5.
ファイルセレクター：SDPオファーがSDPにSDPに含まれるファイル属性のタプルは、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 ="行は、一度に単一のファイルを転送するために使用されるMSRPメディアストリームを記述します。つまり、複数の同時ファイルを転送するには、複数の「M =」行と対応するMSRPメディアストリームが必要です。複数のMSRPメディアストリームが単一の輸送層接続を共有できるため、このメカニズムは輸送リソースの過度の使用につながることはありません。
Each "m=" line for an MSRP media stream is accompanied with a few attributes describing the file to be transferred. If the file sender generates the SDP offer, the attributes describe a local file to be sent (push), and the file receiver can use this information to either accept or reject the transfer. However, if the SDP offer is generated by the file receiver, the attributes are intended to characterize a particular file that the file receiver is willing to get (pull) from the file sender. It is possible that the file sender does not have a matching file or does not want to send the file, in which case the offer is rejected.
MSRPメディアストリームの各「m =」行には、転送されるファイルを記述するいくつかの属性が伴います。ファイル送信者がSDPオファーを生成すると、属性は送信されるローカルファイルを記述し（プッシュ）、ファイル受信者はこの情報を使用して転送を受け入れるか拒否できます。ただし、SDPのオファーがファイルレシーバーによって生成される場合、属性は、ファイル受信者がファイル送信者から（引っ張る）ことをいとわない特定のファイルを特徴付けることを目的としています。ファイル送信者に一致するファイルがないか、ファイルを送信したくない可能性があります。その場合、オファーは拒否されます。
The attributes describing each file are provided in SDP by a set of new SDP attributes, most of which have been directly borrowed from MIME. This way, user agents can decide whether or not to accept a given file transfer based on the file's name, size, description, hash, icon (e.g., if the file is a picture), etc.
各ファイルを記述する属性は、SDPで新しいSDP属性のセットによって提供されます。そのほとんどはMIMEから直接借用されています。これにより、ユーザーエージェントは、ファイルの名前、サイズ、説明、ハッシュ、アイコン（ファイルが画像の場合など）に基づいて、特定のファイル転送を受け入れるかどうかを決定できます。
SDP direction attributes (e.g., 'sendonly', 'recvonly') are used to indicate the direction of the transfer, i.e., whether the SDP offerer is willing to send or receive the file. Assuming that the answerer accepts the file transfer, the actual transfer of the files takes 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」）は、転送の方向を示すために使用されます。回答者がファイル転送を受け入れると仮定すると、ファイルの実際の転送は通常の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.
原則として、ファイル転送は、本明細書で定義されている拡張機能を理解せずに通常のMSRPのみをサポートするエンドポイントでも機能します。そのエンドポイントがSDP回答者とファイルレシーバーの両方である特定の場合。通常のMSRPエンドポイントは、拡張属性に注意を払わずに通常のMSRPオファーに応答するため、オファーに応答します。ただし、このようなシナリオでは、受信者はセッションの理由を（いずれかのプロトコル手段で）知らず、ファイル属性に基づいてそれを受け入れる/拒否することができないため、ユーザーエクスペリエンスが低下します。
When the file receiver generates the SDP offer, this SDP offer needs to unambiguously identify the requested file at the file sender. For this purpose, we introduce the notion of a file selector, which is a tuple composed of one or more of the following individual selectors: the name, size, type, and hash of the file. The file selector can include any number of selectors, so all four of them do not always need to be present.
ファイルレシーバーがSDPオファーを生成すると、このSDPオファーは、ファイル送信者の要求されたファイルを明確に識別する必要があります。この目的のために、ファイルの1つ以上の個々のセレクターで構成されるタプルであるファイルセレクターの概念を紹介します。ファイルの名前、サイズ、タイプ、ハッシュです。ファイルセレクターには、任意の数のセレクターを含めることができるため、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つ、またはそれ以上のファイルにすることができます。このドキュメントで指定されたファイル転送メカニズムでは、ファイルセレクターが最終的に最終的に選択されることを選択する必要があります。通常、ハッシュセレクターがわかっている場合、正確にゼロまたは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
file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector = filename-selector / filesize-selector /
filetype-selector / hash-selector
filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE defined in RFC 5234
filename-string = 1*(filename-char/percent-encoded)
filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF
; any byte except NUL, CR, LF,
; double quotes, or percent
percent-encoded = "%" HEXDIG HEXDIG
; HEXDIG defined in RFC 5234
filesize-selector = "size:" filesize-value
filesize-value = integer ;integer defined in 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
hash-selector = "hash:" hash-algorithm ":" hash-value
hash-algorithm = token ; see IANA Hash Function
; Textual Names registry
; only "sha-1" currently supported
hash-value = 2HEXDIG *(":" 2HEXDIG)
; Each byte in upper-case hex, separated
; by colons.
; HEXDIG defined in RFC 5234
file-tr-id-attr = "file-transfer-id:" file-tr-id-value file-tr-id-value = token
file-tr-id-attr = "file-transfer-id：" file-id-value file-tr-id-value = token
file-disp-attr = "file-disposition:" file-disp-value file-disp-value = token
file-disp-attr = "file-disposition：" file-disp-value file-disp-value = token
file-date-attr = "file-date:" date-param *(SP date-param)
date-param = c-date-param / m-date-param / r-date-param
c-date-param = "creation:" DQUOTE date-time DQUOTE
m-date-param = "modification:" DQUOTE date-time DQUOTE
r-date-param = "read:" DQUOTE date-time DQUOTE
; date-time is defined in RFC 5322
; numeric timezones (+HHMM or -HHMM)
; must be used
; DQUOTE defined in RFC 5234 files.
file-icon-attr = "file-icon:" file-icon-value
file-icon-value = cid-url ; cid-url defined in RFC 2392
file-range-attr = "file-range:" start-offset "-" stop-offset
start-offset = integer ; integer defined in RFC 4566
stop-offset = integer / "*"
Figure 1: Syntax of the SDP extension
図1：SDP拡張の構文
When used for capability query (see Section 8.5), the 'file-selector' attribute MUST NOT contain any selector, because its presence merely indicates compliance to this specification.
機能クエリに使用される場合（セクション8.5を参照）、「ファイルセレクター」属性にはセレクターが含まれてはなりません。その存在は、この仕様のコンプライアンスを示すだけであるためです。
When used in an SDP offer or answer, the 'file-selector' attribute MUST contain at least one selector. Selectors characterize the file to be transferred. There are four selectors in this attribute: 'name', 'size', 'type', and 'hash'.
SDPオファーまたは回答で使用する場合、「ファイルセレクター」属性には少なくとも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]の「ファイル名」パラメーターと同じでなければなりません。ファイル名に、「name」セレクターで構文が許可しない二重引用符または他の文字が含まれている場合、それらはパーセントエンコードされている必要があります。「名前」セレクターには、ローカルオペレーティングシステムによってディレクトリ構造として解釈できる文字を含めるべきではありません。そのような文字がファイル名に存在する場合、それらはパーセントエンコードされている必要があります。
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 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').
「ファイルセレクター」属性の「タイプ」セレクターには、MIMEメディアとサブメディアタイプのコンテンツが含まれています。一般に、コンテンツタイプのヘッダーフィールド（RFC 2045 [RFC2045]を参照）で表現できるものはすべて、「タイプ」セレクターで表現できます。可能なMIMEメディアタイプの値は、MIMEメディアタイプのIANAレジストリにリストされているものです[IANA]。ゼロ以上のパラメーターが続くことができます。コンテンツタイプのヘッダーと「タイプ」セレクターからパラメーターを変換する場合、パラメーターは「タイプ」セレクターのパラメーターとして調節の前に再エンコードする必要があります（「FT-Parameter」の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]はハッシュ（メッセージダイジェストと呼ばれる）を使用して、転送の内容を確認します。「ハッシュ」セレクターの目的は2つあります。片側では、プル操作では、ファイルレシーバーがファイル名ではなくハッシュファイルを識別することができます。帯域外のメカニズムによるリモートファイルの。反対側では、プッシュ操作またはプル操作のいずれかで、ファイルレシーバーが受信されたファイルの内容を確認したり、既存のファイルの不必要な送信を避けたりすることさえできます。
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レジストリで定義されているものです。実装この仕様に従って、「ハッシュ」セレクターが存在する場合、US Secure Hash Algorithm 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.
「File-Transfer-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 .
「ファイルデート」属性は、ファイルが作成、変更、または最後に読み取られた日付を示します。この属性には、「作成」、「変更」、「読み取り」パラメーターの組み合わせが含まれている場合がありますが、各タイプの2つ以上を含むことはできません。
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.
「File-Icon」属性は、画像などの特定のファイルタイプで役立ちます。ファイル送信者は、転送されるファイルの内容を表す小さなプレビューアイコンを含むボディへのポインターを含めることができます。ファイル受信者は、そのようなファイルを受信するかどうかを判断するために使用できます。「File-Icon」属性には、RFC 2392 [RFC2392]で指定されているコンテンツID URLが含まれています。セクション8.8には、「File-Icon」属性に関するさらなる考慮事項が含まれています。
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」で示されます。「オフセットの停止」値とは、このオクテットを含めて、ファイル転送が停止するファイルのオクテット位置を指します。「オフセットの停止」値には、ファイルの合計サイズが事前に不明な場合は「*」を含めることができます。この属性がないことは、完全なファイル、つまり、「ファイル範囲」属性が値「1-*」とともに存在するかのように示されます。「ファイルレンジ」属性を、MSRPのバイトレンジヘッダーと混同しないでください。前者は、アプリケーションが輸送のためにMSRPスタックを読み取り、渡すファイルの部分を示しています。MSRPの観点から、ファイルの部分はメッセージ全体として表示されます。後者は、そのメッセージのバイト数を示しており、その塊とメッセージの合計サイズを示しています。したがって、MSRPは、ファイル内のそのオクテットの位置とは無関係に、オクテット番号1で配信されたメッセージのカウントを開始します。
The following is an example of an SDP body that contains the extensions defined in this memo:
以下は、このメモで定義されている拡張機能を含むSDP本体の例です。
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:32349 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=file-disposition:attachment
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com
a=file-range:1-32349
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の新しい「ファイル配置」属性のコンテンツ配置タイプの既存の「添付ファイル」値を使用します。デフォルトの値は「レンダリング」です。つまり、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] Exchangeのコンテキストでセクション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オファーを送信することによって開始されます。Answererは、ファイル転送セッションを受け入れるか拒否し、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がリモートパーティに再び送信されることが必要です。SIPセッションタイマー（RFC 4028）[RFC4028]を考えてみましょう。RFC 4028は、セッションを更新するために、変更されていない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を含む再視点リクエストを送信します。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オファーを再送信した場合、もう1つのエンドポイントは、新しいファイル転送が開始されるかどうかを判断できません。
To address these scenarios, this specification defines the 'file-transfer-id' attribute, which contains a globally unique random identifier allocated to the file transfer operation. The file transfer identifier helps both endpoints to determine whether the SDP offer is requesting a new file transfer or it is a repetition of the SDP. A new file transfer is one that, in case of acceptance, will provoke the actual transfer of a file. This is typically the case of new offer/answer exchanges, or in cases where an endpoint wants to abort the existing file transfer and restart the file transfer once more. On the other hand, the repetition of the SDP does not lead to any actual file to be transferred, potentially because the file transfer is still going on or because it has already finished. This is the case of repeated offer/answer exchanges, which can be due to a number of reasons (session timer, addition/removal of other media types in the SDP, update in SDP due to changes in other session parameters, etc.).
これらのシナリオに対処するために、この仕様では、ファイル転送操作に割り当てられたグローバルに一意のランダム識別子を含む「ファイルトランシャーファーID」属性を定義します。ファイル転送識別子は、両方のエンドポイントがSDPオファーが新しいファイル転送を要求しているかどうかを判断するのに役立ちます。新しいファイル転送とは、受け入れられた場合に、ファイルの実際の転送を引き起こすものです。これは通常、新しいオファー/回答の交換の場合、またはエンドポイントが既存のファイル転送を中止してファイル転送を再開したい場合です。一方、SDPの繰り返しは、ファイルの転送がまだ進行しているか、すでに終了しているために、実際のファイルを転送することにつながるわけではありません。これは、繰り返されるオファー/回答交換の場合です。これは、多くの理由（SDPの他のメディアタイプの追加/削除、他のセッションパラメーターの変更などのSDPの更新など）が原因である可能性があります。
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つのエンドポイントがファイル転送に同意し、ファイルの実際の転送が行われていると仮定します。ファイル転送の途中のある時点で、1つのエンドポイントは、新しいグローバルに一意のランダム値である「ファイルトランスファーID」属性の値を除いて、最初のSDPオファーに等しい新しいSDPオファーを送信します。これは、SDPパラメーターに従って、オファーが既存の転送を中止し、新しい転送を起動したいことを示しています。SDP回答者は、ファイル転送プロトコル（MSRPなど）の手順に従って、進行中のファイル転送を中止し、最初の要求されたOctetからもう一度ファイルの送信を開始する必要があります。セクション8.4では、ファイル転送の中止についてさらに説明します。
If an endpoint creates an SDP offer where the 'file-transfer-id' attribute value does not change with respect to a previously sent one, but the file selector changes so that a new file is selected, then this is considered an error, and the SDP answerer MUST abort the file transfer operation (e.g., by setting the port number to zero in the SDP answer). Note that endpoints MAY change the 'file-selector' attribute as long as the selected file does not change (e.g., by adding a hash selector); however, it is RECOMMENDED that endpoints do not change the value of the 'file-selector' attribute if it is requested to transfer the same file described in a previous SDP offer/answer exchange.
エンドポイントがSDPオファーを作成した場合、「ファイルトランスファーID」属性値が以前に送信されたものに対して変更されないが、ファイルセレクターが変更されて新しいファイルが選択されるように変更され、これはエラーと見なされ、SDP回答者は、ファイル転送操作を中止する必要があります（たとえば、SDP回答でポート番号をゼロに設定することにより）。選択したファイルが変更されない限り（ハッシュセレクターを追加することにより）、エンドポイントは「ファイルセレクター」属性を変更する場合があります。ただし、以前のSDPオファー/回答交換で説明されている同じファイルを転送するように要求されている場合、エンドポイントは「ファイルセレクター」属性の値を変更しないことをお勧めします。
Figure 3 summarizes the relation of the 'file-transfer-id' attribute with the file selector in subsequent SDP exchanges.
図3は、後続の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が転送メカニズムとして使用される場合、MSRP [RFC4975]手順に従って、各「M =」ラインは単一のMSRPセッションも説明します。以前のSDP交換に既に存在していた可能性のある「m =」の線は、通常、変更されていません。新しい「m =」行が後に追加されます（セクション8.6では、「m =」行が再利用される場合のケースについて説明します）。MSRP [RFC4975]によって指定および要求されるすべてのメディアライン属性（例えば、 "a = path"、 "a = accept-typesなど）も含める必要があります。
In a push operation, the file sender creates an SDP offer describing the file to be sent. The file sender MUST add a 'file-selector' attribute media line containing at least one of the 'type', 'size', or 'hash' selectors in indicating the type, size, or hash of the file, respectively. If the file sender wishes to start a new file transfer, the file sender MUST add a 'file-transfer-id' attribute containing a new globally unique random identifier value. Additionally, the file sender MUST add a session or media 'sendonly' attribute to the SDP offer. Then the file sender sends the SDP offer to the file receiver.
プッシュ操作では、ファイル送信者が送信するファイルを説明するSDPオファーを作成します。ファイル送信者は、それぞれファイルのタイプ、サイズ、またはハッシュを示す「タイプ」、「サイズ」、または「ハッシュ」セレクターを含む「ファイルセレクター」属性メディアラインを追加する必要があります。ファイル送信者が新しいファイル転送を開始することを希望する場合、ファイル送信者は、新しいグローバルに一意のランダム識別子値を含む「ファイル転送ID」属性を追加する必要があります。さらに、ファイル送信者は、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オファーを作成し、ファイル送信者に送信します。ファイルレシーバーには「ファイルセレクター」属性を含める必要があり、少なくともそのような属性（つまり、「名前」、「タイプ」、「サイズ」、または「ハッシュ」）に対して定義されているセレクターの1つを含める必要があります。多くの場合、ファイルのハッシュがわかっている場合、ファイルを識別するのに十分です。したがって、オファーは「ハッシュ」セレクターのみを含めることができます。ただし、特にファイルのハッシュが不明な場合、ファイル名、サイズ、およびタイプは、フェッチするファイルの説明を提供できます。ファイルレシーバーが新しいファイル転送を開始したい場合、新しいグローバルに一意のランダム値を含む「ファイルトランスファー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」属性を検査します。「File-Transfer-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回答を作成する必要があります。オファーに「名前」、「タイプ」、または「ファイルセレクター」属性の「サイズ」セレクターが含まれている場合、回答者はそれらを回答にコピーする必要があります。ファイルレシーバーは、SDP回答に対する「ファイルトランスファーID」属性の値をコピーします。次に、ファイルレシーバーは、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オファーのファイルセレクターを検査します。次に、ファイル送信者はファイルセレクターを適用します。これは、「ファイルセレクター」属性行の「名前」、「タイプ」、「サイズ」、および「ハッシュ」セレクターと1つずつ一致するファイルを選択することを意味します（その場合存在しています）。ファイルセレクターは、送信されるゼロ以上の候補ファイルを識別します。ファイルセレクターがファイルを識別できない場合、回答者はポート番号をゼロに設定してファイル転送のためにMSRPストリームを拒否する必要があり、nessererは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回答の「ファイルセレクター」属性行に「タイプ」セレクターを含めることもできます。応答者には、ファイルをさらに説明するために、「ファイルアイコン」および「ファイル拡散」属性を含めることもできます。Answererには、「ファイルセレクター」属性の「名前」および「サイズ」セレクター、および「ファイルデート」属性も含まれている場合がありますが、実際のファイル転送プロトコルの場合、それらをSDP回答に含めないことをお勧めします。（例えば、MSRP [RFC4975]）は、同等のパラメーターを使用して、コンテンツディスポジションヘッダーフィールド[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送信要求が送信されていると仮定します。ファイル送信者は、MSRP手順に従って、送信要求のエンドラインの継続フィールドに「＃」文字を含めることによりMSRPメッセージを中止します（RFC 4975 [RFC4975]のセクション7.1を参照）。ファイルは1つのMSRPメッセージとして送信されるため、MSRPメッセージを中止すると、ファイル転送が効果的に中止されます。ファイルレシーバーは、200の応答でMSRP送信要求を確認します。次に、ファイル送信者は、ファイル転送を記述する関連する「m =」行でポート番号をゼロに設定する新しいSDPオファーを作成することにより、MSRPセッションを閉じる必要があります（RFC 3264 [RFC3264]のセクション8.2を参照）。このSDPオファーは、セクション8.2.1の要件に準拠する必要があります。「File-Transfer-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オファー/回答の手順に従ってSDP回答を作成します（RFC 3264 [RFC3264]）。この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送信要求の障害レポートヘッダーの値に応じて、2つの可能なシナリオがあります。ここで、MSRP送信要求に「no」とは異なる値にセットされた故障レポートヘッダーが含まれる図5に示されているシナリオを想定します。ファイルレシーバーが進行中のファイル転送を中止したい場合、ファイル受信者は現在のMSRP送信要求に対するMSRP 413応答を生成します（RFC 4975 [RFC4975]のセクション10.5を参照）。次に、ファイルの転送を記述する関連「m =」行でポート番号をゼロに設定する新しいSDPオファーを生成することにより、ファイルレシーバーがMSRPセッションを閉じる必要があります（RFC 3264 [RFC3264]のセクション8.2を参照）。このSDPオファーは、セクション8.2.2で表明された要件に準拠する必要があります。「File-Transfer-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送信要求には、値「いいえ」に障害レポートヘッダーセットが含まれています。ファイルレシーバーが継続的な転送を中止したい場合、ファイル転送を記述する関連する「M =」行でポート番号をゼロに設定する新しいSDPオファーを生成することにより、MSRPセッションを閉じる必要があります（RFC 3264のセクション8.2を参照してください[RFC3264]）。このSDPオファーは、セクション8.2.2で表明された要件に準拠する必要があります。「File-Transfer-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.
SDPオファーを受信したファイル送信者は、最初にファイル転送の関連する「M =」行でポート番号をゼロに設定します。MSRP手順に従って、送信要求のエンドラインの継続フィールド（RFC 4975 [RFC4975]のセクション7.1を参照）。ファイルは1つのMSRPメッセージとして送信されるため、MSRPメッセージを中止すると、ファイル転送が効果的に中止されます。次に、ファイル送信者は、SDPオファー/回答の手順に従ってSDP回答を作成します（RFC 3264 [RFC3264]）。この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 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.
SDPオファー/回答モデル[RFC3264]は、別のエンドポイントに機能を示すための規定を提供します（RFC 3264 [RFC3264]のセクション9を参照）。メカニズムは、SIP [RFC3261]などの高レベルのプロトコルを想定しており、機能クエリ（SIPオプションリクエストなど）を提供します。RFC 3264 [RFC3264]は、そのような機能クエリへの応答に含まれるSDPを構築する方法を示しています。そのため、RFC 3264は、エンドポイントがメディアタイプ（メッセージ、MSRPのメッセージ）を含む「M =」ラインを含むSDP本体を構築することを示しています。このドキュメントで指定されている手順を実装するエンドポイントは、「M = Message」行の「ファイルセレクター」メディア属性も追加する必要があります。「ファイルセレクター」メディア属性は空でなければなりません。つまり、セレクターを含めてはなりません。エンドポイントは、この仕様で定義されている他のファイル属性を追加してはなりません。
The SDP offer/answer model [RFC3264] provides rules that allow SDP offerers and answerers to modify an existing media line, i.e., reuse an existing media line with different attributes. The same is also possible when SDP signals a file transfer operation according to the rules of this memo. Therefore, the procedures defined in RFC 3264 [RFC3264], in particular those defined in Section 8.3, MUST apply for file transfer operations. An endpoint that wants to reuse an existing "m=" line to start the file transfer of another file creates a different 'file-selector' attribute and selects a new globally unique random value of the 'file-transfer-id' attribute.
SDPオファー/回答モデル[RFC3264]は、SDP提供者と回答者が既存のメディアラインを変更できるようにするルールを提供します。つまり、既存のメディアラインを異なる属性で再利用します。SDPがこのメモのルールに従ってファイル転送操作を信号する場合も同じことが可能です。したがって、RFC 3264 [RFC3264]で定義されている手順、特にセクション8.3で定義されている手順では、ファイル転送操作に適用する必要があります。既存の「m =」行を再利用して別のファイルのファイル転送を開始したいエンドポイントは、異なる「ファイルセレクター」属性を作成し、「ファイルトランスファーID」属性の新しいグローバルに一意のランダム値を選択します。
If the file offerer resends an SDP offer with a port different than zero, then the 'file-transfer-id' attribute determines whether a new file transfer will start or whether the file transfer does not need to start. If the SDP answerer accepts the SDP, then file transfer starts from the indicated octet (if a 'file-range' attribute is present).
ファイルオファーがゼロとは異なるポートを備えたSDPオファーを再送信する場合、「ファイルトランスファーID」属性は、新しいファイル転送が開始されるかどうか、またはファイル転送を開始する必要がないかどうかを決定します。SDP回答者がSDPを受け入れる場合、ファイル転送は示されたOctetから始まります（「ファイル」属性が存在する場合）。
The file transfer service specified in this document uses "m=" lines in SDP to describe the unidirectional transfer of a file. Consequently, each MSRP session established following the procedures in Section 8.2 and Section 8.3 is only used to transfer a single file. So, senders MUST only use the dedicated MSRP session to send the file described in the SDP offer or answer. That is, senders MUST NOT send additional files over the same MSRP session.
このドキュメントで指定されたファイル転送サービスは、SDPの「M =」行を使用して、ファイルの単方向転送を記述します。その結果、セクション8.2およびセクション8.3の手順に従って確立された各MSRPセッションは、単一のファイルの転送にのみ使用されます。したがって、送信者は、専用のMSRPセッションのみを使用して、SDPオファーまたは回答に記載されているファイルを送信する必要があります。つまり、送信者は同じMSRPセッションで追加のファイルを送信してはなりません。
File transfer may be accomplished using a new multimedia session established for the purpose. Alternatively, a file transfer may be conducted within an existing multimedia session, without regard for the media in use within that session. Of particular note, file transfer may be done within a multimedia session containing an MSRP session used for regular instant messaging. If file transfer is initiated within an existing multimedia session, the SDP offerer MUST NOT reuse an existing "m=" line that is still being used by MSRP (either regular MSRP for instant messaging or an ongoing file transfer). Rather, it MUST add an additional "m=" line or else reuse an "m=" line that is no longer being used.
ファイル転送は、目的のために確立された新しいマルチメディアセッションを使用して達成できます。あるいは、そのセッション内で使用されているメディアに関係なく、既存のマルチメディアセッション内でファイル転送を実施することもできます。特に、ファイル転送は、通常のインスタントメッセージングに使用されるMSRPセッションを含むマルチメディアセッション内で行うことができます。既存のマルチメディアセッション内でファイル転送が開始された場合、SDPオファーは、MSRPによってまだ使用されている既存の「M =」行を再利用してはなりません（通常のMSRPのいずれか、または進行中のファイル転送）。むしろ、追加の「m =」行を追加するか、使用されなくなった「m =」行を再利用する必要があります。
Additionally, implementations according to this specification MUST include a single file in a single MSRP message. Notice that the MSRP specification defines "MSRP message" as a complete unit of MIME or text content, which can be split and delivered in more than one MSRP request; each of these portions of the complete message is called a "chunk". So, it is still valid to send a file in several chunks, but from the MSRP point of view, all the chunks together form an MSRP message: the Common Presence and Instant Messaging (CPIM) message that wraps the file. When chunking is used, it should be noticed that MSRP does not require to wait for a 200-class response for a chunk before sending the following one. Therefore, it is valid to send pipelined MSRP SEND requests containing chunks of the same MSRP message (the file). Section 9.1 contains an example of a file transfer using pipelined MSRP requests.
さらに、この仕様に従って実装は、単一のMSRPメッセージに単一のファイルを含める必要があります。MSRP仕様は、「MSRPメッセージ」をMIMEまたはテキストコンテンツの完全な単位として定義していることに注意してください。完全なメッセージのこれらの各部分は、「チャンク」と呼ばれます。したがって、ファイルをいくつかのチャンクで送信することはまだ有効ですが、MSRPの観点から、すべてのチャンクが一緒にMSRPメッセージを形成します。チャンクを使用する場合、MSRPは次のものを送信する前に、チャンクの200クラスの応答を待つ必要がないことに注意する必要があります。したがって、同じMSRPメッセージ（ファイル）のチャンクを含むPipelined MSRP送信要求を送信することは有効です。セクション9.1には、Pipelined 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]は、「Max-Size」SDP属性を定義します。この属性は、SDPの作成者が受信することをいとわないMSRPメッセージの最大オクテットの数を指定します（「MSRPメッセージ」の定義にもう一度通知）。ファイルレシーバーは、ファイルを指定するMSRP "m ="行に「max-size」属性を追加する場合があり、MSRPメッセージのオクテットの最大数を示します。ファイル送信者は、結果のセッションで送信されたメッセージの「最大サイズ」の制限を超えてはなりません。
In the absence of a 'file-range' attribute in the SDP, the MSRP file transfer MUST start with the first octet of the file and end with the last octet (i.e., the whole file is transferred). If a 'file-range' attribute is present in SDP, the file sender application MUST extract the indicated range of octets from the file (start and stop offset octets, both inclusive). Then the file sender application MAY wrap those octets in an appropriate wrapper. MSRP mandates implementations to implement the message/cpim wrapper [RFC3862]. Usage of a wrapper is negotiated in the SDP (see Section 8.6 in RFC 4975 [RFC4975]). Last, the file sender application delivers the content (e.g., the message/cpim body) to MSRP for transportation. MSRP will consider the delivered content as a whole message, and will start numbering bytes with the number 1.
SDPに「ファイルレンジ」属性がない場合、MSRPファイル転送はファイルの最初のオクテットから開始し、最後のオクテットで終了する必要があります（つまり、ファイル全体が転送されます）。「ファイルレンジ」属性がSDPに存在する場合、ファイル送信者アプリケーションは、ファイルから示されたオクテットの範囲を抽出する必要があります（両方とも包括的）。その後、ファイル送信者アプリケーションは、これらのオクテットを適切なラッパーにラップする場合があります。MSRPは、メッセージ/CPIMラッパー[RFC3862]を実装するための実装を義務付けています。ラッパーの使用は、SDPで交渉されます（RFC 4975 [RFC4975]のセクション8.6を参照）。最後に、ファイル送信者アプリケーションは、輸送のためにコンテンツ（メッセージ/CPIM本体など）をMSRPに配信します。MSRPは、配信されたコンテンツをメッセージ全体として考慮し、番号1でバイトの番号付けを開始します。
Note that the default content disposition of MSRP bodies is 'render'. When MSRP is used to transfer files, the MSRP Content-Disposition header can also take the value 'attachment' as indicated in Section 7.
MSRPボディのデフォルトコンテンツ処分は「レンダリング」であることに注意してください。MSRPを使用してファイルを転送する場合、MSRPコンテンツ閉フォポジションヘッダーは、セクション7に示されているように、値「添付ファイル」を取得することもできます。
Once the file transfer is completed, the file sender SHOULD close the MSRP session and MUST behave according to the MSRP [RFC4975] procedures with respect to closing MSRP sessions. Note that MSRP 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.
この仕様により、ファイル送信者は画像ファイルの小さなプレビュー：アイコンを含めることができます。「File-Icon」属性には、実際のアイコンを含む追加の本体を指すコンテンツID（CID）URL [RFC2392]が含まれています。アイコンはSDPボディに沿って別のボディとして送信されるため、ファイル送信者はMIMEマルチパート/関連ボディでSDPボディとアイコン本体を包む必要があります。したがって、この仕様に従って実装は、マルチパート/関連MIMEタイプ[RFC2387]を実装する必要があります。マルチパート/関連MIMEラッパーを作成する場合、SDPボディはルートボディでなければなりません。RFC2387[RFC2387]によれば、マルチパート/関連MIMEラッパーの最初のボディとして識別されるか、「開始」パラメーターによって明示的に識別されます。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オファーを拒否します。この場合、ファイル送信者はアイコン本体部品を削除し、単一のSDPボディ（つまり、マルチパートMIMEなし）を作成し、SDPのオファーを再送信することをお勧めします。これにより、この仕様を実装せず、ファイルレシーバーでSDPを受け入れる可能性を高めるファイル受信者との後ろ向きの互換性が提供されます。
Since the icon is sent as part of the signaling, it is RECOMMENDED to keep the size of icons restricted to the minimum number of octets that provide significance.
アイコンはシグナリングの一部として送信されるため、重要性を提供するオクテットの最小数に制限されているアイコンのサイズを維持することをお勧めします。
This section shows an example flow for a file transfer scenario. The example assumes that SIP [RFC3261] is used to transport the SDP offer/answer exchange, although the SIP details are briefly shown for the sake of brevity.
このセクションは、ファイル転送シナリオのフローの例を示しています。この例は、SIP [RFC3261]を使用してSDPオファー/回答の交換を輸送することを前提としていますが、SIPの詳細は簡潔にするために一時的に表示されます。
Alice, the SDP offerer, wishes to send an image file to Bob (the answerer). Alice's User Agent Client (UAC) creates a unidirectional SDP offer that contains the description of the file that she wants to send to Bob's User Agent Server (UAS). The description also includes an icon representing the contents of the file to be transferred. The sequence flow is shown in Figure 7.
SDPオファーのアリスは、Bob（The Answerer）に画像ファイルを送信したいと考えています。Aliceのユーザーエージェントクライアント（UAC）は、Bobのユーザーエージェントサーバー（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 sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
boundary="boundary71"
Content-Length: [length]
--boundary71
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:4092 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
a=file-disposition:render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
[...small preview icon of the file...]
[...ファイルの小さなプレビューアイコン...]
--boundary71--
-boundary71--
Figure 8: INVITE request containing an SDP offer for file transfer
図8：ファイル転送のための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.
注：上記の図のコンテンツタイプのヘッダーフィールドと「ファイルセレクター」属性は、フォーマットのためにいくつかの行で分割されます。実際の実装では、単一の行でエンコードします。
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：ボブは招待リクエストを受け取り、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
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：AliceはBOBへのTCP接続を開き、MSRP送信リクエストを作成します。この送信要求には、ファイルの最初のチャンクが含まれています。
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2048/4385
Content-Type: message/cpim
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送信リクエスト
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
... second set of bytes of the JPEG image ...
-------op2nc9a$
Figure 11: MSRP SEND request containing the second chunk of actual file
図11：実際のファイルの2番目のチャンクを含むMSRP送信リクエスト
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：ボブは2番目のチャンクの受容を認めています。
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：Aliceは、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オファーを作成します。ボブはファイルの転送を受け入れ、ファイルをアリスに送信します。アリスがボブのファイルを完全に受け取ったとき、彼女は新しい画像ファイルをボブに送信するつもりです。したがって、Aliceは、既存のSDPメディアラインをさまざまな属性で再利用し、Bobのユーザーエージェントサーバー（UAS）に送信したい新しいファイルの説明を更新します。特に、Aliceは新しいファイル転送操作であるため、新しいファイル転送識別子を作成します。図14は、シーケンスフローを示しています。
Alice's UAC Bob's UAS
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
| |
|(4) (MSRP) SEND (file) |
|<-----------------------|
|(5) (MSRP) 200 OK |
|----------------------->|
| |
|(6) (SIP) INVITE |
|----------------------->|
|(7) (SIP) 200 OK |
|<-----------------------|
|(8) (SIP) ACK |
|----------------------->|
| |
|(9) (MSRP) SEND (file) |
|----------------------->|
|(10) (MSRP) 200 OK |
|<-----------------------|
| |
|(11) (SIP) BYE |
|<-----------------------|
|(12) (SIP) 200 OK |
|----------------------->|
| |
| |
Figure 14: Flow diagram of an offerer requesting a file from the answerer and then sending a file to the answer
図14：応募者のフロー図は、応答者からファイルをリクエストしてから回答にファイルを送信する
F1: Alice constructs an SDP description of the file she wants to receive and attaches the SDP offer to a SIP INVITE request addressed to Bob.
F1：Aliceは、受信したいファイルのSDP説明を作成し、BOBに宛てられたSIP招待リクエストにSDPオファーを添付します。
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
Figure 15: INVITE request containing an SDP offer for file transfer
図15：ファイル転送のための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行に分割されます。実際の実装では、単一の行でエンコードします。
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
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送信要求を作成します。
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool photo.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300";
modification-date="Mon, 15 May 2006 16:04:53 +0300";
read-date="Mon, 16 May 2006 09:12:27 +0300";
size=1931
Content-Type: image/jpeg
...binary JPEG image...
-------d93kswow$
Figure 17: MSRP SEND request containing the actual file
図17：MSRPは実際のファイルを含むリクエストを送信します
F5: Alice acknowledges the reception of the SEND request.
F5：アリスは、送信要求の受信を認めています。
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再インヴァイトリクエストに添付します。AliceはMSRPストリームのTCPポート番号を再利用しますが、この仕様に従ってMSRPセッションと「ファイルトランスファーID」値を変更します。
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>;tag=1928323431
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 2 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:33 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
boundary="boundary71"
Content-Length: [length of multipart]
--boundary71
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844527 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/iau39;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300"
a=file-icon:cid:id3@alicepc.example.com
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id3@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
[..small preview icon...]
[..Small Previewアイコン...]
--boundary71--
-boundary71--
Figure 19: Reuse of the SDP in a second file transfer
図19：2番目のファイル転送でのSDPの再利用
NOTE: The Content-Type header field and the 'file-selector' attribute in the above figure are split in several lines for formatting purposes. Real implementations will encode it in a single line.
注：上記の図のコンテンツタイプのヘッダーフィールドと「ファイルセレクター」属性は、フォーマットのためにいくつかの行で分割されます。実際の実装では、単一の行でエンコードします。
F7: Bob receives the re-INVITE request, inspects the SDP offer and extracts the icon body, checks the creation date and the file size, and decides to accept the file transfer. So Bob creates an SDP answer where he reuses the same TCP port number, but changes his MSRP session, according to the procedures of this specification.
F7：Bobは、再インバイトリクエストを受け取り、SDPのオファーを検査し、アイコン本体を抽出し、作成日とファイルサイズをチェックし、ファイル転送を受け入れることを決定します。そのため、ボブはSDP回答を作成し、同じTCPポート番号を再利用しますが、この仕様の手順に従ってMSRPセッションを変更します。
v=0
o=bob 2890844656 2890855440 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
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送信要求を送信します。
MSRP d95ksxox SEND
To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 13449sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-21T13:02:15-03:00
Content-Disposition: render; filename="Sunset.jpg";
creation-date="Sun, 21 May 2006 13:02:15 -0300";
size=1931
Content-Type: image/jpeg
...binary JPEG image...
-------d95ksxox+
Figure 21: MSRP SEND request containing the actual file
図21：実際のファイルを含むMSRP送信リクエスト
F10: Bob acknowledges the reception of the SEND request.
F10：ボブは、送信要求の受信を認めています。
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：アリスは、さようならリクエストの受信を認め、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は含まれていません）。ボブは、図24に示すSDPを含む200（OK）応答で答えます。SDPは、他のMIMEタイプを含むCPIMメッセージのサポートを示しています。エンドポイントが受信できる最大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
Figure 24: SDP of the 200 (OK) response to an OPTIONS request
図24：オプションリクエストに対する200（OK）応答のSDP
The SDP attributes defined in this specification identify a file to be transferred between two endpoints. An endpoint can offer to send the file to the other endpoint or request to receive the file from the other endpoint. In the former case, an attacker modifying those SDP attributes could cheat the receiver making it think that the file to be transferred was a different one. In the latter case, the attacker could make the sender send a different file than the one requested by the receiver. Consequently, it is RECOMMENDED that integrity protection be applied to the SDP session descriptions carrying the attributes specified in this specification. Additionally, it is RECOMMENDED that senders verify the properties of the file against the selectors that describe it.
この仕様で定義されているSDP属性は、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提供者のIDを検証し、おそらく信頼できるソースからのファイル転送のみを受け入れる必要があります。ファイル送信者のIDを検証するメカニズムは、SIP [RFC3261]およびMSRP [RFC4975]など、SDPを運ぶ高レベルのプロトコルに依存します。
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>
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>
Phone: +34 91 339 1000
電話：34 91 339 1000
Attribute name: file-transfer-id
属性名：File-Transfer-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>
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>
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>
Phone: +34 91 339 1000
電話：34 91 339 1000
Attribute name: file-icon
属性名：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>
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.
著者は、このメモに記載されている最初の概念について議論してくれたMats Stille、Nancy Greene、Adamu Haruna、Arto Leppisaariに感謝したいと思います。このドキュメントの初期バージョンを確認し、有用なコメントを提供してくれたPekka Kuureに感謝します。Joerg Ott、Jiwey Wang、Amitkumar Goel、Sudha VS、Dan Wing、Juuso Lehtinen、Remi Denis-Courmont、Colin Perkins、Sudhakar AN、Peter Saintrre、Jonathan Rosenberg、Eric Rescorla、Vikram Chhitber、Ben Campbell、Rich Campbellクリス・ニューマンは、この文書のコメントと改善について議論し、提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、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.、Dorner、S。、およびK. Moore、「インターネットメッセージのプレゼンテーション情報の通信：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年8月。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2387]レビンソン、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2387、1998年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E。、「コンテンツIDおよびメッセージ-IDユニフォームリソースロケーター」、RFC 2392、1998年8月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174] Eastlake、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（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. Atkins、「共通の存在とインスタントメッセージング（CPIM）：メッセージ形式」、RFC 3862、2004年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「The Message Session Relay Protocol（MSRP）」、RFC 4975、2007年9月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4028] Donovan、S。およびJ. Rosenberg、「セッション開始プロトコル（SIP）のセッションタイマー」、RFC 4028、2005年4月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483] Burger、E。、「セッション開始プロトコル（SIP）メッセージにおけるコンテンツ間接のメカニズム」、RFC 4483、2006年5月。
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.
[RFC4976] Jennings、C.、Mahy、R。、およびA. Roach、「メッセージセッションリレープロトコル（MSRP）のリレー拡張機能」、RFC 4976、2007年9月。
[IANA] IANA, "Internet Assigned Numbers Authority", <http://www.iana.org>.
[IANA] IANA、「インターネットが割り当てられた数字の権限」、<http://www.iana.org>。
[FLUTE-REV] Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, September 2008.
[Flute -Rev] Luby、M.、Lehtonen、R.、Roca、V。、およびT. Paila、「Flute-単方向輸送を介したファイル配信」、2008年9月、進行中の作業。
The requirements are related to the description and negotiation of the session, not to the actual file transfer mechanism. Thus, it is natural that in order to meet them it is enough to define attribute extensions and usage conventions to SDP, while MSRP itself needs no extensions and can be used as it is. This is effectively the approach taken in this specification. Another goal has been to specify the SDP extensions in such a way that a regular MSRP endpoint that does not support them could still in some cases act as an endpoint in a file transfer session, albeit with a somewhat reduced functionality.
要件は、実際のファイル転送メカニズムではなく、セッションの説明と交渉に関連しています。したがって、それらを満たすためには、属性拡張機能と使用規則をSDPに定義するのに十分であり、MSRP自体は拡張機能を必要とせず、そのまま使用できるのは自然なことです。これは、事実上、この仕様で取られたアプローチです。もう1つの目標は、SDP拡張機能を指定することです。これらをサポートしていない通常のMSRPエンドポイントが、機能がやや縮小されているにもかかわらず、ファイル転送セッションのエンドポイントとして機能する可能性があります。
In some ways, the aim of this specification is similar to the aim of content indirection mechanism in the Session Initiation Protocol (SIP) [RFC4483]. Both mechanisms allow a user agent to decide whether or not to download a file based on information about the file. However, there are some differences. With content indirection, it is not possible for the other endpoint to explicitly accept or reject the file transfer. Also, it is not possible for an endpoint to request a file from another endpoint. Furthermore, content indirection is not tied to the context of a media session, which is sometimes a desirable property. Finally, content indirection typically requires some server infrastructure, which may not always be available. It is possible to use content indirection directly between the endpoints too, but in that case there is no definition for how it works for endpoints behind NATs. The level of requirements in implementations decides which solution meets the requirements.
いくつかの点で、この仕様の目的は、セッション開始プロトコル（SIP）[RFC4483]のコンテンツ間接メカニズムの目的と類似しています。両方のメカニズムにより、ユーザーエージェントは、ファイルに関する情報に基づいてファイルをダウンロードするかどうかを決定できます。ただし、いくつかの違いがあります。コンテンツの間接では、他のエンドポイントがファイル転送を明示的に受け入れるか拒否することはできません。また、エンドポイントが別のエンドポイントからファイルを要求することはできません。さらに、コンテンツの間接は、メディアセッションのコンテキストと結びついていません。これは、望ましいプロパティである場合があります。最後に、コンテンツの間接的には通常、いくつかのサーバーインフラストラクチャが必要であり、常に利用できるとは限りません。エンドポイント間でコンテンツの間接を直接使用することも可能ですが、その場合、NATの背後にあるエンドポイントでどのように機能するかについての定義はありません。実装の要件のレベルは、どのソリューションが要件を満たすかを決定します。
Based on the argumentation above, this document defines the SDP attribute extensions and usage conventions needed for meeting the requirements on file transfer services with the SDP offer/answer model, using MSRP as the transfer protocol within the session.
上記の議論に基づいて、このドキュメントでは、SDP属性拡張機能と、SDPオファー/回答モデルでファイル転送サービスの要件を満たすために必要な使用規則を定義し、MSRPをセッション内の転送プロトコルとして使用します。
In principle, it is possible to use the SDP extensions defined here and replace MSRP with any other similar protocol that can carry MIME objects. This kind of specification can be written as a separate document if the need arises. Essentially, such a protocol should be able to be negotiated on an SDP offer/answer exchange (RFC 3264 [RFC3264]), be able to describe the file to be transferred in SDP offer/answer exchange, be able to carry MIME objects between two endpoints, and use a reliable transport protocol (e.g., TCP).
原則として、ここで定義されているSDP拡張機能を使用して、MSRPをMIMEオブジェクトを運ぶことができる他の同様のプロトコルに置き換えることができます。この種の仕様は、必要に応じて別のドキュメントとして記述できます。基本的に、このようなプロトコルは、SDPオファー/回答交換（RFC 3264 [RFC3264]）で交渉できるはずです。SDPオファー/回答交換で転送されるファイルを説明できます。エンドポイント、および信頼できる輸送プロトコル（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ワーキンググループは、実装がセクション6で定義されたパラメーターのサブセットのみをサポートすることが予想されるため、このアプローチに従わないことを決定しました。これらの実装は、サポートされていないSDPパラメーターを無視するために通常のSDPルールを使用できます。すべての情報が単一のSDP属性でエンコードされた場合、後方互換性に関連するこれらのルールは、そのパラメーターに特に再定義する必要があります。
Authors' Addresses
著者のアドレス
Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid, ES 28033 Spain
ミゲル・A・ガルシア・マルティン・エリクソン・カレはデ・ロス・ポブラドス13マドリッド、ES 28033スペイン
EMail: miguel.a.garcia@ericsson.com
Markus Isomaki Nokia Keilalahdentie 2-4 Espoo 02150 Finland
Markus Isomaki nokia keilalahdentie 2-4 Espoo 02150フィンランド
EMail: markus.isomaki@nokia.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Salvatore.Loreto@ericsson.com
Paul H. Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Paul H. Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: pkyzivat@cisco.com