[要約] RFC 6726は、FLUTE（File Delivery over Unidirectional Transport）プロトコルに関するものであり、大容量ファイルの効率的な配信を目的としています。この要約は、FLUTEプロトコルの目的とRFCの概要を簡潔にまとめたものです。
Internet Engineering Task Force (IETF) T. Paila
Request for Comments: 6726 Nokia
Obsoletes: 3926 R. Walsh
Category: Standards Track Nokia/TUT
ISSN: 2070-1721 M. Luby
Qualcomm Technologies, Inc.
V. Roca
INRIA
R. Lehtonen
TeliaSonera
November 2012
FLUTE - File Delivery over Unidirectional Transport
FLUTE-単方向トランスポートを介したファイル配信
Abstract
概要
This document defines File Delivery over Unidirectional Transport (FLUTE), a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC 3926.
このドキュメントでは、一方向トランスポートを介したファイル配信（FLUTE）を定義しています。これは、マルチキャストネットワークに特に適した、インターネットを介したファイルの一方向配信のためのプロトコルです。この仕様は、大規模にスケーラブルなマルチキャスト配信用に設計された基本プロトコルである非同期レイヤードコーディングに基づいています。このドキュメントはRFC 3926を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6726.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6726で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの資料が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicability Statement ....................................5
1.1.1. The Target Application Space ........................5
1.1.2. The Target Scale ....................................5
1.1.3. Intended Environments ...............................5
1.1.4. Weaknesses ..........................................6
2. Conventions Used in This Document ...............................6
3. File Delivery ...................................................7
3.1. File Delivery Session ......................................8
3.2. File Delivery Table .......................................10
3.3. Dynamics of FDT Instances within a File Delivery Session ..12
3.4. Structure of FDT Instance Packets .........................15
3.4.1. Format of FDT Instance Header ......................16
3.4.2. Syntax of FDT Instance .............................17
3.4.3. Content Encoding of FDT Instance ...................21
3.5. Multiplexing of Files within a File Delivery Session ......22
4. Channels, Congestion Control, and Timing .......................23
5. Delivering FEC Object Transmission Information .................24
6. Describing File Delivery Sessions ..............................26
7. Security Considerations ........................................27
7.1. Problem Statement .........................................27
7.2. Attacks against the Data Flow .............................28
7.2.1. Access to Confidential Files .......................28
7.2.2. File Corruption ....................................28
7.3. Attacks against the Session Control Parameters and
Associated Building Blocks ................................30
7.3.1. Attacks against the Session Description ............30
7.3.2. Attacks against the FDT Instances ..................31
7.3.3. Attacks against the ALC/LCT Parameters .............31
7.3.4. Attacks against the Associated Building Blocks .....32
7.4. Other Security Considerations .............................32
7.5. Minimum Security Recommendations ..........................33
8. IANA Considerations ............................................34
8.1. Registration of the FDT Instance XML Namespace ............34
8.2. Registration of the FDT Instance XML Schema ...............34
8.3. Registration of the application/fdt+xml Media Type ........35
8.4. Creation of the FLUTE Content Encoding Algorithms
Registry ..................................................36
8.5. Registration of LCT Header Extension Types ................36
9. Acknowledgments ................................................36
10. Contributors ..................................................37
11. Change Log ....................................................37
11.1. RFC 3926 to This Document ................................37
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................41
Appendix A. Receiver Operation (Informative) ......................44
Appendix B. Example of FDT Instance (Informative) .................45
This document defines FLUTE version 2, a protocol for unidirectional delivery of files over the Internet. This specification is not backwards compatible with the previous experimental version defined in [RFC3926] (see Section 11 for details). The specification builds on Asynchronous Layered Coding (ALC), version 1 [RFC5775], the base protocol designed for massively scalable multicast distribution. ALC defines transport of arbitrary binary objects. For file delivery applications, mere transport of objects is not enough, however. The end systems need to know what the objects actually represent. This document specifies a technique called FLUTE -- a mechanism for signaling and mapping the properties of files to concepts of ALC in a way that allows receivers to assign those parameters for received objects. Consequently, throughout this document the term 'file' relates to an 'object' as discussed in ALC. Although this specification frequently makes use of multicast addressing as an example, the techniques are similarly applicable for use with unicast addressing.
このドキュメントでは、インターネット経由でファイルを一方向に配信するためのプロトコルであるFLUTEバージョン2を定義しています。この仕様は、[RFC3926]で定義されている以前の実験バージョンとの下位互換性はありません（詳細はセクション11を参照）。この仕様は、大規模にスケーラブルなマルチキャスト配信用に設計された基本プロトコルであるAsynchronous Layered Coding（ALC）バージョン1 [RFC5775]に基づいています。 ALCは、任意のバイナリオブジェクトの転送を定義します。ただし、ファイル配信アプリケーションの場合、オブジェクトを転送するだけでは不十分です。エンドシステムは、オブジェクトが実際に何を表しているかを知る必要があります。このドキュメントでは、FLUTEと呼ばれる手法について説明します。これは、受信者が受信したオブジェクトにこれらのパラメータを割り当てることができるように、ファイルのプロパティをALCの概念にシグナリングおよびマッピングするメカニズムです。したがって、このドキュメント全体で、「ファイル」という用語は、ALCで説明されている「オブジェクト」に関連しています。この仕様では、例としてマルチキャストアドレッシングを頻繁に使用していますが、この技術は、ユニキャストアドレッシングでの使用にも同様に適用できます。
This document defines a specific transport application of ALC, adding the following specifications:
このドキュメントでは、ALCの特定のトランスポートアプリケーションを定義し、次の仕様を追加します。
- Definition of a file delivery session built on top of ALC, including transport details and timing constraints.
- トランスポートの詳細やタイミングの制約など、ALCの上に構築されたファイル配信セッションの定義。
- In-band signaling of the transport parameters of the ALC session.
- ALCセッションのトランスポートパラメータのインバンドシグナリング。
- In-band signaling of the properties of delivered files.
- 配信されたファイルのプロパティのインバンドシグナリング。
- Details associated with the multiplexing of multiple files within a session.
- セッション内の複数のファイルの多重化に関連する詳細。
This specification is structured as follows. Section 3 begins by defining the concept of the file delivery session. Following that, it introduces the File Delivery Table, which forms the core part of this specification. Further, it discusses multiplexing issues of transmission objects within a file delivery session. Section 4 describes the use of congestion control and channels with FLUTE. Section 5 defines how the Forward Error Correction (FEC) Object Transmission Information is to be delivered within a file delivery session. Section 6 defines the required parameters for describing file delivery sessions in a general case. Section 7 outlines security considerations regarding file delivery with FLUTE. Last, there are two informative appendices. Appendix A describes an envisioned receiver operation for the receiver of the file delivery session. Readers who want to see a simple example of FLUTE in operation should refer to Appendix A right away. Appendix B gives an example of a File Delivery Table.
この仕様は次のように構成されています。セクション3では、ファイル配信セッションの概念を定義することから始めます。続いて、この仕様の中核となるファイル配信テーブルを紹介します。さらに、ファイル配信セッション内の送信オブジェクトの多重化の問題についても説明します。セクション4では、FLUTEでの輻輳制御とチャネルの使用について説明します。セクション5では、ファイル転送セッション内で転送エラー訂正（FEC）オブジェクト転送情報を配信する方法を定義します。セクション6では、一般的なケースでファイル配信セッションを説明するために必要なパラメーターを定義します。セクション7では、FLUTEを使用したファイル配信に関するセキュリティの考慮事項について概説します。最後に、有益な付録が2つあります。付録Aでは、ファイル配信セッションの受信者に対して想定される受信者操作について説明します。運用中のFLUTEの簡単な例を見たい読者は、すぐに付録Aを参照してください。付録Bに、ファイル配信テーブルの例を示します。
This specification contains part of the definitions necessary to fully specify a Reliable Multicast Transport (RMT) protocol in accordance with [RFC2357].
この仕様には、[RFC2357]に従ってReliable Multicast Transport（RMT）プロトコルを完全に指定するために必要な定義の一部が含まれています。
This document obsoletes [RFC3926], which contained a previous version of this specification and was published in the "Experimental" category. This Proposed Standard specification is thus based on [RFC3926] and has been updated according to accumulated experience and growing protocol maturity since the publication of [RFC3926]. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
このドキュメントは廃止されました[RFC3926]。この仕様の以前のバージョンが含まれ、「実験的」カテゴリで公開されました。したがって、この提案された標準仕様は[RFC3926]に基づいており、[RFC3926]の公開以降、蓄積された経験とプロトコルの成熟度の高まりに従って更新されています。この経験は、この仕様自体と、この仕様の使用に関連する輻輳制御戦略の両方に適用されます。
The differences between [RFC3926] and this document are listed in Section 11.
[RFC3926]とこのドキュメントの違いは、セクション11に記載されています。
This document updates ALC [RFC5775] and Layered Coding Transport (LCT) [RFC5651] in the sense that it defines two new header extensions, EXT_FDT and EXT_CENC.
このドキュメントは、2つの新しいヘッダー拡張EXT_FDTとEXT_CENCを定義するという意味で、ALC [RFC5775]とLayered Coding Transport（LCT）[RFC5651]を更新します。
FLUTE is applicable to the delivery of large and small files to many hosts, using delivery sessions of several seconds or more. For instance, FLUTE could be used for the delivery of large software updates to many hosts simultaneously. It could also be used for continuous, but segmented, data such as time-lined text for subtitling -- potentially leveraging its layering inheritance from ALC and LCT to scale the richness of the session to the congestion status of the network. It is also suitable for the basic transport of metadata, for example, Session Description Protocol (SDP) [RFC4566] files that enable user applications to access multimedia sessions.
FLUTEは、数秒以上の配信セッションを使用して、多数のホストへの大小のファイルの配信に適用できます。たとえば、FLUTEを使用すると、大規模なソフトウェアアップデートを多数のホストに同時に配信できます。また、字幕のタイムライン付きテキストなど、継続的ではあるがセグメント化されたデータにも使用できます。ALCおよびLCTからの階層化の継承を利用して、セッションの豊富さをネットワークの輻輳ステータスにスケーリングする可能性があります。また、ユーザーアプリケーションがマルチメディアセッションにアクセスできるようにするセッション記述プロトコル（SDP）[RFC4566]ファイルなど、メタデータの基本的な転送にも適しています。
Massive scalability is a primary design goal for FLUTE. IP multicast is inherently massively scalable, but the best-effort service that it provides does not provide session management functionality, congestion control, or reliability. FLUTE provides all of this by using ALC and IP multicast without sacrificing any of the inherent scalability of IP multicast.
大規模なスケーラビリティは、FLUTEの主要な設計目標です。 IPマルチキャストは本質的に非常にスケーラブルですが、提供するベストエフォートサービスは、セッション管理機能、輻輳制御、または信頼性を提供しません。 FLUTEは、IPマルチキャストの固有のスケーラビリティを犠牲にすることなく、ALCおよびIPマルチキャストを使用してこれらすべてを提供します。
All of the environmental requirements and considerations that apply to the RMT building blocks used by FLUTE shall also apply to FLUTE. These are the ALC protocol instantiation [RFC5775], the LCT building block [RFC5651], and the FEC building block [RFC5052].
FLUTEで使用されるRMTビルディングブロックに適用されるすべての環境要件と考慮事項は、FLUTEにも適用されるものとします。これらは、ALCプロトコルのインスタンス化[RFC5775]、LCT構築ブロック[RFC5651]、およびFEC構築ブロック[RFC5052]です。
FLUTE can be used with both multicast and unicast delivery, but its primary application is for unidirectional multicast file delivery. FLUTE requires connectivity between a sender and receivers but does not require connectivity from receivers to a sender. Because of its low expectations, FLUTE works with most types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks.
FLUTEは、マルチキャスト配信とユニキャスト配信の両方で使用できますが、その主な用途は、単方向マルチキャストファイル配信です。 FLUTEは、送信側と受信側の間の接続を必要としますが、受信側から送信側への接続を必要としません。 FLUTEは期待が低いため、LAN、WAN、イントラネット、インターネット、非対称ネットワーク、ワイヤレスネットワーク、衛星ネットワークなど、ほとんどのタイプのネットワークで動作します。
FLUTE is compatible with both IPv4 and IPv6, as no part of the packet is IP version specific. FLUTE works with both multicast models: Any-Source Multicast (ASM) [RFC1112] and Source-Specific Multicast (SSM) [PAPER.SSM].
パケットのどの部分もIPバージョン固有ではないため、FLUTEはIPv4とIPv6の両方と互換性があります。 FLUTEは、Any-Source Multicast（ASM）[RFC1112]とSource-Specific Multicast（SSM）[PAPER.SSM]の両方のマルチキャストモデルで機能します。
FLUTE is applicable for both shared networks, such as the Internet, with a suitable congestion control building block; and provisioned/ controlled networks, such as wireless broadcast radio systems, with a traffic-shaping building block.
FLUTEは、適切な輻輳制御ビルディングブロックを備えた、インターネットなどの両方の共有ネットワークに適用できます。トラフィックシェーピングビルディングブロックを備えた、ワイヤレスブロードキャストラジオシステムなどのプロビジョニング/制御されたネットワーク。
FLUTE congestion control protocols depend on the ability of a receiver to change multicast subscriptions between multicast groups supporting different rates and/or layered codings. If the network does not support this, then the FLUTE congestion control protocols may not be amenable to such a network.
FLUTE輻輳制御プロトコルは、異なるレートやレイヤードコーディングをサポートするマルチキャストグループ間でマルチキャストサブスクリプションを変更するレシーバーの機能に依存します。ネットワークがこれをサポートしていない場合、FLUTE輻輳制御プロトコルはそのようなネットワークに対応できない可能性があります。
FLUTE can also be used for point-to-point (unicast) communications. At a minimum, implementations of ALC MUST support the Wave and Equation Based Rate Control (WEBRC) [RFC3738] multiple-rate congestion control scheme [RFC5775]. However, since WEBRC has been designed for massively scalable multicast flows, it is not clear how appropriate it is to the particular case of unicast flows. Using a separate point-to-point congestion control scheme is another alternative. How to do that is outside the scope of the present document.
FLUTEは、ポイントツーポイント（ユニキャスト）通信にも使用できます。少なくとも、ALCの実装は、Wave and Equation Based Rate Control（WEBRC）[RFC3738]マルチレート輻輳制御方式[RFC5775]をサポートする必要があります。ただし、WEBRCは非常にスケーラブルなマルチキャストフロー用に設計されているため、ユニキャストフローの特定のケースにどれほど適切であるかは明らかではありません。別のポイントツーポイント輻輳制御方式を使用することは、もう1つの代替手段です。これを行う方法は、このドキュメントの範囲外です。
FLUTE provides reliability using the FEC building block. This will reduce the error rate as seen by applications. However, FLUTE does not provide a method for senders to verify the reception success of receivers, and the specification of such a method is outside the scope of this document.
FLUTEはFECビルディングブロックを使用して信頼性を提供します。これにより、アプリケーションで見られるエラー率が減少します。ただし、FLUTEは送信者が受信者の受信成功を確認する方法を提供していません。そのような方法の仕様はこのドキュメントの範囲外です。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The terms "object" and "transmission object" are consistent with the definitions in ALC [RFC5775] and LCT [RFC5651]. The terms "file" and "source object" are pseudonyms for "object".
「オブジェクト」および「伝送オブジェクト」という用語は、ALC [RFC5775]およびLCT [RFC5651]の定義と一致しています。 「ファイル」および「ソースオブジェクト」という用語は、「オブジェクト」の仮名です。
Asynchronous Layered Coding [RFC5775] is a protocol designed for delivery of arbitrary binary objects. It is especially suitable for massively scalable, unidirectional multicast distribution. ALC provides the basic transport for FLUTE, and thus FLUTE inherits the requirements of ALC.
非同期レイヤードコーディング[RFC5775]は、任意のバイナリオブジェクトの配信用に設計されたプロトコルです。これは、非常にスケーラブルな単方向マルチキャスト配信に特に適しています。 ALCはFLUTEの基本的なトランスポートを提供するため、FLUTEはALCの要件を継承します。
This specification is designed for the delivery of files. The core of this specification is to define how the properties of the files are carried in-band together with the delivered files.
この仕様は、ファイルの配信用に設計されています。この仕様の中核は、ファイルのプロパティが配信されたファイルと一緒にインバンドでどのように運ばれるかを定義することです。
As an example, let us consider a 5200-byte file referred to by "http://www.example.com/docs/file.txt". Using the example, the following properties describe the properties that need to be conveyed by the file delivery protocol.
例として、「http://www.example.com/docs/file.txt」によって参照される5200バイトのファイルを考えてみましょう。例を使用して、次のプロパティは、ファイル配信プロトコルによって伝達される必要があるプロパティを説明します。
* Identifier of the file, expressed as a URI [RFC3986]. The identifier MAY provide a location for the file. In the above example: "http://www.example.com/docs/file.txt".
* URIとして表現されるファイルの識別子[RFC3986]。識別子は、ファイルの場所を提供する場合があります。上記の例では、「http://www.example.com/docs/file.txt」です。
* File name (usually, this can be concluded from the URI). In the above example: "file.txt".
* ファイル名（通常、これはURIから結論付けることができます）。上記の例では、「file.txt」です。
* File type, expressed as Internet Media Types (often referred to as "Media Types"). In the above example: "text/plain".
* インターネットメディアタイプとして表現されるファイルタイプ（多くの場合、「メディアタイプ」と呼ばれます）。上記の例では、「text / plain」です。
* File size, expressed in octets. In the above example: "5200". If the file is content encoded, then this is the file size before content encoding.
* オクテットで表したファイルサイズ。上記の例では、「5200」です。ファイルがコンテンツエンコードされている場合、これはコンテンツエンコード前のファイルサイズです。
* Content encoding of the file, within transport. In the above example, the file could be encoded using ZLIB [RFC1950]. In this case, the size of the transmission object carrying the file would probably differ from the file size. The transmission object size is delivered to receivers as part of the FLUTE protocol.
* トランスポート内のファイルのコンテンツエンコーディング。上記の例では、ZLIB [RFC1950]を使用してファイルをエンコードできます。この場合、ファイルを伝送する送信オブジェクトのサイズは、おそらくファイルサイズとは異なります。送信オブジェクトサイズは、FLUTEプロトコルの一部として受信側に配信されます。
* Security properties of the file, such as digital signatures, message digests, etc. For example, one could use S/MIME [RFC5751] as the content encoding type for files with this authentication wrapper, and one could use XML Digital Signatures (XML-DSIG) [RFC3275] to digitally sign the file. XML-DSIG can also be used to provide tamper prevention, e.g., in the Content-Location field. Content encoding is applied to file data before FEC protection.
* ファイルのセキュリティプロパティ（デジタル署名、メッセージダイジェストなど）。たとえば、この認証ラッパーを持つファイルのコンテンツエンコーディングタイプとしてS / MIME [RFC5751]を使用し、XMLデジタル署名（XML- DSIG）[RFC3275]でファイルにデジタル署名します。 XML-DSIGは、たとえばContent-Locationフィールドなどの改ざん防止にも使用できます。コンテンツのエンコードは、FEC保護の前にファイルデータに適用されます。
For each unique file, FLUTE encodes the attributes listed above and other attributes as children of an XML file element. A table of XML file elements is transmitted as a special file called a 'File Delivery Table' (FDT), which is further described in the next subsection and in Section 3.2.
FLUTEは一意のファイルごとに、上記の属性とその他の属性をXMLファイル要素の子としてエンコードします。 XMLファイル要素のテーブルは、「ファイル配信テーブル」（FDT）と呼ばれる特別なファイルとして送信されます。これについては、次のサブセクションとセクション3.2で詳しく説明します。
ALC is a protocol instantiation of the Layered Coding Transport (LCT) building block [RFC5651]. Thus, ALC inherits the session concept of LCT. In this document, we will use the concept of the ALC/LCT session to collectively denote the interchangeable terms "ALC session" and "LCT session".
ALCは、レイヤードコーディングトランスポート（LCT）ビルディングブロック[RFC5651]のプロトコルのインスタンス化です。したがって、ALCはLCTのセッション概念を継承します。このドキュメントでは、ALC / LCTセッションの概念を使用して、交換可能な用語「ALCセッション」と「LCTセッション」をまとめて表します。
An ALC/LCT session consists of a set of logically grouped ALC/LCT channels associated with a single sender sending ALC/LCT packets for one or more objects. An ALC/LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel.
ALC / LCTセッションは、1つ以上のオブジェクトのALC / LCTパケットを送信する単一の送信者に関連付けられた、論理的にグループ化されたALC / LCTチャネルのセットで構成されます。 ALC / LCTチャネルは、送信者と送信者がチャネルに関連付けたアドレスの組み合わせによって定義されます。レシーバーはチャネルに参加して、センダーによってチャネルに送信されたデータパケットの受信を開始し、レシーバーはチャネルを離れて、チャネルからのデータパケットの受信を停止します。
One of the fields carried in the ALC/LCT header is the Transport Session Identifier (TSI), an integer carried in a field of size 16, 32, or 48 bits (note that the TSI may be carried by other means, in which case it is absent from the LCT header [RFC5651]). The (source IP address, TSI) pair uniquely identifies a session. Note that the TSI is scoped by the IP address, so the same TSI may be used by several source IP addresses at once. Thus, the receiver uses the (source IP address, TSI) pair from each packet to uniquely identify the session sending each packet. When a session carries multiple objects, the Transmission Object Identifier (TOI) field within the ALC/LCT header names the object used to generate each packet. Note that each object is associated with a unique TOI within the scope of a session.
ALC / LCTヘッダーで運ばれるフィールドの1つは、Transport Session Identifier（TSI）です。これは、サイズが16、32、または48ビットのフィールドで運ばれる整数です（TSIは他の手段で運ばれる場合があります。その場合、 LCTヘッダーにはありません[RFC5651]）。 （ソースIPアドレス、TSI）ペアは、セッションを一意に識別します。 TSIのスコープはIPアドレスであるため、同じTSIが複数の送信元IPアドレスで同時に使用される可能性があることに注意してください。したがって、受信者は各パケットの（送信元IPアドレス、TSI）ペアを使用して、各パケットを送信するセッションを一意に識別します。セッションが複数のオブジェクトを伝送する場合、ALC / LCTヘッダー内の伝送オブジェクト識別子（TOI）フィールドは、各パケットの生成に使用されるオブジェクトを指定します。各オブジェクトは、セッションのスコープ内で一意のTOIに関連付けられていることに注意してください。
A FLUTE session consistent with this specification MUST use FLUTE version 2 as specified in this document. Thus, all sessions consistent with this specification MUST set the FLUTE version to 2. The FLUTE version is carried within the EXT_FDT Header Extension (defined in Section 3.4.1) in the ALC/LCT layer. A FLUTE session consistent with this specification MUST use ALC version 1 as specified in [RFC5775], and LCT version 1 as specified in [RFC5651].
この仕様に一致するFLUTEセッションでは、このドキュメントで指定されているFLUTEバージョン2を使用する必要があります。したがって、この仕様に準拠するすべてのセッションでは、FLUTEバージョンを2に設定する必要があります。FLUTEバージョンは、ALC / LCTレイヤーのEXT_FDTヘッダー拡張（セクション3.4.1で定義）内で伝送されます。この仕様に一致するFLUTEセッションでは、[RFC5775]で指定されているALCバージョン1と、[RFC5651]で指定されているLCTバージョン1を使用する必要があります。
If multiple FLUTE sessions are sent to a channel, then receivers MUST determine the FLUTE protocol version, based on version fields and the (source IP address, TSI) pair carried in the ALC/LCT header of the packet. Note that when a receiver first begins receiving packets, it might not know the FLUTE protocol version, as not every LCT packet carries the EXT_FDT header (containing the FLUTE protocol version). A new receiver MAY keep an open binding in the LCT protocol layer between the TSI and the FLUTE protocol version, until the EXT_FDT header arrives. Alternatively, a new receiver MAY discover a binding between TSI and FLUTE protocol version via a session discovery protocol that is out of scope of this document.
複数のFLUTEセッションがチャネルに送信される場合、受信者はバージョンフィールドとパケットのALC / LCTヘッダーで運ばれる（送信元IPアドレス、TSI）ペアに基づいて、FLUTEプロトコルバージョンを決定する必要があります。すべてのLCTパケットがEXT_FDTヘッダー（FLUTEプロトコルバージョンを含む）を運ぶわけではないため、受信者が最初にパケットの受信を開始するとき、FLUTEプロトコルバージョンを認識していない可能性があることに注意してください。新しいレシーバーは、EXT_FDTヘッダーが到着するまで、TSIとFLUTEプロトコルバージョンの間のLCTプロトコルレイヤーでオープンバインディングを保持する場合があります。あるいは、新しいレシーバーは、このドキュメントの範囲外であるセッション検出プロトコルを介して、TSIとFLUTEプロトコルバージョン間のバインディングを検出する場合があります。
If the sender's IP address is not accessible to receivers, then packets that can be received by receivers contain an intermediate IP address. In this case, the TSI is scoped by this intermediate IP address of the sender for the duration of the session. As an example, the sender may be behind a Network Address Translation (NAT) device that temporarily assigns an IP address for the sender. In this case, the TSI is scoped by the intermediate IP address assigned by the NAT. As another example, the sender may send its original packets using IPv6, but some portions of the network may not be IPv6 capable. Thus, there may be an IPv6-to-IPv4 translator that changes the IP address of the packets to a different IPv4 address. In this case, receivers in the IPv4 portion of the network will receive packets containing the IPv4 address, and thus the TSI for them is scoped by the IPv4 address. How the IP address of the sender to be used to scope the session by receivers is delivered to receivers, whether it is the sender's IP address or an intermediate IP address, is outside the scope of this document.
送信者のIPアドレスが受信者にアクセスできない場合、受信者が受信できるパケットには中間IPアドレスが含まれます。この場合、TSIは、セッションの期間中、送信者のこの中間IPアドレスによってスコープされます。例として、送信者は、送信者のIPアドレスを一時的に割り当てるネットワークアドレス変換（NAT）デバイスの背後にいる可能性があります。この場合、TSIのスコープは、NATによって割り当てられた中間IPアドレスです。別の例として、送信者はIPv6を使用して元のパケットを送信できますが、ネットワークの一部はIPv6に対応していない場合があります。したがって、パケットのIPアドレスを別のIPv4アドレスに変更するIPv6-to-IPv4トランスレータが存在する可能性があります。この場合、ネットワークのIPv4部分のレシーバーはIPv4アドレスを含むパケットを受信するため、それらのTSIはIPv4アドレスによってスコープされます。受信者がセッションをスコープするために使用する送信者のIPアドレスが、送信者のIPアドレスであるか中間IPアドレスであるかにかかわらず、受信者に配信される方法は、このドキュメントの範囲外です。
When FLUTE is used for file delivery over ALC, the ALC/LCT session is called a file delivery session, and the ALC/LCT concept of 'object' denotes either a 'file' or a 'File Delivery Table Instance' (Section 3.2).
ALCを介したファイル配信にFLUTEを使用する場合、ALC / LCTセッションはファイル配信セッションと呼ばれ、ALC / LCTの「オブジェクト」の概念は「ファイル」または「ファイル配信テーブルインスタンス」を示します（セクション3.2） 。
Additionally, the following rules apply:
さらに、次のルールが適用されます。
* The TOI field MUST be included in ALC packets sent within a FLUTE session, with the exception that ALC packets sent in a FLUTE session with the Close Session (A) flag set to 1 (signaling the end of the session) and that contain no payload (carrying no information for any file or FDT) SHALL NOT carry the TOI. See Section 5.1 of [RFC5651] for the LCT definition of the Close Session flag, and see Section 4.2 of [RFC5775] for an example of the use of a TOI within an ALC packet.
* TOIフィールドは、FLUTEセッション内で送信されるALCパケットに含まれている必要があります。ただし、ALSパケットがFLUTEセッションで送信され、Close Session（A）フラグが1に設定され（セッションの終了を通知）、ペイロードが含まれていない場合は例外です。 （ファイルやFDTの情報を一切持ちません）TOIを持ちません。セッション終了フラグのLCT定義については、[RFC5651]のセクション5.1を参照してください。ALCパケット内でのTOIの使用例については、[RFC5775]のセクション4.2を参照してください。
* The TOI value '0' is reserved for the delivery of File Delivery Table Instances. Each non-expired File Delivery Table Instance is uniquely identified by an FDT Instance ID within the EXT_FDT header defined in Section 3.4.1.
* TOI値「0」は、ファイル配信テーブルインスタンスの配信用に予約されています。有効期限が切れていない各ファイル配信テーブルインスタンスは、セクション3.4.1で定義されているEXT_FDTヘッダー内のFDTインスタンスIDによって一意に識別されます。
* Each file in a file delivery session MUST be associated with a TOI (>0) in the scope of that session.
* ファイル配信セッションの各ファイルは、そのセッションのスコープ内のTOI（> 0）に関連付けられている必要があります。
* Information carried in the headers and the payload of a packet is scoped by the source IP address and the TSI. Information particular to the object carried in the headers and the payload of a packet is further scoped by the TOI for file objects, and is further scoped by both the TOI and the FDT Instance ID for FDT Instance objects.
* ヘッダーとパケットのペイロードで運ばれる情報は、送信元IPアドレスとTSIによってスコープされます。ヘッダーで運ばれるオブジェクトとパケットのペイロードに固有の情報は、ファイルオブジェクトのTOIによってさらにスコープされ、FDTインスタンスオブジェクトのTOIとFDTインスタンスIDの両方によってさらにスコープされます。
The File Delivery Table (FDT) provides a means to describe various attributes associated with files that are to be delivered within the file delivery session. The following lists are examples of such attributes and are not intended to be mutually exclusive or exhaustive.
ファイル配信テーブル（FDT）は、ファイル配信セッション内で配信されるファイルに関連するさまざまな属性を記述する手段を提供します。以下のリストはそのような属性の例であり、相互に排他的または完全であることを意図したものではありません。
Attributes related to the delivery of a file:
ファイルの配信に関連する属性：
- TOI value that represents the file
- ファイルを表すTOI値
- FEC Object Transmission Information (including the FEC Encoding ID and, if relevant, the FEC Instance ID)
- FECオブジェクト送信情報（FECエンコーディングID、および関連する場合はFECインスタンスIDを含む）
- Size of the transmission object carrying the file
- ファイルを運ぶ送信オブジェクトのサイズ
- Aggregate rate of sending packets to all channels
- すべてのチャネルにパケットを送信する総レート
Attributes related to the file itself:
ファイル自体に関連する属性：
- Name, Identification, and Location of file (specified by the URI)
- ファイルの名前、識別、および場所（URIで指定）
- Media type of file
- ファイルのメディアタイプ
- Size of file
- ファイルのサイズ
- Encoding of file
- ファイルのエンコーディング
- Message digest of file
- ファイルのメッセージダイジェスト
Some of these attributes MUST be included in the file description entry for a file; others are optional, as defined in Section 3.4.2.
これらの属性のいくつかは、ファイルのファイル記述エントリに含まれている必要があります。セクション3.4.2で定義されているように、その他はオプションです。
Logically, the FDT is a set of file description entries for files to be delivered in the session. Each file description entry MUST include the TOI for the file that it describes and the URI identifying the file. The TOI carried in each file description entry is how FLUTE names the ALC/LCT data packets used for delivery of the file. Each file description entry may also contain one or more descriptors that map the above-mentioned attributes to the file.
論理的には、FDTは、セッションで配信されるファイルのファイル記述エントリのセットです。各ファイル記述エントリには、それが記述するファイルのTOIおよびファイルを識別するURIを含める必要があります。各ファイル記述エントリに含まれるTOIは、ファイルの配信に使用されるALC / LCTデータパケットをFLUTEがどのように命名するかです。各ファイル記述エントリには、前述の属性をファイルにマップする1つ以上の記述子も含まれます。
Each file delivery session MUST have an FDT that is local to the given session. The FDT MUST provide a file description entry mapped to a TOI for each file appearing within the session. An object that is delivered within the ALC session, but not described in the FDT, other than the FDT itself, is not considered a 'file' belonging to the file delivery session. This object received with an unmapped TOI (non-zero TOI that is not resolved by the FDT) SHOULD in general be ignored by a FLUTE receiver. The details of how to do that are out of scope of this specification.
各ファイル配信セッションには、特定のセッションに対してローカルなFDTが必要です。 FDTは、セッション内に表示される各ファイルのTOIにマップされたファイル記述エントリを提供する必要があります。 ALCセッション内で配信され、FDT以外でFDTに記述されていないオブジェクトは、ファイル配信セッションに属する「ファイル」とは見なされません。マップされていないTOI（FDTによって解決されないゼロ以外のTOI）で受信されたこのオブジェクトは、一般にFLUTEレシーバーによって無視される必要があります。それを行う方法の詳細は、この仕様の範囲外です。
Note that a client that joins an active file delivery session MAY receive data packets for a TOI > 0 before receiving any FDT Instance (see Section 3.3 for recommendations on how to limit the probability that this situation will occur). Even if the TOI is not mapped to any file description entry, this is hopefully a transient situation. When this happens, system performance might be improved by caching such packets within a reasonable time window and storage size. Such optimizations are use-case and implementation specific, and further details are beyond the scope of this document.
アクティブなファイル配信セッションに参加するクライアントは、FDTインスタンスを受信する前に、TOI> 0のデータパケットを受信する場合があります（この状況が発生する可能性を制限する方法に関する推奨事項については、セクション3.3を参照してください）。 TOIがファイル記述エントリにマップされていない場合でも、これは一時的な状況である可能性があります。これが発生した場合、そのようなパケットを妥当な時間枠とストレージサイズ内でキャッシュすることにより、システムパフォーマンスが向上する可能性があります。このような最適化はユースケースと実装に固有であり、詳細はこのドキュメントの範囲を超えています。
Within the file delivery session, the FDT is delivered as FDT Instances. An FDT Instance contains one or more file description entries of the FDT. Any FDT Instance can be equal to, be a subset of, be a superset of, overlap with, or complement any other FDT Instance. A certain FDT Instance may be repeated multiple times during a session, even after subsequent FDT Instances (with higher FDT Instance ID numbers) have been transmitted. Each FDT Instance contains at least a single file description entry and at most the exhaustive set of file description entries of the files being delivered in the file delivery session.
ファイル配信セッション内で、FDTはFDTインスタンスとして配信されます。 FDTインスタンスには、FDTの1つ以上のファイル記述エントリが含まれています。すべてのFDTインスタンスは、他のFDTインスタンスと同等、そのサブセット、スーパーセット、オーバーラップ、または補完することができます。特定のFDTインスタンスは、後続のFDTインスタンス（より高いFDTインスタンスID番号を持つ）が送信された後でも、セッション中に複数回繰り返される場合があります。各FDTインスタンスには、ファイル配信セッションで配信されるファイルの少なくとも1つのファイル記述エントリと、多くても完全なファイル記述エントリのセットが含まれています。
A receiver of the file delivery session keeps an FDT database for received file description entries. The receiver maintains the database, for example, upon reception of FDT Instances. Thus, at any given time the contents of the FDT database represent the receiver's current view of the FDT of the file delivery session. Since each receiver behaves independently of other receivers, it SHOULD NOT be assumed that the contents of the FDT database are the same for all the receivers of a given file delivery session.
ファイル配信セッションの受信者は、受信したファイル記述エントリのFDTデータベースを保持します。受信者は、たとえばFDTインスタンスの受信時にデータベースを維持します。したがって、FDTデータベースのコンテンツは常に、ファイル配信セッションのFDTに関する受信者の現在のビューを表します。各レシーバーは他のレシーバーとは独立して動作するため、FDTデータベースの内容が、特定のファイル配信セッションのすべてのレシーバーで同じであるとは想定されません。
Since the FDT database is an abstract concept, the structure and the maintenance of the FDT database are left to individual implementations and are thus out of scope of this specification.
FDTデータベースは抽象的な概念であるため、FDTデータベースの構造と保守は個々の実装に任されているため、この仕様の範囲外です。
The following rules define the dynamics of the FDT Instances within a file delivery session:
次のルールは、ファイル配信セッション内のFDTインスタンスのダイナミクスを定義します。
* For every file delivered within a file delivery session, there MUST be a file description entry included in at least one FDT Instance sent within the session. A file description entry contains at a minimum the mapping between the TOI and the URI.
* ファイル配信セッション内で配信されるすべてのファイルについて、セッション内で送信される少なくとも1つのFDTインスタンスにファイル記述エントリが含まれている必要があります。ファイル記述エントリには、少なくともTOIとURIの間のマッピングが含まれています。
* An FDT Instance MAY appear in any part of the file delivery session, and packets for an FDT Instance MAY be interleaved with packets for other files or other FDT Instances within a session.
* FDTインスタンスは、ファイル配信セッションの任意の部分に表示される場合があり、FDTインスタンスのパケットは、セッション内の他のファイルまたは他のFDTインスタンスのパケットとインターリーブされる場合があります。
* The TOI value of '0' MUST be reserved for delivery of FDT Instances. The use of other TOI values (i.e., an integer > 0) for FDT Instances is outside the scope of this specification.
* TOI値「0」は、FDTインスタンスの配信用に予約する必要があります。 FDTインスタンスに他のTOI値（つまり、整数> 0）を使用することは、この仕様の範囲外です。
* The FDT Instance is identified by the use of a new fixed-length LCT Header Extension, EXT_FDT (defined later in this section). Each non-expired FDT Instance is uniquely identified within the file delivery session by its FDT Instance ID, carried by the EXT_FDT Header Extension. Any ALC/LCT packet carrying an FDT Instance MUST include EXT_FDT.
* FDTインスタンスは、新しい固定長LCTヘッダー拡張、EXT_FDT（このセクションの後半で定義）を使用して識別されます。有効期限が切れていない各FDTインスタンスは、ファイル配信セッション内で、EXT_FDTヘッダー拡張によって伝送されるFDTインスタンスIDによって一意に識別されます。 FDTインスタンスを伝送するALC / LCTパケットには、EXT_FDTを含める必要があります。
* It is RECOMMENDED that an FDT Instance that contains the file description entry for a file be sent at least once before sending the described file within a file delivery session. This recommendation is intended to minimize the amount of file data that may be received by receivers in advance of the FDT Instance containing the entry for a file (such data must either be speculatively buffered or discarded). Note that this possibility cannot be completely eliminated, since the first transmission of FDT data might be lost.
* ファイル配信セッション内で記述されたファイルを送信する前に、ファイルのファイル記述エントリを含むFDTインスタンスを少なくとも1回送信することをお勧めします。この推奨事項は、ファイルのエントリを含むFDTインスタンスの前に受信者が受信する可能性のあるファイルデータの量を最小限に抑えることを目的としています（このようなデータは、投機的にバッファリングするか破棄する必要があります）。 FDTデータの最初の送信が失われる可能性があるため、この可能性を完全に排除することはできません。
* Within a file delivery session, any TOI > 0 MAY be described more than once. For example, a previous FDT Instance 0 describes a TOI of value '3'. Now, subsequent FDT Instances can either keep TOI '3' unmodified in the table, not include it, or augment the description. However, subsequent FDT Instances MUST NOT change the parameters already described for a specific TOI.
* ファイル配信セッション内で、TOI> 0は2回以上記述される場合があります。たとえば、前のFDTインスタンス0は、値「3」のTOIを記述しています。これで、後続のFDTインスタンスは、TOI '3'を変更せずにテーブルに保持するか、それを含めないか、説明を追加できます。ただし、後続のFDTインスタンスは、特定のTOIについてすでに説明されているパラメーターを変更してはなりません（MUST NOT）。
* An FDT Instance is valid until its expiration time. The expiration time is expressed within the FDT Instance payload as a UTF-8 decimal representation of a 32-bit unsigned integer. The value of this integer represents the 32 most significant bits of a 64-bit Network Time Protocol (NTP) [RFC5905] time value. These 32 bits provide an unsigned integer representing the time in seconds relative to 0 hours 1 January 1900 in the case of the prime epoch (era 0) [RFC5905]. The handling of time wraparound (to happen in 2036) requires that the associated epoch be considered. In any case, both a sender and a receiver easily determine to which (136-year) epoch the FDT Instance expiration time value pertains by choosing the epoch for which the expiration time is closest in time to the current time.
* FDTインスタンスは、有効期限まで有効です。有効期限は、FDTインスタンスのペイロード内で、32ビットの符号なし整数のUTF-8 10進表記として表されます。この整数の値は、64ビットのネットワークタイムプロトコル（NTP）[RFC5905]時間値の上位32ビットを表します。これらの32ビットは、プライムエポック（時代0）[RFC5905]の場合、1900年1月1日の0時間を基準とした秒単位の時間を表す符号なし整数を提供します。 （2036年に発生する）時間の折り返しの処理では、関連するエポックを考慮する必要があります。いずれの場合も、送信者と受信者はどちらも、有効期限が現在の時刻に最も近いエポックを選択することにより、FDTインスタンスの有効期限の値が関係する（136年）エポックを簡単に判断できます。
Here is an example. Let us imagine that a new FLUTE session is started on February 7th, 2036, 0h, i.e., at NTP time 4,294,944,000, a few hours before the end of epoch 0. In order to define an FDT Instance valid for the next 48 hours, The FLUTE sender sets an expiry time of 149,504. This FDT Instance will expire exactly on February 9th, 2036, 0h. A client that receives this FDT Instance on the 7th, 0h, just after it has been sent, immediately understands that this value corresponds to epoch 1. A client that joins the session on February 8th, 0h, i.e., at NTP time 63,104, epoch 1, immediately understands that the 149,504 NTP timestamp corresponds to epoch 1.
例を示します。新しいFLUTEセッションが2036年2月7日0hに、つまりエポック0の終了の数時間前のNTP時間4,294,944,000に開始されたとします。次の48時間有効なFDTインスタンスを定義するために、 FLUTE送信側は、149,504の有効期限を設定します。このFDTインスタンスは、2036年2月9日0時間に期限が切れます。このFDTインスタンスを送信された直後の7日0hに受信したクライアントは、この値がエポック1に対応することをすぐに理解します。2月8日0hにセッションに参加するクライアント、つまりNTP時間63,104、エポック1は、149,504のNTPタイムスタンプがエポック1に対応していることをすぐに理解します。
* The space of FDT Instance IDs is limited by the associated field size (i.e., 20 bits) in the EXT_FDT Header Extension (Section 3.4.1). Therefore, senders should take care to always have a large enough supply of available FDT Instance IDs when specifying FDT expiration times.
* FDTインスタンスIDのスペースは、EXT_FDTヘッダー拡張（セクション3.4.1）の関連フィールドサイズ（つまり、20ビット）によって制限されます。したがって、FDTの有効期限を指定する場合、送信者は常に十分な量の利用可能なFDTインスタンスIDを用意するように注意する必要があります。
* The receiver MUST NOT use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance.
* 受信者は、FDTインスタンスの有効期限を超えて受信したパケットを解釈するために、受信したFDTインスタンスを使用してはなりません（MUST NOT）。
* A sender MUST use an expiration time in the future upon creation of an FDT Instance relative to its Sender Current Time (SCT).
* 送信者は、送信者の現在時刻（SCT）に関連するFDTインスタンスの作成時に、将来の有効期限を使用する必要があります。
* Any FEC Encoding ID MAY be used for the sending of FDT Instances. The default is to use the Compact No-Code FEC Encoding ID 0 [RFC5445] for the sending of FDT Instances. (Note that since FEC Encoding ID 0 is the default for FLUTE, this implies that Source Block Number and Encoding Symbol ID lengths both default to 16 bits each.)
* FECエンコードIDは、FDTインスタンスの送信に使用できます。デフォルトでは、FDTインスタンスの送信にCompact No-Code FECエンコーディングID 0 [RFC5445]を使用します。 （FECエンコーディングID 0がFLUTEのデフォルトであるため、これは、ソースブロック番号とエンコーディングシンボルIDの長さが両方ともデフォルトでそれぞれ16ビットであることを意味します。）
* If the receiver does not support the FEC Scheme indicated by the FEC Encoding ID, the receiver MUST NOT decode the associated FDT.
* レシーバーがFECエンコーディングIDで示されるFECスキームをサポートしない場合、レシーバーは関連するFDTをデコードしてはなりません（MUST NOT）。
* It is RECOMMENDED that the mechanisms used for file attribute delivery SHOULD achieve a delivery probability that is higher than the file recovery probability and the file attributes SHOULD be delivered at this higher priority before the delivery of the associated files begins.
* ファイル属性の配信に使用されるメカニズムは、ファイル回復確率よりも高い配信確率を達成する必要があり（SHOULD）、関連するファイルの配信が始まる前に、ファイル属性をこのより高い優先度で配信する必要があります（SHOULD）。
Generally, a receiver needs to receive an FDT Instance describing a file before it is able to recover the file itself. In this sense, FDT Instances are of higher priority than files. Additionally, a FLUTE sender SHOULD assume that receivers will not receive all packets pertaining to FDT Instances. The way FDT Instances are transmitted has a large impact on satisfying the recommendation above. When there is a single file transmitted in the session, one way to satisfy the recommendation above is to repeatedly transmit on a regular enough basis FDT Instances describing the file while the file is being transmitted. If an FDT Instance is longer than one packet payload in length, it is RECOMMENDED that an FEC code that provides protection against loss be used for delivering this FDT Instance. When there are multiple files in a session concurrently being transmitted to receivers, the way the FDT Instances are structured and transmitted also has a large impact. As an example, a way to satisfy the recommendation above is to transmit an FDT Instance that describes all files currently being transmitted, and to transmit this FDT Instance reliably, using the same techniques as explained for the case when there is a single file transmitted in a session. If instead the concurrently transmitted files are described in separate FDT Instances, another way to satisfy this recommendation is to transmit all the relevant FDT Instances reliably, using the same techniques as explained for the case when there is a single file transmitted in a session.
一般に、受信者は、ファイル自体を回復する前に、ファイルを記述するFDTインスタンスを受信する必要があります。この意味で、FDTインスタンスはファイルよりも優先されます。さらに、FLUTE送信者は、受信者がFDTインスタンスに関連するすべてのパケットを受信しないことを想定する必要があります（SHOULD）。 FDTインスタンスが送信される方法は、上記の推奨を満たすことに大きな影響を与えます。セッションで単一のファイルが送信される場合、上記の推奨を満たす1つの方法は、ファイルが送信されている間、ファイルを記述する十分な規則に基づいてFDTインスタンスを繰り返し送信することです。 FDTインスタンスの長さが1パケットペイロードよりも長い場合、損失に対する保護を提供するFECコードをこのFDTインスタンスの配信に使用することをお勧めします。セッションで複数のファイルが同時にレシーバーに送信される場合、FDTインスタンスが構造化されて送信される方法も大きな影響を及ぼします。例として、上記の推奨を満たす方法は、現在送信されているすべてのファイルを記述するFDTインスタンスを送信し、このFDTインスタンスを確実に送信することです。単一のファイルが送信される場合について説明したのと同じ手法を使用します。セッション。代わりに、同時に送信されるファイルが個別のFDTインスタンスで記述されている場合、この推奨事項を満たす別の方法は、セッションで単一のファイルが送信される場合について説明したのと同じ手法を使用して、関連するすべてのFDTインスタンスを確実に送信することです。
In any case, how often the description of a file is sent in an FDT Instance, how often an FDT Instance is sent, and how much FEC protection is provided for an FDT Instance (if longer than one packet payload) are dependent on the particular application and are outside the scope of this document.
いずれの場合でも、ファイルの説明がFDTインスタンスで送信される頻度、FDTインスタンスが送信される頻度、およびFDTインスタンスに提供されるFEC保護の量（複数のパケットペイロードより長い場合）は、特定のアプリケーションとこのドキュメントの範囲外です。
Sometimes the various attributes associated with files that are to be delivered within the file delivery session are sent out-of-band. The details of how this is done are out of the scope of this document. However, it is still RECOMMENDED that any out-of-band transmission be managed in such a way that a receiver will be able to recover the attributes associated with a file at least as reliably as the receiver is able to receive enough packets containing encoding symbols to recover the file. For example, the probability of a randomly chosen receiver being able to recover a given file can often be estimated based on a statistical model of reception conditions, the amount of data transmitted, and the properties of any Forward Error Correction in use. The recommendation above suggests that mechanisms used for file attribute delivery should achieve a higher delivery probability than the file recovery probability. The sender MAY also continue sending the various file attributes in-band, in addition to the out-of-band transmission.
ファイル配信セッション内で配信されるファイルに関連するさまざまな属性が、帯域外で送信されることがあります。これがどのように行われるかの詳細は、このドキュメントの範囲外です。ただし、帯域外送信は、受信者がファイルに関連付けられた属性を、少なくとも受信者がエンコードシンボルを含む十分なパケットを受信できるのと同じくらい確実に回復できるように管理することをお勧めします。ファイルを回復します。たとえば、ランダムに選択されたレシーバーが特定のファイルを回復できる確率は、受信状態の統計モデル、送信されたデータの量、および使用中の前方誤り訂正のプロパティに基づいて推定されることがよくあります。上記の推奨事項は、ファイル属性の配信に使用されるメカニズムが、ファイルの回復確率よりも高い配信確率を実現することを示唆しています。送信者は、帯域外送信に加えて、さまざまなファイル属性を帯域内で送信し続けることもできます（MAY）。
FDT Instances are carried in ALC packets with TOI = 0 and with an additional REQUIRED LCT Header extension called the FDT Instance Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance ID that uniquely identifies FDT Instances within a file delivery session. Placement of the FDT Instance Header is the same as that of any other LCT Header Extension. There MAY be other LCT Header Extensions in use.
FDTインスタンスは、TOI = 0、およびFDTインスタンスヘッダーと呼ばれる追加の必須LCTヘッダー拡張を備えたALCパケットで伝送されます。 FDTインスタンスヘッダー（EXT_FDT）には、ファイル配信セッション内のFDTインスタンスを一意に識別するFDTインスタンスIDが含まれています。 FDTインスタンスヘッダーの配置は、他のLCTヘッダー拡張の配置と同じです。他のLCTヘッダー拡張が使用されている場合があります。
The FDT Instance is encoded for transmission, like any other object, using an FEC Scheme (which MAY be the Compact No-Code FEC Scheme). The LCT Header Extensions are followed by the FEC Payload ID, and finally the Encoding Symbols for the FDT Instance, which contains one or more file description entries. An FDT Instance MAY span several ALC packets -- the number of ALC packets is a function of the file attributes associated with the FDT Instance. The FDT Instance Header is carried in each ALC packet carrying the FDT Instance. The FDT Instance Header is identical for all ALC/LCT packets for a particular FDT Instance.
FDTインスタンスは、他のオブジェクトと同様に、FECスキーム（コンパクトなNo-Code FECスキームである場合があります）を使用して送信用にエンコードされます。 LCTヘッダー拡張の後にFECペイロードIDが続き、最後にFDTインスタンスのエンコーディングシンボルが続きます。これには、1つ以上のファイル記述エントリが含まれています。 FDTインスタンスは複数のALCパケットにまたがる場合があります-ALCパケットの数はFDTインスタンスに関連付けられたファイル属性の関数です。 FDTインスタンスヘッダーは、FDTインスタンスを伝送する各ALCパケットで伝送されます。 FDTインスタンスヘッダーは、特定のFDTインスタンスのすべてのALC / LCTパケットで同一です。
The overall format of ALC/LCT packets carrying an FDT Instance is depicted in Figure 1 below. All integer fields are carried in "big-endian" or "network order" format (i.e., most significant byte (octet) first). As defined in [RFC5775], all ALC/LCT packets are sent using UDP.
FDTインスタンスを伝送するALC / LCTパケットの全体的なフォーマットを以下の図1に示します。すべての整数フィールドは、「ビッグエンディアン」または「ネットワークオーダー」形式で転送されます（つまり、最上位バイト（オクテット）が最初）。 [RFC5775]で定義されているように、すべてのALC / LCTパケットはUDPを使用して送信されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT Header Extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FLUTE Payload: Encoding Symbol(s)
~ (for FDT Instance in an FDT packet) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Overall FDT Packet
図1：FDTパケット全体
The FDT Instance Header (EXT_FDT) is a new fixed-length, ALC Protocol-Instantiation-specific LCT Header Extension [RFC5651]. The Header Extension Type (HET) for the extension is 192. Its format is defined below:
FDTインスタンスヘッダー（EXT_FDT）は、新しい固定長のALCプロトコル-インスタンス化固有のLCTヘッダー拡張[RFC5651]です。拡張のヘッダー拡張タイプ（HET）は192です。そのフォーマットは次のように定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EXT_FDT Format
図2：EXT_FDTフォーマット
Version of FLUTE (V), 4 bits:
FLUTE（V）のバージョン、4ビット：
This document specifies FLUTE version 2. Hence, in any ALC packet that carries an FDT Instance and that belongs to the file delivery session as specified in this specification MUST set this field to '2'.
このドキュメントではFLUTEバージョン2を指定しています。したがって、FDTインスタンスを伝送し、この仕様で指定されているファイル配信セッションに属するALCパケットでは、このフィールドを「2」に設定する必要があります。
FDT Instance ID, 20 bits:
FDTインスタンスID、20ビット：
For each file delivery session, the numbering of FDT Instances starts from '0' and is incremented by one for each subsequent FDT Instance. After reaching the maximum value (2^20-1), the numbering starts from the smallest FDT Instance ID value assigned to an expired FDT Instance. When wraparound from a greater FDT Instance ID value to a smaller FDT Instance ID value occurs, the smaller FDT Instance ID value is considered logically higher than the greater FDT Instance ID value. Then, the subsequent FDT Instances are assigned the next available smallest FDT Instance ID value, in order to always keep the FDT Instance ID values logically increasing.
ファイル配信セッションごとに、FDTインスタンスの番号は「0」から始まり、後続のFDTインスタンスごとに1ずつ増加します。最大値（2 ^ 20-1）に達した後、有効期限が切れたFDTインスタンスに割り当てられた最小のFDTインスタンスID値から番号付けが始まります。大きいFDTインスタンスID値から小さいFDTインスタンスID値へのラップアラウンドが発生した場合、小さいFDTインスタンスID値は、大きいFDTインスタンスID値よりも論理的に高いと見なされます。次に、FDTインスタンスID値を常に論理的に増加させ続けるために、後続のFDTインスタンスには、次に利用可能な最小のFDTインスタンスID値が割り当てられます。
Senders MUST NOT reuse an FDT Instance ID value that is already in use for a non-expired FDT Instance. Sender behavior when all the FDT Instance IDs are used by non-expired FEC Instances is outside the scope of this specification and left to individual implementations of FLUTE. Receipt of an FDT Instance that reuses an FDT Instance ID value that is currently used by a non-expired FDT Instance MUST be considered an error case. Receiver behavior in this case (e.g., leave the session or ignore the new FDT Instance) is outside the scope of this specification and left to individual implementations of FLUTE. Receivers MUST be ready to handle FDT Instance ID wraparound and situations where missing FDT Instance IDs result in increments larger than one.
送信者は、有効期限が切れていないFDTインスタンスですでに使用されているFDTインスタンスID値を再利用してはなりません（MUST NOT）。すべてのFDTインスタンスIDが期限切れになっていないFECインスタンスによって使用される場合の送信者の動作は、この仕様の範囲外であり、FLUTEの個々の実装に任されています。期限が切れていないFDTインスタンスによって現在使用されているFDTインスタンスID値を再利用するFDTインスタンスの受信は、エラーケースと見なされなければなりません（MUST）。この場合のレシーバーの動作（たとえば、セッションを終了するか、新しいFDTインスタンスを無視する）は、この仕様の範囲外であり、FLUTEの個々の実装に任されています。レシーバーは、FDTインスタンスIDの折り返しと、FDTインスタンスIDがないために1より大きい増分が発生する状況を処理する準備ができている必要があります。
The FDT Instance contains file description entries that provide the mapping functionality described in Section 3.2 above.
FDTインスタンスには、上記のセクション3.2で説明したマッピング機能を提供するファイル記述エントリが含まれています。
The FDT Instance is an Extensible Markup Language (XML) structure that has a single root element "FDT-Instance". The "FDT-Instance" element MUST contain the "Expires" attribute, which provides the expiration time of the FDT Instance. In addition, the "FDT-Instance" element MAY contain the "Complete" attribute, a boolean that can be either set to '1' or 'true' for TRUE, or '0' or 'false' for FALSE. When TRUE, the "Complete" attribute signals that this "FDT Instance" includes the set of "File" entries that exhausts both the set of files delivered so far and the set of files to be delivered in the session. This implies that no new data will be provided in future FDT Instances within this session (i.e., that either FDT Instances with higher ID numbers will not be used or, if they are used, will only provide file parameters identical to those already given in this and previous FDT Instances). The "Complete" attribute is therefore used to provide a complete list of files in an entire FLUTE session (a "complete FDT"). Note that when all the FDT Instances received so far have no "Complete" attribute, the receiver MUST consider that the session is not complete and that new data MAY be provided in future FDT Instances. This is equivalent to receiving FDT Instances having the "Complete" attribute set to FALSE.
FDTインスタンスは、1つのルート要素 "FDT-Instance"を持つExtensible Markup Language（XML）構造です。 「FDT-Instance」要素には、FDTインスタンスの有効期限を提供する「Expires」属性を含める必要があります。さらに、「FDT-Instance」要素には「Complete」属性を含めることができます。これは、TRUEの場合は「1」または「true」、FALSEの場合は「0」または「false」に設定できるブール値です。 TRUEの場合、「完全」属性は、この「FDTインスタンス」に、これまでに配信されたファイルのセットとセッションで配信されるファイルのセットの両方を使い果たす「ファイル」エントリのセットが含まれていることを示します。これは、このセッション内の今後のFDTインスタンスで新しいデータが提供されないことを意味します（つまり、より大きなID番号のFDTインスタンスは使用されないか、使用される場合、これですでに指定されているものと同じファイルパラメーターのみを提供しますおよび以前のFDTインスタンス）。したがって、「完全」属性は、FLUTEセッション全体（「完全FDT」）内のファイルの完全なリストを提供するために使用されます。これまでに受信したすべてのFDTインスタンスに「完了」属性がない場合、受信者はセッションが完了していないこと、および新しいデータが将来のFDTインスタンスで提供される可能性があることを考慮しなければならないことに注意してください。これは、「Complete」属性がFALSEに設定されているFDTインスタンスを受け取ることと同じです。
The "FDT-Instance" element MAY contain attributes that give common parameters for all files of an FDT Instance. These attributes MAY also be provided for individual files in the "File" element. Where the same attribute appears in both the "FDT-Instance" and the "File" elements, the value of the attribute provided in the "File" element takes precedence.
「FDT-Instance」要素には、FDTインスタンスのすべてのファイルに共通のパラメーターを与える属性を含めることができます。これらの属性は、「File」要素の個々のファイルにも提供される場合があります。 「FDT-Instance」要素と「File」要素の両方に同じ属性が出現する場合、「File」要素で提供される属性の値が優先されます。
For each file to be declared in the given FDT Instance, there is a single file description entry in the FDT Instance. Each entry is represented by element "File", which is a child element of the FDT Instance structure.
特定のFDTインスタンスで宣言されるファイルごとに、FDTインスタンスに単一のファイル記述エントリがあります。各エントリは、FDTインスタンス構造の子要素である要素「ファイル」によって表されます。
The attributes of the "File" element in the XML structure represent the attributes given to the file that is delivered in the file delivery session. The value of the XML attribute name corresponds to the MIME field name, and the XML attribute value corresponds to the value of the MIME field body [RFC2045]. Each "File" element MUST contain at least two attributes: "TOI" and "Content-Location". "TOI" MUST be assigned a valid TOI value as described in Section 3.3. "Content-Location" [RFC2616] MUST be assigned a syntactically valid URI, as defined in [RFC3986], which identifies the file to be delivered. For example, it can be a URI with the "http" or "file" URI scheme. Only one "Content-Location" attribute is allowed for each file. The "Content-Location" field MUST be considered a string that identifies a file (i.e., two different strings are two different identifiers). Any use of the "Content-Location" field for anything else other than to identify the object is out of scope of this specification. The semantics for any two "File" elements declaring the same "Content-Location" but differing "TOI" is that the element appearing in the FDT Instance with the greater FDT Instance ID is considered to declare a newer instance (e.g., version) of the same "File".
XML構造の「File」要素の属性は、ファイル配信セッションで配信されるファイルに与えられた属性を表します。 XML属性名の値はMIMEフィールド名に対応し、XML属性値はMIMEフィールド本体[RFC2045]の値に対応します。各「File」要素には、「TOI」と「Content-Location」の少なくとも2つの属性を含める必要があります。 「TOI」には、セクション3.3で説明されているように、有効なTOI値を割り当てる必要があります。 「Content-Location」[RFC2616]には、[RFC3986]で定義されているように、配信されるファイルを識別する構文的に有効なURIを割り当てる必要があります。たとえば、 "http"または "file" URIスキームのURIにすることができます。各ファイルに許可される「Content-Location」属性は1つだけです。 「Content-Location」フィールドは、ファイルを識別する文字列と見なす必要があります（つまり、2つの異なる文字列は2つの異なる識別子です）。オブジェクトを識別する以外の目的で「Content-Location」フィールドを使用することは、この仕様の範囲外です。同じ "Content-Location"を宣言するが "TOI"が異なる2つの "File"要素のセマンティクスは、FDTインスタンスIDが大きいFDTインスタンスに表示される要素が、新しいインスタンス（バージョンなど）を宣言すると見なされることです。同じ「ファイル」。
In addition to mandatory attributes, the "FDT-Instance" element and the "File" element MAY contain other attributes, of which the following are specifically pointed out:
必須の属性に加えて、「FDT-Instance」要素と「File」要素には他の属性を含めることができます（MAYは次のとおりです）。
* The attribute "Content-Type" SHOULD be included and, when present, MUST be used for the purpose defined in [RFC2616].
* 属性「Content-Type」を含める必要があり、存在する場合は、[RFC2616]で定義されている目的で使用する必要があります。
* Where the length is described, the attribute "Content-Length" MUST be used for the purpose defined in [RFC2616]. The transfer length is defined to be the length of the object transported in octets. It is often important to convey the transfer length to receivers, because the source block structure needs to be known for the FEC decoder to be applied to recover source blocks of the file, and the transfer length is often needed to properly determine the source block structure of the file. There generally will be a difference between the length of the original file and the transfer length if content encoding is applied to the file before transport, and thus the "Content-Encoding" attribute is used. If the file is not content encoded before transport (and thus the "Content-Encoding" attribute is not used), then the transfer length is the length of the original file, and in this case the "Content-Length" is also the transfer length. However, if the file is content encoded before transport (and thus the "Content-Encoding" attribute is used), e.g., if compression is applied before transport to reduce the number of octets that need to be transferred, then the transfer length is generally different than the length of the original file, and in this case the attribute "Transfer-Length" MAY be used to carry the transfer length.
* 長さが記述されている場合、[Content-Length]属性は、[RFC2616]で定義されている目的に使用する必要があります。転送長は、オクテットで転送されるオブジェクトの長さと定義されます。ファイルのソースブロックを回復するためにFECデコーダーを適用するにはソースブロック構造が既知である必要があり、ソースブロック構造を適切に決定するために転送長がしばしば必要になるため、転送長をレシーバーに伝えることがしばしば重要です。ファイルの。転送前にコンテンツエンコーディングがファイルに適用される場合、通常は元のファイルの長さと転送の長さの間に差があるため、「Content-Encoding」属性が使用されます。転送前にファイルがコンテンツエンコードされていない場合（したがって「Content-Encoding」属性が使用されない場合）、転送長は元のファイルの長さであり、この場合、「Content-Length」も転送されます。長さ。ただし、ファイルが転送前にコンテンツエンコードされている場合（したがって「Content-Encoding」属性が使用される場合）、たとえば転送する必要があるオクテットの数を減らすために転送前に圧縮が適用される場合、転送長は通常元のファイルの長さとは異なり、この場合、 "Transfer-Length"属性を使用して転送の長さを保持できます。
* Whenever content encoding is applied, the attribute "Content-Encoding" MUST be included. Whenever the attribute "Content-Encoding" is included, it MUST be used as described in [RFC2616].
* コンテンツのエンコーディングが適用される場合は常に、「Content-Encoding」属性を含める必要があります。 「Content-Encoding」属性が含まれる場合は常に、[RFC2616]で説明されているように使用する必要があります。
* Where the MD5 message digest is described, the attribute "Content-MD5" MUST be used for the purpose defined in [RFC2616]. Note that the goal is to provide a decoded object integrity service in cases where transmission and/or FLUTE/ALC processing errors may occur (the probability of collision is in that case negligible). It MUST NOT be regarded as a security mechanism (see Section 7 for information regarding security measures).
* MD5メッセージダイジェストが記述されている場合、[Content-MD5]属性は、[RFC2616]で定義されている目的で使用する必要があります。目的は、送信エラーやFLUTE / ALC処理エラーが発生する可能性がある場合に、デコードされたオブジェクト整合性サービスを提供することです（その場合、衝突の確率は無視できます）。セキュリティメカニズムと見なしてはなりません（セキュリティ対策に関する情報については、セクション7を参照してください）。
* The FEC Object Transmission Information attributes are described in Section 5.
* FECオブジェクト転送情報属性については、セクション5で説明します。
The following specifies the XML Schema [XML-Schema-Part-1] [XML-Schema-Part-2] for the FDT Instance:
以下は、FDTインスタンスのXMLスキーマ[XML-Schema-Part-1] [XML-Schema-Part-2]を指定します。
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:ietf:params:xml:ns:fdt"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:fdt"
elementFormDefault="qualified">
<xs:element name="FDT-Instance" type="FDT-InstanceType"/>
<xs:complexType name="FDT-InstanceType">
<xs:sequence>
<xs:element name="File" type="FileType" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Expires"
type="xs:string"
use="required"/>
<xs:attribute name="Complete"
type="xs:boolean"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="FileType">
<xs:sequence>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Content-Location"
type="xs:anyURI"
use="required"/>
<xs:attribute name="TOI"
type="xs:positiveInteger"
use="required"/>
<xs:attribute name="Content-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Transfer-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-MD5"
type="xs:base64Binary"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:schema>
END
Figure 3: XML Schema for the FDT Instance
図3：FDTインスタンスのXMLスキーマ
Any valid FDT Instance MUST use the above XML Schema. This way, FDT provides extensibility to support private elements and private attributes within the file description entries. Those could be, for example, the attributes related to the delivery of the file (timing, packet transmission rate, etc.). Unsupported private elements and attributes SHOULD be silently ignored by a FLUTE receiver.
有効なFDTインスタンスはすべて、上記のXMLスキーマを使用する必要があります。このように、FDTは、ファイル記述エントリ内のプライベート要素とプライベート属性をサポートする拡張性を提供します。これらは、たとえば、ファイルの配信に関連する属性（タイミング、パケット転送速度など）です。サポートされていないプライベート要素と属性は、FLUTEレシーバーによって暗黙的に無視される必要があります（SHOULD）。
In case the basic FDT XML Schema is extended in terms of new descriptors (attributes or elements), for descriptors applying to a single file, those MUST be placed within the element "File". For descriptors applying to all files described by the current FDT Instance, those MUST be placed within the element "FDT-Instance". It is RECOMMENDED that the new attributes applied in the FDT be in the format of message header fields and be either defined in the HTTP/1.1 specification [RFC2616] or another well-known specification, or in an IANA registry [IANAheaderfields]. However, this specification doesn't prohibit the use of other formats to allow private attributes to be used when interoperability is not a concern.
基本的なFDT XMLスキーマが新しい記述子（属性または要素）の観点から拡張されている場合、単一のファイルに適用される記述子の場合、それらは要素 "File"内に配置する必要があります。現在のFDTインスタンスによって記述されているすべてのファイルに適用される記述子の場合、それらは要素「FDT-Instance」内に配置する必要があります。 FDTに適用される新しい属性はメッセージヘッダーフィールドの形式であり、HTTP / 1.1仕様[RFC2616]または別のよく知られた仕様、またはIANAレジストリ[IANAheaderfields]で定義することをお勧めします。ただし、この仕様では、相互運用性が問題にならない場合に、他の形式を使用してプライベート属性を使用できるようにすることを禁止していません。
The FDT Instance itself MAY be content encoded (e.g., compressed). This specification defines the FDT Instance Content Encoding Header (EXT_CENC). EXT_CENC is a new fixed-length LCT Header Extension [RFC5651]. The Header Extension Type (HET) for the extension is 193. If the FDT Instance is content encoded, EXT_CENC MUST be used to signal the content encoding type. In that case, the EXT_CENC Header Extension MUST be used in all ALC packets carrying the same FDT Instance ID. Consequently, when the EXT_CENC header is used, it MUST be used together with a proper FDT Instance Header (EXT_FDT). Within a file delivery session, FDT Instances that are not content encoded and FDT Instances that are content encoded MAY both appear. If content encoding is not used for a given FDT Instance, EXT_CENC MUST NOT be used in any packet carrying the FDT Instance. The format of EXT_CENC is defined below:
FDTインスタンス自体は、コンテンツがエンコードされている（たとえば、圧縮されている）場合があります。この仕様は、FDTインスタンスコンテンツエンコーディングヘッダー（EXT_CENC）を定義します。 EXT_CENCは、新しい固定長LCTヘッダー拡張[RFC5651]です。拡張のヘッダー拡張タイプ（HET）は193です。FDTインスタンスがコンテンツエンコードされている場合は、コンテンツエンコードタイプを通知するためにEXT_CENCを使用する必要があります。その場合、同じFDTインスタンスIDを伝送するすべてのALCパケットでEXT_CENCヘッダー拡張を使用する必要があります。したがって、EXT_CENCヘッダーを使用する場合は、適切なFDTインスタンスヘッダー（EXT_FDT）と共に使用する必要があります。ファイル配信セッション内では、コンテンツエンコードされていないFDTインスタンスとコンテンツエンコードされているFDTインスタンスの両方が表示される場合があります。特定のFDTインスタンスにコンテンツエンコーディングが使用されていない場合、FDTインスタンスを運ぶパケットでEXT_CENCを使用してはなりません（MUST NOT）。 EXT_CENCのフォーマットは以下に定義されています：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 193 | CENC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EXT_CENC Format
図4：EXT_CENCフォーマット
Content Encoding Algorithm (CENC), 8 bits:
コンテンツエンコーディングアルゴリズム（CENC）、8ビット：
This field signals the content encoding algorithm used in the FDT Instance payload. This subsection reserves the Content Encoding Algorithm values 0, 1, 2, and 3 for null, ZLIB [RFC1950], DEFLATE [RFC1951], and GZIP [RFC1952], respectively.
このフィールドは、FDTインスタンスのペイロードで使用されるコンテンツエンコーディングアルゴリズムを示します。このサブセクションでは、コンテンツエンコーディングアルゴリズムの値0、1、2、3をそれぞれnull、ZLIB [RFC1950]、DEFLATE [RFC1951]、GZIP [RFC1952]に予約しています。
Reserved, 16 bits:
予約済み、16ビット：
This field MUST be set to all '0's. This field MUST be ignored on reception.
このフィールドはすべて「0」に設定する必要があります。このフィールドは、受信時には無視する必要があります。
The delivered files are carried as transmission objects (identified with TOIs) in the file delivery session. All these objects, including the FDT Instances, MAY be multiplexed in any order and in parallel with each other within a session; i.e., packets for one file may be interleaved with packets for other files or other FDT Instances within a session.
配信されたファイルは、ファイル配信セッションで送信オブジェクト（TOIで識別）として運ばれます。 FDTインスタンスを含むこれらすべてのオブジェクトは、セッション内で任意の順序で並列に多重化できます（MAY）。つまり、1つのファイルのパケットは、セッション内の他のファイルまたは他のFDTインスタンスのパケットとインターリーブされます。
Multiple FDT Instances MAY be delivered in a single session using TOI = 0. In this case, it is RECOMMENDED that the sending of a previous FDT Instance SHOULD end before the sending of the next FDT Instance starts. However, due to unexpected network conditions, packets for the FDT Instances might be interleaved. A receiver can determine which FDT Instance a packet contains information about, since the FDT Instances are uniquely identified by their FDT Instance ID carried in the EXT_FDT headers.
TOI = 0を使用して、単一のセッションで複数のFDTインスタンスを配信できます。この場合、次のFDTインスタンスの送信が開始する前に、前のFDTインスタンスの送信を終了することをお勧めします。ただし、予期しないネットワーク状態により、FDTインスタンスのパケットがインターリーブされる可能性があります。 FDTインスタンスはEXT_FDTヘッダーに含まれるFDTインスタンスIDによって一意に識別されるため、受信者はパケットに情報が含まれているFDTインスタンスを特定できます。
ALC/LCT has a concept of channels and congestion control. There are four scenarios in which FLUTE is envisioned to be applied.
ALC / LCTには、チャネルと輻輳制御の概念があります。 FLUTEの適用が想定されるシナリオは4つあります。
(a) Use of a single channel and a single-rate congestion control protocol.
（a）単一チャネルと単一レートの輻輳制御プロトコルの使用。
(b) Use of multiple channels and a multiple-rate congestion control protocol. In this case, the FDT Instances MAY be delivered on more than one channel.
（b）複数のチャネルと複数のレートの輻輳制御プロトコルの使用。この場合、FDTインスタンスは複数のチャネルで配信される場合があります。
(c) Use of a single channel without congestion control supplied by ALC, but only when in a controlled network environment where flow/congestion control is being provided by other means.
（c）ALCによって提供される輻輳制御なしの単一チャネルの使用。ただし、フロー/輻輳制御が他の手段によって提供されている制御されたネットワーク環境でのみ。
(d) Use of multiple channels without congestion control supplied by ALC, but only when in a controlled network environment where flow/congestion control is being provided by other means. In this case, the FDT Instances MAY be delivered on more than one channel.
（d）ALCによって提供される輻輳制御なしの複数のチャネルの使用。ただし、他の手段によってフロー/輻輳制御が提供されている制御されたネットワーク環境でのみ。この場合、FDTインスタンスは複数のチャネルで配信される場合があります。
When using just one channel for a file delivery session, as in (a) and (c), the notion of 'prior' and 'after' are intuitively defined for the delivery of objects with respect to their delivery times.
（a）と（c）のように、ファイル配信セッションに1つのチャネルのみを使用する場合、オブジェクトの配信時間に関して、「優先」および「後」の概念がオブジェクトの配信に対して直感的に定義されます。
However, if multiple channels are used, as in (b) and (d), it is not straightforward to state that an object was delivered 'prior' to the other. An object may begin to be delivered on one or more of those channels before the delivery of a second object begins. However, the use of multiple channels/layers may mean that the delivery of the second object is completed before the first. This is not a problem when objects are delivered sequentially using a single channel. Thus, if the application of FLUTE has a mandatory or critical requirement that the first transmission object must complete 'prior' to the second one, it is RECOMMENDED that only a single channel be used for the file delivery session.
ただし、（b）と（d）のように複数のチャネルが使用されている場合、オブジェクトが他のオブジェクトよりも「先に」配信されたと述べることは簡単ではありません。オブジェクトは、2番目のオブジェクトの配信が始まる前に、これらのチャネルの1つ以上で配信され始める場合があります。ただし、複数のチャネル/レイヤーの使用は、2番目のオブジェクトの配信が最初のオブジェクトの前に完了することを意味する場合があります。オブジェクトが単一のチャネルを使用して順次配信される場合、これは問題ではありません。したがって、FLUTEのアプリケーションに、最初の送信オブジェクトが2番目の送信オブジェクトよりも「前に」完了しなければならないという必須または重要な要件がある場合、ファイル配信セッションに単一のチャネルのみを使用することをお勧めします。
Furthermore, if multiple channels are used, then a receiver joined to the session at a low reception rate will only be joined to the lower layers of the session. Thus, since the reception of FDT Instances is of higher priority than the reception of files (because the reception of files depends on the reception of an FDT Instance describing it), the following are RECOMMENDED:
さらに、複数のチャネルが使用されている場合、低い受信レートでセッションに参加しているレシーバーは、セッションの下位層にのみ参加します。したがって、FDTインスタンスの受信はファイルの受信よりも優先度が高いため（ファイルの受信はそれを記述するFDTインスタンスの受信に依存するため）、以下をお勧めします。
1. The layers to which packets for FDT Instances are sent SHOULD NOT be biased towards those layers to which lower-rate receivers are not joined. For example, it is okay to put all the packets for an FDT Instance into the lowest layer (if this layer carries enough packets to deliver the FDT to higher-rate receivers in a reasonable amount of time), but it is not okay to put all the packets for an FDT Instance into the higher layers that only higher-rate receivers will receive.
1. FDTインスタンスのパケットが送信されるレイヤーは、低速の受信機が参加していないレイヤーに偏らないようにする必要があります（SHOULD NOT）。たとえば、FDTインスタンスのすべてのパケットを最下層に配置することは問題ありません（この層がFDTを高速受信機に妥当な時間内に配信するのに十分なパケットを運ぶ場合）。ただし、 FDTインスタンスのすべてのパケットを、高レートのレシーバーのみが受信する高レイヤーに送信します。
2. If FDT Instances are generally longer than one Encoding Symbol in length and some packets for FDT Instances are sent to layers that lower-rate receivers do not receive, an FEC encoding other than Compact No-Code FEC Encoding ID 0 [RFC5445] SHOULD be used to deliver FDT Instances. This is because in this case, even when there is no packet loss in the network, a lower-rate receiver will not receive all packets sent for an FDT Instance.
2. FDTインスタンスが一般的に1つのエンコーディングシンボルよりも長く、FDTインスタンスの一部のパケットが低レートレシーバーが受信しないレイヤーに送信される場合、コンパクトなノーコードFECエンコーディングID 0 [RFC5445]以外のFECエンコーディングを使用する必要がありますFDTインスタンスを提供します。これは、この場合、ネットワークでパケット損失がない場合でも、FDTインスタンス用に送信されたすべてのパケットを低速の受信機が受信するわけではないためです。
FLUTE inherits the use of the FEC building block [RFC5052] from ALC. When using FLUTE for file delivery over ALC, the FEC Object Transmission Information MUST be delivered in-band within the file delivery session. There are two methods to achieve this: the use of the ALC-specific LCT Header Extension EXT_FTI [RFC5775] and the use of the FDT. The latter method is specified in this section. The use of EXT_FTI requires repetition of the FEC Object Transmission Information to ensure reception (though not necessarily in every packet) and thus may entail higher overhead than the use of the FDT, but may also provide more timely delivery of the FEC Object Transmission Information.
FLUTEは、ALCからFECビルディングブロック[RFC5052]の使用を継承しています。 ALCを介したファイル配信にFLUTEを使用する場合、FECオブジェクト転送情報は、ファイル配信セッション内のインバンドで配信する必要があります。これを実現するには2つの方法があります。ALC固有のLCTヘッダー拡張EXT_FTI [RFC5775]の使用とFDTの使用です。後者の方法は、このセクションで指定されています。 EXT_FTIを使用するには、受信を確実にするためにFECオブジェクト送信情報を繰り返す必要があります（ただし、必ずしもすべてのパケットで送信する必要はありません）。したがって、FDTを使用する場合よりもオーバーヘッドが高くなる可能性がありますが、FECオブジェクト送信情報をよりタイムリーに配信できる場合もあります。
The receiver of a file delivery session MUST support delivery of FEC Object Transmission Information using EXT_FTI for the FDT Instances carried using TOI value 0. For the TOI values other than 0, the receiver MUST support both methods: the use of EXT_FTI and the use of the FDT.
ファイル配信セッションの受信者は、TOI値0を使用してFDTインスタンスのEXT_FTIを使用したFECオブジェクト送信情報の配信をサポートする必要があります。0以外のTOI値の場合、受信者は両方のメソッドをサポートする必要があります。 FDT。
The FEC Object Transmission Information that needs to be delivered to receivers MUST be exactly the same whether it is delivered using EXT_FTI or using the FDT (or both). The FEC Object Transmission Information that MUST be delivered to receivers is defined by the FEC Scheme. This section describes the delivery using the FDT.
受信者に配信する必要があるFECオブジェクト転送情報は、EXT_FTIを使用して配信されるか、FDT（またはその両方）を使用して配信されるかとまったく同じである必要があります。受信者に配信しなければならないFECオブジェクト送信情報は、FECスキームによって定義されます。このセクションでは、FDTを使用した配信について説明します。
The FEC Object Transmission Information regarding a given TOI may be available from several sources. In this case, it is RECOMMENDED that the receiver of the file delivery session prioritize the sources in the following way (in order of decreasing priority).
特定のTOIに関するFECオブジェクト送信情報は、いくつかのソースから入手できる場合があります。この場合、ファイル配信セッションの受信者は、次の方法でソースを優先順位付けすることをお勧めします（優先度の高い順に）。
1. FEC Object Transmission Information that is available in EXT_FTI.
1. EXT_FTIで利用可能なFECオブジェクト転送情報。
2. FEC Object Transmission Information that is available in the FDT.
2. FDTで利用可能なFECオブジェクト転送情報。
The FDT delivers FEC Object Transmission Information for each file using an appropriate attribute within the "FDT-Instance" or the "File" element of the FDT structure.
FDTは、FDT構造の「FDT-Instance」または「File」要素内の適切な属性を使用して、各ファイルのFECオブジェクト転送情報を配信します。
* "Transfer-Length" carries the "Transfer-Length" Object Transmission Information element defined in [RFC5052].
* 「Transfer-Length」は、[RFC5052]で定義されている「Transfer-Length」オブジェクト伝送情報要素を保持します。
* "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object Transmission Information element defined in [RFC5052], as carried in the Codepoint field of the ALC/LCT header.
* 「FEC-OTI-FEC-Encoding-ID」は、ALC / LCTヘッダーのコードポイントフィールドで運ばれるように、[RFC5052]で定義された「FECエンコーディングID」オブジェクト伝送情報要素を運びます。
* "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object Transmission Information element defined in [RFC5052] for Under-Specified FEC Schemes.
* 「FEC-OTI-FEC-Instance-ID」は、[RFC5052]で定義されている、不十分な仕様のFECスキーム用の「FECインスタンスID」オブジェクト伝送情報要素を伝達します。
* "FEC-OTI-Maximum-Source-Block-Length" carries the "Maximum-Source-Block-Length" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.
* 「FEC-OTI-Maximum-Source-Block-Length」は、FECスキームで必要な場合、[RFC5052]で定義されている「Maximum-Source-Block-Length」オブジェクト転送情報要素を伝送します。
* "FEC-OTI-Encoding-Symbol-Length" carries the "Encoding-Symbol-Length" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.
* 「FEC-OTI-Encoding-Symbol-Length」は、FECスキームで必要な場合、[RFC5052]で定義されている「Encoding-Symbol-Length」オブジェクト伝送情報要素を保持します。
* "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the "Max-Number-of-Encoding-Symbols" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.
* 「FEC-OTI-Max-Number-of-Encoding-Symbols」は、FECスキームで必要な場合、[RFC5052]で定義されている「Max-Number-of-Encoding-Symbols」オブジェクト伝送情報要素を伝達します。
* "FEC-OTI-Scheme-Specific-Info" carries the "encoded Scheme-specific FEC Object Transmission Information" as defined in [RFC5052], if required by the FEC Scheme.
* 「FEC-OTI-Scheme-Specific-Info」は、FECスキームで必要な場合、[RFC5052]で定義されている「エンコードされたスキーム固有のFECオブジェクト送信情報」を伝送します。
In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be carried in the Codepoint field of the ALC/LCT header. When the FEC Object Transmission Information for this TOI is delivered through the FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the Codepoint field of all packets for this TOI MUST be the same.
FLUTEでは、特定のTOIのFECエンコーディングID（8ビット）は、ALC / LCTヘッダーのコードポイントフィールドで伝送する必要があります。このTOIのFECオブジェクト送信情報がFDTを介して配信される場合、関連する「FEC-OTI-FEC-Encoding-ID」属性と、このTOIのすべてのパケットのコードポイントフィールドは同じでなければなりません。
To start receiving a file delivery session, the receiver needs to know transport parameters associated with the session. Interpreting these parameters and starting the reception therefore represent the entry point from which thereafter the receiver operation falls into the scope of this specification. According to [RFC5775], the transport parameters of an ALC/LCT session that the receiver needs to know are:
ファイル配信セッションの受信を開始するには、受信者はセッションに関連付けられたトランスポートパラメータを知っている必要があります。したがって、これらのパラメーターを解釈して受信を開始することは、その後のレシーバー操作がこの仕様の範囲に入るエントリポイントを表します。 [RFC5775]によれば、受信者が知る必要があるALC / LCTセッションのトランスポートパラメータは次のとおりです。
* The source IP address;
* 送信元IPアドレス。
* The number of channels in the session;
* セッションのチャネル数。
* The destination IP address and port number for each channel in the session;
* セッションの各チャネルの宛先IPアドレスとポート番号。
* The Transport Session Identifier (TSI) of the session;
* セッションのトランスポートセッション識別子（TSI）。
* An indication that the session is a FLUTE session. The need to demultiplex objects upon reception is implicit in any use of FLUTE, and this fulfills the ALC requirement of an indication of whether or not a session carries packets for more than one object (all FLUTE sessions carry packets for more than one object).
* セッションがFLUTEセッションであることを示します。受信時にオブジェクトを逆多重化する必要性は、FLUTEを使用する際に暗黙的に発生します。これは、セッションが複数のオブジェクトのパケットを運ぶかどうかを示すALC要件を満たします（すべてのFLUTEセッションが複数のオブジェクトのパケットを運ぶ）。
Optionally, the following parameters MAY be associated with the session (note that the list is not exhaustive):
オプションで、以下のパラメーターをセッションに関連付けることができます（リストは完全ではないことに注意してください）。
* The start time and end time of the session;
* セッションの開始時間と終了時間。
* FEC Encoding ID and FEC Instance ID when the default FEC Encoding ID 0 is not used for the delivery of the FDT;
* FDTの配信にデフォルトのFECエンコーディングID 0が使用されていない場合のFECエンコーディングIDおよびFECインスタンスID。
* Content encoding format if optional content encoding of the FDT Instance is used, e.g., compression;
* FDTインスタンスのオプションのコンテンツエンコーディングが使用されている場合のコンテンツエンコーディング形式（圧縮など）。
* Some information that tells receiver, in the first place, that the session contains files that are of interest;
* そもそも、セッションに重要なファイルが含まれていることを受信者に伝えるいくつかの情報。
* Definition and configuration of a congestion control mechanism for the session;
* セッションの輻輳制御メカニズムの定義と構成。
* Security parameters relevant for the session;
* セッションに関連するセキュリティパラメータ。
* FLUTE version number.
* FLUTEバージョン番号。
It is envisioned that these parameters would be described according to some session description syntax (such as SDP [RFC4566] or XML based) and held in a file that would be acquired by the receiver before the FLUTE session begins by means of some transport protocol (such as the Session Announcement Protocol (SAP) [RFC2974], email, HTTP [RFC2616], SIP [RFC3261], manual preconfiguration, etc.). However, the way in which the receiver discovers the above-mentioned parameters is out of scope of this document, as it is for LCT and ALC. In particular, this specification does not mandate or exclude any mechanism.
これらのパラメーターは、いくつかのセッション記述構文（SDP [RFC4566]またはXMLベースなど）に従って記述され、何らかのトランスポートプロトコル（FLUTEセッションが開始する前に受信者が取得するファイルに保持される）が想定されます。たとえば、Session Announcement Protocol（SAP）[RFC2974]、電子メール、HTTP [RFC2616]、SIP [RFC3261]、手動事前設定など）。ただし、レシーバーが上記のパラメーターを検出する方法は、LCTおよびALCの場合と同様に、このドキュメントの範囲外です。特に、この仕様はメカニズムを義務付けたり除外したりするものではありません。
A content delivery system is potentially subject to attacks. Attacks may target:
コンテンツ配信システムは潜在的に攻撃の対象になります。攻撃の対象：
* the network (to compromise the routing infrastructure, e.g., by creating congestion),
* ネットワーク（たとえば、輻輳を作成することによってルーティングインフラストラクチャを危険にさらすため）、
* the Content Delivery Protocol (CDP) (e.g., to compromise the normal behavior of FLUTE), or
* コンテンツ配信プロトコル（CDP）（たとえば、FLUTEの通常の動作を危険にさらすため）、または
* the content itself (e.g., to corrupt the files being transmitted).
* コンテンツ自体（たとえば、送信されるファイルを破壊するため）。
These attacks can be launched either:
これらの攻撃は、次のいずれかで起動できます。
* against the data flow itself (e.g., by sending forged packets),
* データフロー自体に対して（たとえば、偽造されたパケットを送信することにより）、
* against the session control parameters (e.g., by corrupting the session description, the FDT Instances, or the ALC/LCT control parameters) that are sent either in-band or out-of-band, or
* 帯域内または帯域外のいずれかで送信されたセッション制御パラメーターに対して（たとえば、セッション記述、FDTインスタンス、またはALC / LCT制御パラメーターを破損することにより）、または
* against some associated building blocks (e.g., the congestion control component).
* 一部の関連するビルディングブロック（輻輳制御コンポーネントなど）に対して。
In the following sections, we provide more details on these possible attacks and sketch some possible countermeasures. We provide recommendations in Section 7.5.
次のセクションでは、これらの考えられる攻撃の詳細を提供し、考えられるいくつかの対策を示します。セクション7.5で推奨事項を示します。
Let us consider attacks against the data flow first. At the least, the following types of attacks exist:
まず、データフローに対する攻撃について考えてみましょう。少なくとも、次の種類の攻撃が存在します。
* attacks that are meant to give access to a confidential file (e.g., in the case of non-free content) and
* 機密ファイルへのアクセスを許可することを意図した攻撃（たとえば、フリーでないコンテンツの場合）および
* attacks that try to corrupt the file being transmitted (e.g., to inject malicious code within a file, or to prevent a receiver from using a file, which is a kind of denial of service (DoS)).
* 送信されているファイルを破壊しようとする攻撃（たとえば、ファイル内に悪意のあるコードを挿入したり、一種のサービス拒否（DoS）である受信者がファイルを使用できないようにする）。
Access control to the file being transmitted is typically provided by means of encryption. This encryption can be done over the whole file, i.e., before applying FEC protection (e.g., by the content provider, before submitting the file to FLUTE), or can be done on a packet-by-packet basis (e.g., when IPsec/ESP [RFC4303] is used; see Section 7.5). If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used.
送信されるファイルへのアクセス制御は、通常、暗号化によって提供されます。この暗号化は、ファイル全体で、つまりFEC保護を適用する前に（たとえば、コンテンツプロバイダーによって、ファイルをFLUTEに送信する前に）、またはパケット単位で（たとえば、IPsec / ESP [RFC4303]が使用されます（セクション7.5を参照）。機密性が懸念される場合は、これらのソリューションのいずれかを使用することをお勧めします。
Protection against corruptions (e.g., if an attacker sends forged packets) is achieved by means of a content integrity verification/ sender authentication scheme. This service can be provided at the file level, i.e., before applying content encoding and FEC encoding. In that case, a receiver has no way to identify which symbol(s) is(are) corrupted if the file is detected as corrupted. This service can also be provided at the packet level, i.e., after applying content encoding and FEC encoding, on a packet-by-packet basis. In this case, after removing all corrupted packets, the file may be in some cases recovered from the remaining correct packets.
破損からの保護（たとえば、攻撃者が偽造パケットを送信した場合）は、コンテンツの整合性検証/送信者認証スキームによって実現されます。このサービスは、ファイルレベルで、つまりコンテンツエンコーディングとFECエンコーディングを適用する前に提供できます。その場合、ファイルが破損していると検出された場合、受信者はどのシンボルが破損しているかを識別する方法がありません。このサービスは、パケットレベルで提供することもできます。つまり、コンテンツエンコーディングとFECエンコーディングを適用した後で、パケットごとに提供できます。この場合、破損したパケットをすべて削除した後、残りの正しいパケットからファイルが復元される場合があります。
Integrity protection applied at the file level has the advantage of lower overhead, since only relatively few bits are added to provide the integrity protection compared to the file size. However, it has the disadvantage that it cannot distinguish between correct packets and corrupt packets, and therefore correct packets, which may form the majority of packets received, may be unusable. Integrity protection applied at the packet level has the advantage that it can distinguish between correct and corrupt packets, at the cost of additional per-packet overhead.
ファイルレベルと比較して整合性保護を提供するために追加されるビットは比較的少ないため、ファイルレベルで適用される整合性保護にはオーバーヘッドが少ないという利点があります。ただし、正しいパケットと破損したパケットを区別できないため、受信したパケットの大部分を占める可能性のある正しいパケットが使用できなくなるという欠点があります。パケットレベルで適用される整合性保護には、パケットごとのオーバーヘッドが増えるという犠牲を払って、正しいパケットと破損したパケットを区別できるという利点があります。
Several techniques can provide this source authentication/content integrity service:
いくつかの手法で、このソース認証/コンテンツ整合性サービスを提供できます。
* At the file level, the file MAY be digitally signed (e.g., by using RSA Probabilistic Signature Scheme Public-Key Cryptography Standards version 1.5 (RSASSA-PKCS1-v1_5) [RFC3447]). This signature enables a receiver to check the file's integrity once the file has been fully decoded. Even if digital signatures are computationally expensive, this calculation occurs only once per file, which is usually acceptable.
* ファイルレベルでは、ファイルにデジタル署名を付けることができます（たとえば、RSA確率的署名方式の公開鍵暗号化規格バージョン1.5（RSASSA-PKCS1-v1_5）[RFC3447]を使用）。このシグネチャにより、ファイルが完全にデコードされると、受信者はファイルの整合性をチェックできます。デジタル署名の計算コストが高い場合でも、この計算はファイルごとに1回だけ行われ、通常はこれで問題ありません。
* At the packet level, each packet can be digitally signed [RFC6584]. A major limitation is the high computational and transmission overheads that this solution requires. To avoid this problem, the signature may span a set of symbols (instead of a single one) in order to amortize the signature calculation, but if a single symbol is missing, the integrity of the whole set cannot be checked.
* パケットレベルでは、各パケットにデジタル署名を付けることができます[RFC6584]。主な制限は、このソリューションが必要とする高い計算および伝送オーバーヘッドです。この問題を回避するために、シグネチャは、シグネチャ計算を償却するために、（1つではなく）シンボルのセットにまたがることがありますが、1つのシンボルが欠落している場合、セット全体の整合性をチェックできません。
* At the packet level, a Group-Keyed Message Authentication Code (MAC) [RFC2104] [RFC6584] scheme can be used; an example is using HMAC-SHA-256 with a secret key shared by all the group members, senders, and receivers. This technique creates a cryptographically secured digest of a packet that is sent along with the packet. The Group-Keyed MAC scheme does not create prohibitive processing load or transmission overhead, but it has a major limitation: it only provides a group authentication/ integrity service, since all group members share the same secret group key, which means that each member can send a forged packet. It is therefore restricted to situations where group members are fully trusted (or in association with another technique as a pre-check).
* パケットレベルでは、グループキーメッセージ認証コード（MAC）[RFC2104] [RFC6584]スキームを使用できます。たとえば、HMAC-SHA-256を使用して、すべてのグループメンバー、送信者、受信者が共有する秘密鍵を使用します。この手法は、パケットと共に送信される暗号化されたパケットのダイジェストを作成します。 Group-Keyed MACスキームは、過度の処理負荷や送信オーバーヘッドを発生させませんが、大きな制限があります。すべてのグループメンバーが同じ秘密グループキーを共有するため、グループ認証/整合性サービスのみを提供します。つまり、各メンバーは偽造パケットを送信します。したがって、これは、グループメンバーが完全に信頼されている（または事前チェックとして別の手法に関連している）状況に制限されます。
* At the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] [RFC5776] is an attractive solution that is robust to losses, provides a true authentication/ integrity service, and does not create any prohibitive processing load or transmission overhead. However, checking a packet requires a small delay (a second or more) after its reception.
* パケットレベルでは、Timed Efficient Stream Loss-Tolerant Authentication（TESLA）[RFC4082] [RFC5776]は、損失に強い魅力的なソリューションであり、真の認証/整合性サービスを提供し、過度の処理負荷や送信オーバーヘッドを発生させません。 。ただし、パケットのチェックには、受信後のわずかな遅延（1秒以上）が必要です。
* At the packet level, IPsec/ESP [RFC4303] can be used to check the integrity and authenticate the sender of all the packets being exchanged in a session (see Section 7.5).
* パケットレベルでは、IPsec / ESP [RFC4303]を使用して整合性をチェックし、セッションで交換されるすべてのパケットの送信者を認証できます（セクション7.5を参照）。
Techniques relying on public key cryptography (digital signatures and TESLA during the bootstrap process, when used) require that public keys be securely associated to the entities. This can be achieved by a Public Key Infrastructure (PKI), or by a Pretty Good Privacy (PGP) Web of Trust, or by pre-distributing the public keys of each group member.
公開鍵暗号化に依存する手法（ブートストラッププロセス中のデジタル署名とTESLAを使用する場合）では、公開鍵をエンティティに安全に関連付ける必要があります。これは、公開キー基盤（PKI）、プリティグッドプライバシー（PGP）Web of Trust、または各グループメンバーの公開キーを事前に配布することで実現できます。
Techniques relying on symmetric key cryptography (Group-Keyed MAC) require that a secret key be shared by all group members. This can be achieved by means of a group key management protocol, or simply by pre-distributing the secret key (but this manual solution has many limitations).
対称キー暗号化（Group-Keyed MAC）に依存する手法では、すべてのグループメンバーが秘密キーを共有する必要があります。これは、グループキー管理プロトコルを使用して、または単に秘密キーを事前に配布することで実現できます（ただし、この手動のソリューションには多くの制限があります）。
It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate. Nonetheless, in case there is any concern of the threat of file corruption, it is RECOMMENDED that at least one of these techniques be used.
どのアプリケーションが最も適切であるかを定義するのは、ターゲットアプリケーション領域のセキュリティ要件と機能を知っている開発者とデプロイヤー次第です。それでも、ファイルの破損の恐れがある場合は、これらの手法の少なくとも1つを使用することをお勧めします。
7.3. Attacks against the Session Control Parameters and Associated Building Blocks
7.3. セッション制御パラメーターおよび関連するビルディングブロックに対する攻撃
Let us now consider attacks against the session control parameters and the associated building blocks. The attacker has at least the following opportunities to launch an attack:
次に、セッション制御パラメーターおよび関連する構成要素に対する攻撃について考えてみましょう。攻撃者は、少なくとも以下の攻撃を開始する機会があります。
* the attack can target the session description,
* 攻撃はセッションの説明を標的にすることができ、
* the attack can target the FDT Instances,
* 攻撃はFDTインスタンスを標的にすることができ、
* the attack can target the ALC/LCT parameters, carried within the LCT header, or
* 攻撃は、LCTヘッダー内で運ばれるALC / LCTパラメータを標的にすることができます。
* the attack can target the FLUTE associated building blocks (e.g., the multiple-rate congestion control protocol).
* 攻撃は、FLUTEに関連付けられたビルディングブロック（マルチレート輻輳制御プロトコルなど）を標的にすることができます。
The consequences of these attacks are potentially serious, since they might compromise the behavior of the content delivery system itself.
これらの攻撃はコンテンツ配信システム自体の動作を危険にさらす可能性があるため、これらの結果は潜在的に深刻です。
A FLUTE receiver may potentially obtain an incorrect session description for the session. The consequence of this is that legitimate receivers with the wrong session description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby possibly disrupting other traffic in the network.
FLUTEレシーバーは、セッションの誤ったセッション記述を取得する可能性があります。この結果、セッションの説明が間違っている正当な受信者がセッションのコンテンツを正しく受信できなかったり、受信者が不注意に自分の能力よりもはるかに高いレートで受信しようとしたりして、ネットワーク内の他のトラフィックが中断される可能性があります。
To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions. One such measure is source authentication to ensure that receivers only accept legitimate session descriptions from authorized senders. How these measures are achieved is outside the scope of this document, since this session description is usually carried out-of-band.
これらの問題を回避するには、受信者が誤ったセッション記述を受け入れないようにするための対策を講じることをお勧めします。そのような手段の1つは、受信者が正当な送信者からの正当なセッション記述のみを受け入れることを保証するソース認証です。このセッションの説明は通常、帯域外で行われるため、これらの手段がどのように達成されるかは、このドキュメントの範囲外です。
Corrupting the FDT Instances is one way to create a DoS attack. For example, the attacker changes the MD5 sum associated to a file. This possibly leads a receiver to reject the files received, no matter whether the files have been correctly received or not.
FDTインスタンスの破損は、DoS攻撃を作成する1つの方法です。たとえば、攻撃者はファイルに関連付けられているMD5サムを変更します。これにより、ファイルが正しく受信されたかどうかに関係なく、受信者が受信したファイルを拒否する可能性があります。
Corrupting the FDT Instances is also a way to make the reception process more costly than it should be. This can be achieved by changing the FEC Object Transmission Information when the FEC Object Transmission Information is included in the FDT Instance. For example, an attacker may corrupt the FDT Instance in such a way that Reed-Solomon over GF(2^^16) would be used instead of GF(2^^8) with FEC Encoding ID 2. This may significantly increase the processing load while compromising FEC decoding.
FDTインスタンスを破損させることは、受信プロセスを本来よりも高価にする方法でもあります。これは、FECオブジェクト転送情報がFDTインスタンスに含まれているときにFECオブジェクト転送情報を変更することで実現できます。たとえば、攻撃者はFDTインスタンスを破壊する可能性があり、GF（2 ^^ 8）の代わりにFECエンコーディングID 2のGF（2 ^^ 16）上のリードソロモンが使用される可能性があります。これにより、処理が大幅に増加する可能性があります。 FECデコードを危険にさらしながらロードします。
More generally, because FDT Instance data is structured using the XML language by means of an XML media type, many of the security considerations described in [RFC3023] and [RFC3470] also apply to such data.
より一般的には、FDTインスタンスデータはXMLメディアタイプを使用してXML言語を使用して構造化されるため、[RFC3023]および[RFC3470]で説明されているセキュリティに関する考慮事項の多くは、そのようなデータにも適用されます。
It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the FDT Instances. To that purpose, one of the countermeasures mentioned above (Section 7.2.2) SHOULD be used. These measures will either be applied on a packet level or globally over the whole FDT Instance object. Additionally, XML digital signatures [RFC3275] are a way to protect the FDT Instance by digitally signing it. When there is no packet-level integrity verification scheme, it is RECOMMENDED to rely on XML digital signatures of the FDT Instances.
したがって、整合性を保証し、FDTインスタンスの送信者のIDをチェックするための対策を講じることをお勧めします。そのためには、上記の対策（セクション7.2.2）の1つを使用する必要があります。これらの対策は、パケットレベルで適用されるか、FDTインスタンスオブジェクト全体にグローバルに適用されます。さらに、XMLデジタル署名[RFC3275]は、FDTインスタンスにデジタル署名することでFDTインスタンスを保護する方法です。パケットレベルの整合性検証スキームがない場合は、FDTインスタンスのXMLデジタル署名に依存することをお勧めします。
By corrupting the ALC/LCT header (or header extensions), one can execute attacks on the underlying ALC/LCT implementation. For example, sending forged ALC packets with the Close Session flag (A) set to one can lead the receiver to prematurely close the session. Similarly, sending forged ALC packets with the Close Object flag (B) set to one can lead the receiver to prematurely give up the reception of an object.
ALC / LCTヘッダー（またはヘッダー拡張）を破壊することにより、基礎となるALC / LCT実装に対して攻撃を実行できます。たとえば、セッションを閉じるフラグ（A）を1に設定して偽造されたALCパケットを送信すると、レシーバーがセッションを途中で閉じる可能性があります。同様に、オブジェクトのクローズフラグ（B）を1に設定して偽造されたALCパケットを送信すると、レシーバーがオブジェクトの受信を途中でやめる可能性があります。
It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the ALC packets received. To that purpose, one of the countermeasures mentioned above (Section 7.2.2) SHOULD be used.
したがって、整合性を保証し、受信したALCパケットの送信者のIDを確認するための対策を講じることをお勧めします。そのためには、上記の対策（セクション7.2.2）の1つを使用する必要があります。
Let us first focus on the congestion control building block, which may be used in the ALC session. A receiver with an incorrect or corrupted implementation of the multiple-rate congestion control building block may affect the health of the network in the path between the sender and the receiver. That may also affect the reception rates of other receivers who joined the session.
まず、ALCセッションで使用される可能性がある輻輳制御ビルディングブロックに焦点を当てましょう。マルチレート輻輳制御ビルディングブロックの実装が正しくないか壊れているレシーバーは、センダーとレシーバーの間のパスのネットワークの状態に影響を与える可能性があります。また、セッションに参加した他の受信者の受信率にも影響を与える可能性があります。
When the congestion control building block is applied with FLUTE, it is RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the session description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document. If authenticating a receiver does not prevent this receiver from launching an attack, this authentication will enable the network operator to identify him and to take countermeasures.
輻輳制御ビルディングブロックがFLUTEで適用される場合、セッションに参加するために必要なセッションの説明を受信する前に、受信者が正当なものであることを識別する必要があります。受信者が正当なものとして自分を識別する方法は、このドキュメントの範囲外です。受信者を認証してもこの受信者が攻撃を開始することを妨げない場合、この認証により、ネットワークオペレーターは受信者を識別し、対策を講じることができます。
When the congestion control building block is applied with FLUTE, it is also RECOMMENDED that a packet-level authentication scheme be used, as explained in Section 7.2.2. Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control requires a rapid reaction. It is therefore RECOMMENDED [RFC5775] that a receiver using TESLA quickly reduce its subscription level when the receiver believes that congestion did occur, even if the packet has not yet been authenticated. Therefore, TESLA will not prevent DoS attacks where an attacker makes the receiver believe that congestion occurred. This is an issue for the receiver, but this will not compromise the network. Other authentication methods that do not feature this delayed authentication could be preferred, or a Group-Keyed MAC scheme could be used in parallel with TESLA to prevent attacks launched from outside of the group.
輻輳制御ビルディングブロックがFLUTEで適用される場合、セクション7.2.2で説明されているように、パケットレベルの認証方式を使用することも推奨されます。 TESLAなどの一部のサービスでは遅延認証サービスしか提供されませんが、輻輳制御には迅速な対応が必要です。したがって、パケットがまだ認証されていない場合でも、輻輳が発生したと受信者が信じる場合、TESLAを使用する受信者がサブスクリプションレベルをすばやく下げることが推奨されます[RFC5775]。したがって、TESLAは、攻撃者が受信者に輻輳が発生したと信じ込ませるDoS攻撃を防止しません。これは受信機の問題ですが、ネットワークを危険にさらすことはありません。この遅延認証を備えていない他の認証方法が優先される場合や、グループキードMACスキームをTESLAと並行して使用して、グループの外部からの攻撃を防ぐことができます。
The security considerations that apply to, and are described in, ALC [RFC5775], LCT [RFC5651], and FEC [RFC5052] also apply to FLUTE, as FLUTE builds on those specifications. In addition, any security considerations that apply to any congestion control building block used in conjunction with FLUTE also apply to FLUTE.
ALC [RFC5775]、LCT [RFC5651]、およびFEC [RFC5052]に適用され、これらに説明されているセキュリティの考慮事項は、FLUTEがそれらの仕様に基づいているため、FLUTEにも適用されます。さらに、FLUTEと組み合わせて使用される輻輳制御ビルディングブロックに適用されるセキュリティ上の考慮事項は、FLUTEにも適用されます。
Even if FLUTE defines a purely unidirectional delivery service, without any feedback information that would be sent to the sender, security considerations MAY require bidirectional communications. For instance, if an automated key management scheme is used, a bidirectional point-to-point channel is often needed to establish a shared secret between each receiver and the sender. Each shared secret can then be used to distribute additional keys to the associated receiver (e.g., traffic encryption keys).
FLUTEが純粋に単一方向の配信サービスを定義していても、送信者に送信されるフィードバック情報がない場合、セキュリティの考慮事項には双方向通信が必要になる場合があります。たとえば、自動化されたキー管理スキームが使用されている場合、各受信者と送信者の間で共有秘密を確立するために、双方向のポイントツーポイントチャネルが必要になることがよくあります。次に、各共有シークレットを使用して、関連する受信者に追加のキーを配布できます（トラフィック暗号化キーなど）。
As an example, [MBMSsecurity] details a complete security framework for the Third Generation Partnership Project (3GPP) Multimedia Broadcast/Multicast Service (MBMS) that relies on FLUTE/ALC for Download Sessions. It relies on bidirectional point-to-point communications for User Equipment authentication and for key distribution, using the Multimedia Internet KEYing (MIKEY) protocol [RFC3830]. Because this security framework is specific to this use case, it cannot be reused as such for generic security recommendations in this specification. Instead, the following section introduces minimum security recommendations.
例として、[MBMSsecurity]は、ダウンロードセッションをFLUTE / ALCに依存する第3世代パートナーシッププロジェクト（3GPP）マルチメディアブロードキャスト/マルチキャストサービス（MBMS）の完全なセキュリティフレームワークについて詳しく説明しています。マルチメディアインターネットキーイング（MIKEY）プロトコル[RFC3830]を使用して、ユーザー機器の認証とキーの配布を双方向のポイントツーポイント通信に依存しています。このセキュリティフレームワークはこのユースケースに固有であるため、この仕様の一般的なセキュリティの推奨事項にそのまま再利用することはできません。代わりに、次のセクションでは最低限のセキュリティの推奨事項を紹介します。
We now introduce a mandatory-to-implement, but not necessarily to use, security configuration, in the sense of [RFC3365]. Since FLUTE relies on ALC/LCT, it inherits the "baseline secure ALC operation" of [RFC5775]. More precisely, security is achieved by means of IPsec/ ESP in transport mode. [RFC4303] explains that ESP can be used to potentially provide confidentiality, data origin authentication, content integrity, anti-replay, and (limited) traffic flow confidentiality. [RFC5775] specifies that the data origin authentication, content integrity, and anti-replay services SHALL be supported, and that the confidentiality service is RECOMMENDED. If a short-lived session MAY rely on manual keying, it is also RECOMMENDED that an automated key management scheme be used, especially in the case of long-lived sessions.
[RFC3365]の意味で、必須ではありませんが必ずしも使用する必要はないセキュリティ構成を紹介します。 FLUTEはALC / LCTに依存しているため、[RFC5775]の「ベースラインセキュアALC操作」を継承します。より正確には、セキュリティはトランスポートモードのIPsec / ESPによって実現されます。 [RFC4303]は、ESPを使用して機密性、データ発信元認証、コンテンツの整合性、リプレイ防止、および（制限された）トラフィックフローの機密性を提供できる可能性があることを説明しています。 [RFC5775]は、データ発信元の認証、コンテンツの整合性、およびリプレイ防止サービスがサポートされる必要があり、機密性サービスが推奨されることを指定します。短期間のセッションが手動のキーイングに依存する場合は、特に長期間のセッションの場合は、自動キー管理スキームを使用することも推奨されます。
Therefore, the RECOMMENDED solution for FLUTE provides per-packet security, with data origin authentication, integrity verification, and anti-replay. This is sufficient to prevent most of the in-band attacks listed above. If confidentiality is required, a per-packet encryption SHOULD also be used.
したがって、FLUTEに推奨されるソリューションは、データ発信元認証、整合性検証、およびリプレイ防止機能を備えたパケット単位のセキュリティを提供します。これは、上記のインバンド攻撃のほとんどを防ぐのに十分です。機密性が必要な場合は、パケットごとの暗号化も使用する必要があります（SHOULD）。
This specification contains five separate items upon which IANA has taken action:
この仕様には、IANAが行動を起こした5つの個別の項目が含まれています。
1. Registration of the FDT Instance XML Namespace.
1. FDTインスタンスXML名前空間の登録。
2. Registration of the FDT Instance XML Schema.
2. FDTインスタンスXMLスキーマの登録。
3. Registration of the application/fdt+xml Media Type.
3. application / fdt + xmlメディアタイプの登録。
4. Registration of the Content Encoding Algorithms.
4. コンテンツエンコーディングアルゴリズムの登録。
5. Registration of two LCT Header Extension Types (EXT_FDT and EXT_CENC).
5. 2つのLCTヘッダー拡張タイプ（EXT_FDTおよびEXT_CENC）の登録。
IANA has registered the following new XML Namespace in the IETF XML "ns" registry [RFC3688] at http://www.iana.org/assignments/xml-registry/ns.html.
IANAは、http：//www.iana.org/assignments/xml-registry/ns.htmlにあるIETF XML "ns"レジストリ[RFC3688]に次の新しいXML名前空間を登録しました。
URI: urn:ietf:params:xml:ns:fdt
Registrant Contact: Toni Paila (toni.paila@gmail.com)
登録者の連絡先：Toni Paila（toni.paila@gmail.com）
XML: N/A
ＸＭＬ： ん／あ
IANA has registered the following in the IETF XML "schema" registry [RFC3688] at http://www.iana.org/assignments/xml-registry/schema.html.
IANAは、http：//www.iana.org/assignments/xml-registry/schema.htmlにあるIETF XML "スキーマ"レジストリ[RFC3688]に以下を登録しています。
URI: urn:ietf:params:xml:schema:fdt
Registrant Contact: Toni Paila (toni.paila@gmail.com)
登録者の連絡先：Toni Paila（toni.paila@gmail.com）
XML: The XML Schema specified in Section 3.4.2
XML：セクション3.4.2で指定されたXMLスキーマ
IANA has registered the following in the "Application Media Types" registry at http://www.iana.org/assignments/media-types/application/.
IANAは、http：//www.iana.org/assignments/media-types/application/の "Application Media Types"レジストリに以下を登録しています。
Type name: application
タイプ名：アプリケーション
Subtype name: fdt+xml
サブタイプ名：fdt + xml
Required parameters: none
必須パラメーター：なし
Optional parameters: charset="utf-8"
オプションのパラメーター：charset = "utf-8"
Encoding considerations: binary (the FLUTE file delivery protocol does not impose any restriction on the objects it carries and in particular on the FDT Instance itself)
エンコーディングに関する考慮事項：バイナリ（FLUTEファイル配信プロトコルは、運ぶオブジェクト、特にFDTインスタンス自体に制限を課しません）
Restrictions on usage: none
使用上の制限：なし
Security considerations: fdt+xml data is passive and does not generally represent a unique or new security threat. However, there is some risk in sharing any kind of data, in that unintentional information may be exposed, and that risk applies to fdt+xml data as well.
セキュリティに関する考慮事項：fdt + xmlデータはパッシブであり、通常、固有または新しいセキュリティの脅威を表すものではありません。ただし、意図しない情報が公開される可能性があり、そのリスクがfdt + xmlデータにも適用されるという点で、あらゆる種類のデータを共有することにはいくつかのリスクがあります。
Interoperability considerations: None
相互運用性に関する考慮事項：なし
Published specification: [RFC6726], especially noting Section 3.4.2. The specified FDT Instance functions as an actual media format of use to the general Internet community, and thus media type registration under the Standards Tree is appropriate to maximize interoperability.
公開された仕様：[RFC6726]、特にセクション3.4.2に注目。指定されたFDTインスタンスは、一般的なインターネットコミュニティで使用される実際のメディア形式として機能するため、標準ツリーでのメディアタイプの登録は、相互運用性を最大化するのに適しています。
Applications that use this media type: file and object delivery applications and protocols (e.g., FLUTE).
このメディアタイプを使用するアプリケーション：ファイルとオブジェクトの配信アプリケーションとプロトコル（FLUTEなど）。
Additional information:
追加情報：
Magic number(s): none
File extension(s): ".fdt" (e.g., if there is a need to store an
FDT Instance as a file)
Macintosh File Type Code(s): none
Person and email address to contact for further information: Toni Paila (toni.paila@gmail.com)
詳細について連絡する人とメールアドレス：Toni Paila（toni.paila@gmail.com）
Intended usage: Common
使用目的：一般
Author/Change controller: IETF
作成者/変更コントローラ：IETF
IANA has created a new registry, "FLUTE Content Encoding Algorithms", with a reference to [RFC6726]; see Section 3.4.3. The registry entries consist of a numeric value from 0 to 255, inclusive, and may be registered using the Specification Required policy [RFC5226].
IANAは、[RFC6726]を参照する新しいレジストリ「FLUTE Content Encoding Algorithms」を作成しました。セクション3.4.3を参照してください。レジストリエントリは0〜255の数値で構成され、Specification Requiredポリシー[RFC5226]を使用して登録できます。
The initial contents of the registry are as follows, with unspecified values available for new registrations:
レジストリの初期内容は次のとおりです。未登録の値は新規登録に使用できます。
+-------+----------------+-----------+
| Value | Algorithm Name | Reference |
+-------+----------------+-----------+
| 0 | null | [RFC6726] |
| 1 | ZLIB | [RFC1950] |
| 2 | DEFLATE | [RFC1951] |
| 3 | GZIP | [RFC1952] |
+-------+----------------+-----------+
IANA has registered two new entries in the "Layered Coding Transport (LCT) Header Extension Types" registry [RFC5651], as follows:
IANAは、「レイヤードコーディングトランスポート（LCT）ヘッダー拡張タイプ」レジストリ[RFC5651]に次の2つの新しいエントリを登録しました。
+--------+----------+-------------------------+
| Number | Name | Reference |
+--------+----------+-------------------------+
| 192 | EXT_FDT | [RFC6726] Section 3.4.1 |
| 193 | EXT_CENC | [RFC6726] Section 3.4.3 |
+--------+----------+-------------------------+
The following persons have contributed to this specification: Brian Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma, Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington, Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica, Francis Dupont, Peter Saint-Andre, Don Gillies, and Barry Leiba. The authors would like to thank all the contributors for their valuable work in reviewing and providing feedback regarding this specification.
次の人物がこの仕様に貢献しました。フランシス・デュポン、ピーター・サンタンドレ、ドン・ギリース、バリー・レイバ。著者は、この仕様に関するレビューとフィードバックを提供する貴重な仕事をしてくれたすべての貢献者に感謝します。
Jani Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: jani.peltotalo@tut.fi
Jani Peltotaloタンペレ工科大学P.O. Box 553（Korkeakoulunkatu 1）タンペレFIN-33101フィンランドメール：jani.peltotalo@tut.fi
Sami Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: sami.peltotalo@tut.fi
サミペルトッロタンペレ工科大学P.O. Box 553（Korkeakoulunkatu 1）タンペレFIN-33101フィンランドメール：sami.peltotalo@tut.fi
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm Sweden EMail: magnus.westerlund@ericsson.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80ストックホルムスウェーデンEメール：magnus.westerlund@ericsson.com
Thorsten Lohmar Ericsson Research (EDD) Ericsson Allee 1 52134 Herzogenrath Germany EMail: thorsten.lohmar@ericsson.com
Thorsten Lohmar Ericsson Research（EDD）Ericsson Allee 1 52134 HerzogenrathドイツEメール：thorsten.lohmar@ericsson.com
Incremented the FLUTE protocol version from 1 to 2, due to concerns about backwards compatibility. For instance, the LCT header changed between RFC 3451 and [RFC5651]. In RFC 3451, the T and R fields of the LCT header indicate the presence of Sender Current Time and Expected Residual Time, respectively. In [RFC5651], these fields MUST be set to zero and MUST be ignored by receivers (instead, the EXT_TIME Header Extensions can convey this information if needed). Thus, [RFC5651] is not backwards compatible with RFC 3451, even though both use LCT version 1. FLUTE version 1 as specified in [RFC3926] MUST use RFC 3451. FLUTE version 2 as specified in this document MUST use [RFC5651]. Therefore, an implementation that relies on [RFC3926] and RFC 3451 will not be backwards compatible with FLUTE as specified in this document.
下位互換性に関する懸念のため、FLUTEプロトコルのバージョンを1から2に上げました。たとえば、LCTヘッダーはRFC 3451と[RFC5651]の間で変更されました。 RFC 3451では、LCTヘッダーのTおよびRフィールドは、それぞれ送信者の現在時刻と予想される残り時間の存在を示します。 [RFC5651]では、これらのフィールドはゼロに設定されなければならず（MUST）、レシーバーによって無視されなければなりません（代わりに、EXT_TIMEヘッダー拡張は必要に応じてこの情報を伝えることができます）。したがって、どちらもLCTバージョン1を使用していても、[RFC5651]はRFC 3451と下位互換性がありません。[RFC3926]で指定されているFLUTEバージョン1はRFC 3451を使用する必要があります。したがって、[RFC3926]とRFC 3451に依存する実装は、このドキュメントで指定されているFLUTEとの下位互換性がありません。
Updated dependencies to other RFCs to revised versions; e.g., changed ALC reference from RFC 3450 to [RFC5775], changed LCT reference from RFC 3451 to [RFC5651], etc.
他のRFCへの依存関係を改訂版に更新しました。たとえば、ALC参照をRFC 3450から[RFC5775]に変更した、LCT参照をRFC 3451から[RFC5651]に変更した、など。
Added clarification for the use of FLUTE for unicast communications in Section 1.1.4.
セクション1.1.4に、ユニキャスト通信でのFLUTEの使用に関する説明を追加しました。
Clarified how to reliably deliver the FDT in Section 3.3 and the possibility of using out-of-band delivery of FDT information.
セクション3.3でFDTを確実に配信する方法と、FDT情報の帯域外配信を使用する可能性を明確にしました。
Clarified how to address FDT Instance expiration time wraparound with the notion of the NTPv4 "epoch" in Section 3.3.
セクション3.3で、NTPv4の「エポック」の概念を使用してFDTインスタンスの有効期限のラップアラウンドに対処する方法を明確にしました。
Clarified what should be considered erroneous situations in Section 3.4.1 (definition of FDT Instance ID). In particular, a receiver MUST be ready to handle FDT Instance ID wraparounds and missing FDT Instances.
セクション3.4.1（FDTインスタンスIDの定義）で、誤った状況と見なすべきことを明確にしました。特に、レシーバーはFDTインスタンスIDの折り返しと欠落しているFDTインスタンスを処理する準備ができている必要があります。
Updated Section 7.5 to define IPsec/ESP as a mandatory-to-implement security solution.
実装が必須のセキュリティソリューションとしてIPsec / ESPを定義するようにセクション7.5を更新しました。
Removed the 'Statement of Intent' from Section 1. The statement of intent was meant to clarify the "Experimental" status of [RFC3926]. It does not apply to this document.
セクション1から「意図の声明」を削除しました。意図の声明は、[RFC3926]の「実験的」ステータスを明確にすることを目的としています。このドキュメントには適用されません。
Added clarification of "XML-DSIG" near the end of Section 3.
セクション3の終わり近くに「XML-DSIG」の説明を追加。
In Section 3.2, replaced "complete FDT" with text that is more descriptive.
セクション3.2で、「完全なFDT」をより説明的なテキストに置き換えました。
Clarified Figure 1 with regard to "Encoding Symbol(s) for FDT Instance".
「FDTインスタンスのエンコードシンボル」に関して図1を明確にしました。
Clarified the text regarding FDT Instance ID wraparound at the end of Section 3.4.1.
セクション3.4.1の最後にあるFDTインスタンスIDの折り返しに関するテキストを明確にしました。
Clarified "complete FDT" in Section 3.4.2.
セクション3.4.2で「完全なFDT」を明確にしました。
Added semantics for the case where two TOIs refer to the same Content-Location. It is now in line with the way that 3GPP and Digital Video Broadcasting (DVB) standards interpret this case.
2つのTOIが同じContent-Locationを参照する場合のセマンティクスを追加しました。これは、3GPPおよびデジタルビデオブロードキャスト（DVB）標準がこのケースを解釈する方法と一致しています。
In Section 3.4.2, the XML Schema of the FDT Instance was modified per advice from various sources. For example, extension by element was missing but is now supported. Also, the namespace definition was changed to URN format.
セクション3.4.2では、FDTインスタンスのXMLスキーマがさまざまなソースからのアドバイスに従って変更されました。たとえば、要素による拡張がありませんでしたが、現在はサポートされています。また、ネームスペース定義がURN形式に変更されました。
Clarified FDT-schema extensibility at the end of Section 3.4.2.
セクション3.4.2の最後で、FDTスキーマの拡張性を明確にしました。
The CENC value allocation has been added at the end of Section 3.4.3.
CENC値の割り当ては、セクション3.4.3の最後に追加されました。
Section 5 has been modified so that EXT_FTI and the FEC issues were replaced by a reference to the ALC specification [RFC5775].
セクション5が変更され、EXT_FTIおよびFECの問題がALC仕様[RFC5775]への参照に置き換えられました。
Added a clarifying paragraph on the use of the Codepoint field at the end of Section 5.
セクション5の最後に、コードポイントフィールドの使用に関する明確な段落を追加しました。
Reworked Section 8 -- IANA Considerations; it now contains six IANA registration requests:
セクション8の書き直し-IANAに関する考慮事項。現在、6つのIANA登録要求が含まれています。
* Registration of the FDT Instance XML Namespace.
* FDTインスタンスXML名前空間の登録。
* Registration of the FDT Instance XML Schema.
* FDTインスタンスXMLスキーマの登録。
* Registration of the application/fdt+xml Media Type.
* application / fdt + xmlメディアタイプの登録。
* Registration of the Content Encoding Algorithms.
* コンテンツエンコーディングアルゴリズムの登録。
* Registration of two LCT Header Extension Types and corresponding values in the LCT Header Extension Types Registry (192 for EXT_FDT and 193 for EXT_CENC).
* 2つのLCTヘッダー拡張タイプと対応する値をLCTヘッダー拡張タイプレジストリに登録（EXT_FDTの場合は192、EXT_CENCの場合は193）。
Added Section 10 -- Contributors.
セクション10を追加-貢献者。
Revised lists of both Normative and Informative references.
規範的および有益な参照の両方の改訂リスト。
Added a clarification that the receiver should ignore reserved bits of Header Extension type 193 upon reception.
受信時にヘッダー拡張タイプ193の予約ビットを無視する必要があるという説明が追加されました。
Elaborated on what kinds of networks cannot support FLUTE congestion control (Section 1.1.4).
どのようなネットワークがFLUTE輻輳制御をサポートできないかについて詳しく説明しました（セクション1.1.4）。
In Section 3.2, changed "several" (meaning 3-n vs. "couple" = 2) to "multiple" (meaning 2-n).
セクション3.2で、「数個」（3-nと「カップル」の意味= 2）を「複数」（2-nの意味）に変更しました。
Moved the requirement in Section 3.3 (to send FDT more reliably than files) to a bulleted RECOMMENDED requirement, making check-off easier for testers.
セクション3.3の要件（ファイルよりもFDTを確実に送信するため）を箇条書きのRECOMMENDED要件に移動し、テスターによるチェックオフを容易にしました。
In Section 3.3, sharpened the definition that future FDT file instances can "augment" (meaning enhance) rather than "complement" (sometimes meaning negate, which is not allowed) the file parameters.
セクション3.3で、将来のFDTファイルインスタンスがファイルパラメーターを「補完」（場合によっては否定することを意味する）するのではなく「拡張」（強化を意味する）できるという定義を明確にしました。
Elaborated in Sections 3.3 and 4 that FEC Encoding ID = 0 is Compact No-Code FEC, so that the reader doesn't have to search other RFCs to understand these protocol constants used by FLUTE.
セクション3.3と4で詳しく説明したように、FECエンコーディングID = 0はコンパクトなノーコードFECであるため、FLUTEで使用されるこれらのプロトコル定数を理解するために他のRFCを検索する必要はありません。
Required in Section 3.3 that FLUTE receivers SHALL NOT attempt to decode FDTs if they do not understand the FEC Encoding ID.
セクション3.3でFLUTEレシーバーがFECエンコーディングIDを理解していない場合、FDTのデコードを試みてはならないことを必須とします。
Removed the restriction of Section 3.3, in bullet #4, that TOI = 0 for the FDT, to be consistent with Appendix A step 6 and elsewhere. An FDT is signaled by an FDT Instance ID, NOT only by TOI = 0.
箇条書き＃4のセクション3.3の制限を削除しました。FDTのTOI = 0であり、付録Aのステップ6などと整合性があります。 FDTは、TOI = 0だけでなく、FDTインスタンスIDによって通知されます。
Standardized on the term "expiration time", and avoided using the redundant and possibly confusing term "expiry time".
「有効期限」という用語で標準化され、冗長で混乱を招く可能性のある「有効期限」という用語の使用を避けました。
To interwork with experimental FLUTE, stipulated in Section 3.1 that only 1 instantiation of all 3 protocols -- FLUTE, ALC, and LCT -- can be associated with a session (source IP Address, TSI), and mentioned in Section 6 that one may (optionally) derive the FLUTE version from the file delivery session description.
実験的なFLUTEと相互作用するために、3つのプロトコルすべて（FLUTE、ALC、およびLCT）の1つのインスタンス化のみがセッション（ソースIPアドレス、TSI）に関連付けることができるとセクション3.1で規定されており、セクション6で、 （オプション）ファイル配信セッションの説明からFLUTEバージョンを取得します。
Used a software writing tool to lower the reading grade level and simplify Section 3.1.
ソフトウェアの書き込みツールを使用して、リーディンググレードレベルを下げ、セクション3.1を簡略化しました。
[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月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775] Luby、M.、Watson、M。、およびL. Vicisano、「Asynchronous Layered Coding（ALC）Protocol Instantiation」、RFC 5775、2010年4月。
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5651] Luby、M.、Watson、M。、およびL. Vicisano、「Layered Coding Transport（LCT）Building Block」、RFC 5651、2009年10月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052] Watson、M.、Luby、M。、およびL. Vicisano、「Forward Error Correction（FEC）Building Block」、RFC 5052、2007年8月。
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes", RFC 5445, March 2009.
[RFC5445] Watson、M。、「Basic Forward Error Correction（FEC）Schemes」、RFC 5445、2009年3月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」 、RFC 2616、1999年6月。
[XML-Schema-Part-1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[XML-Schema-Part-1] Thompson、H.、Beech、D.、Maloney、M。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、W3C勧告、2004年10月、<http：/ /www.w3.org/TR/xmlschema-1/>。
[XML-Schema-Part-2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-2/>.
[XML-Schema-Part-2] Biron、P。およびA. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、W3C勧告、2004年10月、<http://www.w3.org/TR/xmlschema- 2 />。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、RFC 5226、2008年5月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738] Luby、M。およびV. Goyal、「Wave and Equation Based Rate Control（WEBRC）Building Block」、RFC 3738、2004年4月。
Note: The RFC 3738 reference is to a target document of a lower maturity level. Some caution should be used, since it may be less stable than the present document.
注：RFC 3738の参照は、より低い成熟度レベルのターゲットドキュメントに対するものです。現在のドキュメントよりも安定性が低い可能性があるため、注意が必要です。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004.
[RFC3926] Paila、T.、Luby、M.、Lehtonen、R.、Roca、V。、およびR. Walsh、「FLUTE-File Delivery over Unidirectional Transport」、RFC 3926、2004年10月。
[RFC2357] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357] Mankin、A.、Romanow、A.、Bradner、S。、およびV. Paxson、「IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols」、RFC 2357、1998年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470] Hollenbeck、S.、Rose、M。、およびL. Masinter、「IETFプロトコル内でのExtensible Markup Language（XML）の使用に関するガイドライン」、BCP 70、RFC 3470、2003年1月。
[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、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950] Deutsch、P. and J-L。ゲイリー、「ZLIB圧縮データ形式仕様バージョン3.3」、RFC 1950、1996年5月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC1951] Deutsch、P。、「DEFLATE Compressed Data Format Specification version 1.3」、RFC 1951、1996年5月。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[RFC1952] Deutsch、P。、「GZIPファイル形式仕様バージョン4.3」、RFC 1952、1996年5月。
[IANAheaderfields] IANA, "Message Header Fields", <http://www.iana.org/protocols>.
[IANAheaderfields] IANA、「メッセージヘッダーフィールド」、<http://www.iana.org/protocols>。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、2000年10月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[PAPER.SSM] Holbrook, H., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[PAPER.SSM] Holbrook、H。、「A Channel Model for Multicast」、Ph.D。論文、スタンフォード大学、コンピュータサイエンス学部、スタンフォード、カリフォルニア、2001年8月。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.
[RFC3365] Schiller、J。、「Strong Security Requirements for Internet Engineering Task Force Standard Protocols」、BCP 61、RFC 3365、2002年8月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] Eastlake 3rd、D.、Reagle、J。、およびD. Solo、「（Extensible Markup Language）XML-Signature Syntax and Processing」、RFC 3275、2002年3月。
[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 Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、2003年2月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082] Perrig、A.、Song、D.、Canetti、R.、Tygar、J。、およびB. Briscoe、「Timed Efficient Stream Loss-Tolerant Authentication（TESLA）：Multicast Source Authentication Transform Introduction」、RFC 4082、 2005年6月。
[RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 5776, April 2010.
[RFC5776] Roca、V.、Francillon、A。、およびS. Faurite、「非同期レイヤードコーディング（ALC）およびNACK指向の信頼性のあるマルチキャスト（NORM）プロトコルでの時限効率的なストリーム損失許容認証（TESLA）の使用」 、RFC 5776、2010年4月。
[RFC6584] Roca, V., "Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6584, April 2012.
[RFC6584] Roca、V。、「Asynchronous Layered Coding（ALC）and NACK-Oriented Reliable Multicast（NORM）Protocolsの単純な認証方式」、RFC 6584、2012年4月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「MIKEY：Multimedia Internet KEYing」、RFC 3830、2004年8月。
[MBMSsecurity] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS) (Release 10)", December 2010, <http://www.3gpp.org/ftp/Specs/archive/33_series/33.246/>.
[MBMSsecurity] 3GPP、「3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security of Multimedia Broadcast / Multicast Service（MBMS）（Release 10）」、2010年12月、<http：//www.3gpp。 org / ftp / Specs / archive / 33_series / 33.246 />。
Appendix A. Receiver Operation (Informative)
付録A.レシーバーの動作（参考）
This section gives an example of how the receiver of the file delivery session may operate. Instead of a detailed state-by-state specification, the following should be interpreted as a rough sequence of an envisioned file delivery receiver.
このセクションでは、ファイル配信セッションの受信者がどのように動作するかの例を示します。状態ごとの詳細な仕様の代わりに、以下は想定されるファイル配信レシーバーのおおまかなシーケンスとして解釈されるべきです。
1. The receiver obtains the description of the file delivery session identified by the (source IP address, Transport Session Identifier) pair. The receiver also obtains the destination IP addresses and respective ports associated with the file delivery session.
1. 受信者は、（送信元IPアドレス、トランスポートセッション識別子）ペアで識別されるファイル配信セッションの説明を取得します。受信者は、ファイル配信セッションに関連付けられている宛先IPアドレスとそれぞれのポートも取得します。
2. The receiver joins the channels in order to receive packets associated with the file delivery session. The receiver may schedule this join operation utilizing the timing information contained in a possible description of the file delivery session.
2. 受信者は、ファイル配信セッションに関連するパケットを受信するためにチャネルに参加します。受信者は、ファイル配信セッションの可能な説明に含まれるタイミング情報を利用して、この結合操作をスケジュールすることができます。
3. The receiver receives ALC/LCT packets associated with the file delivery session. The receiver checks that the packets match the declared Transport Session Identifier. If not, the packets are silently discarded.
3. 受信者は、ファイル配信セッションに関連付けられたALC / LCTパケットを受信します。受信者は、パケットが宣言されたトランスポートセッション識別子と一致することを確認します。そうでない場合、パケットは通知なく破棄されます。
4. While receiving, the receiver demultiplexes packets based on their TOI and stores the relevant packet information in an appropriate area for recovery of the corresponding file. Multiple files can be reconstructed concurrently.
4. 受信中、レシーバーはTOIに基づいてパケットを逆多重化し、関連するパケット情報を適切な領域に格納して、対応するファイルを復元します。複数のファイルを同時に再構築できます。
5. The receiver recovers an object. An object can be recovered when an appropriate set of packets containing Encoding Symbols for the transmission object has been received. An appropriate set of packets is dependent on the properties of the FEC Encoding ID and FEC Instance ID, and on other information contained in the FEC Object Transmission Information.
5. 受信者はオブジェクトを回復します。送信オブジェクトのエンコードシンボルを含むパケットの適切なセットを受信すると、オブジェクトを回復できます。パケットの適切なセットは、FECエンコーディングIDとFECインスタンスIDのプロパティ、およびFECオブジェクト転送情報に含まれる他の情報に依存します。
6. Objects with TOI = 0 are reserved for FDT Instances. All FDT Instances are signaled by including an EXT_FDT Header Extension in the LCT header. The EXT_FDT header contains an FDT Instance ID (i.e., an FDT version number). If the object has an FDT Instance ID 'N', the receiver parses the payload of the instance 'N' of the FDT and updates its FDT database accordingly.
6. TOI = 0のオブジェクトは、FDTインスタンス用に予約されています。すべてのFDTインスタンスは、LCTヘッダーにEXT_FDTヘッダー拡張を含めることによって通知されます。 EXT_FDTヘッダーには、FDTインスタンスID（つまり、FDTバージョン番号）が含まれています。オブジェクトにFDTインスタンスID「N」がある場合、レシーバーはFDTのインスタンス「N」のペイロードを解析し、それに応じてFDTデータベースを更新します。
7. If the object recovered is not an FDT Instance but a file, the receiver looks up its FDT database to get the properties described in the database, and assigns the file the given properties. The receiver also checks that the received content length matches with the description in the database. Optionally, if an MD5 checksum has been used, the receiver checks that the calculated MD5 matches the description in the FDT database.
7.復元されたオブジェクトがFDTインスタンスではなくファイルの場合、受信者はFDTデータベースを検索して、データベースに記述されているプロパティを取得し、ファイルに特定のプロパティを割り当てます。受信者は、受信したコンテンツの長さがデータベース内の説明と一致することも確認します。オプションで、MD5チェックサムが使用されている場合、レシーバーは、計算されたMD5がFDTデータベースの記述と一致することを確認します。
8. The actions the receiver takes with imperfectly received files (missing data, mismatching content integrity digest, etc.) are outside the scope of this specification. When a file is recovered before the associated file description entry is available, a possible behavior is to wait until an FDT Instance is received that includes the missing properties.
8. 不完全に受信されたファイルに対して受信者が実行するアクション（データの欠落、コンテンツ整合性ダイジェストの不一致など）は、この仕様の範囲外です。関連するファイル記述エントリが利用可能になる前にファイルが回復されると、可能な動作は、不足しているプロパティを含むFDTインスタンスが受信されるまで待機することです。
9. If the file delivery session end time has not been reached, go back to step 3. Otherwise, end.
9. ファイル配信セッションの終了時刻に達していない場合は、手順3に戻ります。それ以外の場合は終了します。
Appendix B. Example of FDT Instance (Informative)
付録B. FDTインスタンスの例（参考）
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:fdt
ietf-flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>
Authors' Addresses
著者のアドレス
Toni Paila Nokia Itamerenkatu 11-13 Helsinki 00180 Finland
とに ぱいぁ のきあ いためれんかつ １１ー１３ へｌしんき ００１８０ ふぃんぁんｄ
EMail: toni.paila@gmail.com
Rod Walsh Nokia/Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FI-33101 Finland
ロッドウォルシュノキア/タンペレ工科大学P.O. Box 553（Korkeakoulunkatu 1）タンペレFI-33101フィンランド
EMail: roderick.walsh@tut.fi
Michael Luby Qualcomm Technologies, Inc. 2030 Addison Street, Suite 420 Berkeley, CA 94704 USA
Michael Luby Qualcomm Technologies、Inc. 2030 Addison Street、Suite 420 Berkeley、CA 94704 USA
EMail: luby@qti.qualcomm.com
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
ヴィンセントロカINRIA 655、av。イノヴァリーヨーロッパの; Montbonnot ST ISMIER cedex 38334フランス
EMail: vincent.roca@inria.fr
Rami Lehtonen TeliaSonera Hatanpaankatu 1 Tampere FIN-33100 Finland
Rami Lehtonen TeliaSonera Hatanpaankatu 1 Tampere FIN-33100フィンランド
EMail: rami.lehtonen@teliasonera.com