Network Working Group T. Paila
Request for Comments: 3926 Nokia
Category: Experimental M. Luby
Digital Fountain
R. Lehtonen
TeliaSonera
V. Roca
INRIA Rhone-Alpes
R. Walsh
Nokia
October 2004
FLUTE - File Delivery over Unidirectional Transport
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document defines 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.
この文書では、FLUTE、マルチキャストネットワークに特に適しているインターネット上でのファイルの一方向の送達のためのプロトコルを定義します。仕様は、非同期階層符号化、大規模スケーラブルマルチキャスト配信のために設計された基本プロトコルの上に構築します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Statement . . . . . . . . . . . . . . . . 3
1.1.1. The Target Application Space . . . . . . . . . . 3
1.1.2. The Target Scale . . . . . . . . . . . . . . . . 4
1.1.3. Intended Environments . . . . . . . . . . . . . 4
1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this Document. . . . . . . . . . . . . . . 5
3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. File delivery session . . . . . . . . . . . . . . . . . 6
3.2. File Delivery Table. . . . . . . . . . . . . . . . . . . 8
3.3. Dynamics of FDT Instances within file delivery session . 9
3.4. Structure of FDT Instance packets. . . . . . . . . . . . 11
3.4.1. Format of FDT Instance Header . . . . . . . . . 12
3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . 13
3.4.3. Content Encoding of FDT Instance . . . . . . . . 16
3.5. Multiplexing of files within a file delivery session . . 17
4. Channels, congestion control and timing . . . . . . . . . . . 18
5. Delivering FEC Object Transmission Information . . . . . . . . 19
5.1. Use of EXT_FTI for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. General EXT_FTI format . . . . . . . . . . . . . 20
5.1.2. FEC Encoding ID specific formats for EXT_FTI . . 21
5.2. Use of FDT for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 25
6. Describing file delivery sessions. . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
Normative References . . . . . . . . . . . . . . . . . . . . . 29
Informative References . . . . . . . . . . . . . . . . . . . . 30
A. Receiver operation (informative) . . . . . . . . . . . . . . . 32
B. Example of FDT Instance (informative). . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 35
This document defines FLUTE version 1, a protocol for unidirectional delivery of files over the Internet. The specification builds on Asynchronous Layered Coding (ALC), version 1 [2], 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バージョン1、インターネット上でのファイルの一方向の配信のためのプロトコルを定義します。仕様は、（ALC）をコード非同期階層にバージョン1 [2]、大規模スケーラブルマルチキャスト配信のために設計された基本プロトコルを構築します。 ALCは、任意のバイナリオブジェクトのトランスポートを定義します。ファイル配信アプリケーションのためのオブジェクトの単なる輸送は、しかし、十分ではありません。エンドシステムは、オブジェクトが実際に何を表すかを知る必要があります。シグナリングと受信機が受信オブジェクトに対して、これらのパラメータを割り当てることができますように、ALCのコンセプトにファイルのプロパティをマッピングするためのメカニズム - このドキュメントは、FLUTEと呼ばれる技術を指定します。 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 signalling of the transport parameters of the ALC session.
- ALCセッションのトランスポートパラメータのインバンドシグナリング。
- In-band signalling 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 that forms the core part of this specification. Further, it discusses multiplexing issues of transport 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. The first appendix describes an envisioned receiver operation for the receiver of the file delivery session. The second appendix gives an example of File Delivery Table.
次のようにこの仕様は構成されています。第3節では、ファイル配信セッションの概念を定義することによって開始されます。それはこの仕様のコア部分を構成するファイル配信表を紹介することを次に示します。さらに、それは、ファイル配信セッション内のトランスポート・オブジェクトの多重化の問題について説明します。第4章では、輻輳制御とFLUTEのチャネルの使用を記載しています。第5節では、前方誤り訂正（FEC）オブジェクトの送信情報は、ファイル配信セッション内で配信される方法を定義します。セクション6は、一般的な場合に、ファイル配信セッションを記述するために必要なパラメータを定義します。第7節は、FLUTEとファイル配信に関するセキュリティ上の考慮事項の概要を説明します。最後に、2つの有益な付録があります。最初の付録では、ファイル配信セッションの受信のために想定受信動作を説明します。第二付録では、ファイル配信表の例を示します。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC2357. As per RFC2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモは、完全にRFC2357に従った信頼性の高いマルチキャストトランスポートプロトコルを指定するために必要な定義の一部が含まれています。 RFC2357に従って、インターネットの任意の信頼できるマルチキャストプロトコルの使用は、適切な輻輳制御方式を必要とします。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
このようなスキームを待っているが利用できるようにする、または既存のスキームのための十分な証明することが、信頼性の高いマルチキャスト交通ワーキンググループ（RMT）は「実験」カテゴリ内のコメントのためにこの要求を発行しています。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
すぐに上記の条件が満たされたとしてIETFのProposed Standardとして、この明細書を再提出するRMTの意図です。
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 SDP [12] files which enable user applications to access multimedia sessions.
FLUTEは、数秒以上の配信セッションを使用して、多くのホストに大小のファイルの配信に適用されます。例えば、FLUTEは、同時に多くのホストに大規模なソフトウェアアップデートの配信のために使用することができます。潜在的にネットワークの輻輳状況にセッションの豊かさをスケーリングするALC及びLCTからその積層継承を活用する - それはまた、字幕の時間ライニングテキストとして、連続的な、しかし、セグメント化されたデータを使用することができます。それは、また、マルチメディアセッションにアクセスするためのユーザー・アプリケーションを可能にする例えばSDP [12]ファイルのメタデータの基本的な輸送に適しています。
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 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 ALC building block [2] and to any additional building blocks that FLUTE uses also apply to FLUTE.
ALCビルディングブロックに適用される環境要件と考慮事項の全ての[2]とFLUTEもFLUTEに適用されます使用する任意の追加のビルディングブロックへ。
FLUTE can be used with both multicast and unicast delivery, but it's 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. FLUTE inherently works with all 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 or IPv6 as no part of the packet is IP version specific. FLUTE works with both multicast models: Any-Source Multicast (ASM) [13] and the Source-Specific Multicast (SSM) [15].
パケットのどの部分が、特定のIPバージョンではないとしてFLUTEは、IPv4またはIPv6の両方に対応しています。任意-ソースマルチキャスト（ASM）[13]とソース固有マルチキャスト（SSM）[15]：FLUTEは、両方のマルチキャストモデルで動作します。
FLUTE is applicable for both Internet use, with a suitable congestion control building block, and provisioned/controlled systems, such as delivery over wireless broadcast radio systems.
FLUTEは、適切な輻輳制御ビルディングブロックと、インターネット利用の両方に適用可能であり、そのような無線放送ラジオシステム上の配信としてプロビジョニング/制御システム。
Some networks are not amenable to some congestion control protocols that could be used with FLUTE. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session.
ネットワークによっては、FLUTEで使用することができ、いくつかの輻輳制御プロトコルに従順ではありません。具体的には、衛星または無線ネットワークのために、セッションに割り当てられた一定の伝送速度が存在し得るので、効果的に受信レートを低減するための受信機のためのメカニズムが存在しない場合があります。
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 RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
The terms "object" and "transport object" are consistent with the definitions in ALC [2] and LCT [3]. The terms "file" and "source object" are pseudonyms for "object".
用語「対象」および「トランスポート・オブジェクトは、」ALC [2]とLCTの定義と一致している[3]。用語「ファイル」と「ソースオブジェクトは、」「オブジェクト」のための仮名です。
Asynchronous Layered Coding [2] 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.
非同期階層コーディング[2]任意のバイナリオブジェクトの送達のために設計されたプロトコルです。これは、大規模スケーラブル、単方向、マルチキャスト配信に特に適しています。 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. This identifier may be globally unique. The identifier may also provide a location for the file. In the above example: "http://www.example.com/docs/ file.txt".
*ファイルの識別子は、URIとして表さ。この識別子は、グローバルに一意であることがあります。識別子は、ファイルの場所を提供することができます。上記の例では：「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 MIME media type (usually, this can also be concluded from the extension of the file name). In the above example: "text/plain". If an explicit value for the MIME type is provided separately from the file extension and does not match the MIME type of the file extension then the explicitly provided value MUST be used as the MIME type.
*ファイルタイプ、MIMEメディアタイプ（通常、これはファイル名の拡張子からもを締結することができます）のように表します。 "text / plainの"：上記の例では。 MIMEタイプの明示的な値は、ファイル拡張子とは別に設けられており、次いで、明示的に指定値はMIMEタイプとして使用されなければならないファイル拡張子のMIMEタイプと一致しない場合。
* File size, expressed in bytes. 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 [10]. In this case the size of the transport object carrying the file would probably differ from the file size. The transport object size is delivered to receivers as part of the FLUTE protocol.
*輸送中のファイルの内容のエンコーディング、。上記の例では、ファイルは、ZLIB [10]を使用して符号化することができます。この場合、ファイルを運ぶトランスポート・オブジェクトのサイズは、おそらく、ファイルサイズは異なります。トランスポート・オブジェクトのサイズはFLUTEプロトコルの一部として受信機に配信されます。
* Security properties of the file such as digital signatures, message digests, etc. For example, one could use S/MIME [18] as the content encoding type for files with this authentication wrapper, and one could use XML-DSIG [19] to digitally sign an FDT Instance.
*など、デジタル署名、メッセージダイジェストなどのファイルのセキュリティ特性、例えば、一つは使用することができ、S / MIME [18]この認証ラッパーを持つファイルのコンテンツ符号化タイプとして、1つはXML-DSIG [19]を使用することができデジタルFDTインスタンスを署名します。
ALC is a protocol instantiation of Layered Coding Transport building block (LCT) [3]. Thus ALC inherits the session concept of LCT. In this document we will use the concept ALC/LCT session to collectively denote the interchangeable terms ALC session and LCT session.
ALCは、階層符号化移送ビルディングブロック（LCT）のプロトコルのインスタンス[3]です。したがって、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 packets with ALC/LCT headers 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). The TSI is scoped by the source IP address, and the (source IP address, TSI) pair uniquely identifies a session, i.e., the receiver uses this pair carried in each packet to uniquely identify from which session the packet was received. In case multiple objects are carried within a session, the Transport Object Identifier (TOI) field within the ALC/LCT header identifies from which object the data in the packet was generated. Note that each object is associated with a unique TOI within the scope of a session.
ALC / LCTヘッダで運ばれたフィールドの一つは、トランスポートセッション識別子（TSI）です。 TSIは、送信元IPアドレス、及び（送信元IPアドレス、TSI）対によってスコープれる一意すなわち、受信機を一意にパケットを受信したセッションから識別するために、各パケットで運ばれ、このペアを使用して、セッションを識別する。場合に複数のオブジェクトがセッション内で実行される、ALC / LCTヘッダ内のトランスポート・オブジェクト識別子（TOI）フィールドは、パケット内のデータが生成されたどのオブジェクトから識別する。各オブジェクトは、セッションの範囲内で一意TOIに関連付けられていることに留意されたいです。
If the sender is not assigned a permanent IP address accessible to receivers, but instead, packets that can be received by receivers containing a temporary IP address for packets sent by the sender, then the TSI is scoped by this temporary 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 that is accessible to receivers, and in this case the TSI is scoped by the temporary IP address assigned by the NAT that will appear in packets received by the receiver. As another example, the sender may send its original packets using IPv6, but some portions of the network may not be IPv6 capable and 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 a permanent IP address or a temporary IP address, is outside the scope of this document.
送信者によって送信されたパケットのための一時的なIPアドレスを含む受信機によって送信者が受信者にアクセス可能な恒久的なIPアドレスが割り当てられていないが、その代わりに、パケットを受信することができる場合には、TSIは、送信者のこの一時的なIPアドレスのためによりスコープされセッションの期間。一例として、送信者が一時的に受信機にアクセス可能である送信者のIPアドレスを割り当てるネットワークアドレス変換（NAT）デバイスの背後にあってもよく、この場合、TSIは、NATによって割り当てられた一時的なIPアドレスによってスコープされます受信機が受信したパケットに表示されます。別の例として、送信者がIPv6を使用して元のパケットを送信してもよいが、ネットワークのいくつかの部分は、IPv6対応でなくてもよく、したがって、異なるIPv4アドレスへのパケットのIPアドレスを変更したIPv6のIPv4に翻訳が存在してもよいです。この場合、ネットワークのIPv4の部分における受信機は、IPv4アドレスを含むパケットを受信することになるので、それらのためのTSIは、IPv4アドレスによってスコープされます。どのように受信機によってスコープにセッションを使用する送信元のIPアドレスは、それが永久的なIPアドレスまたは一時的なIPアドレスであるかどうかを、受信機に配信され、このドキュメントの範囲外です。
When FLUTE is used for file delivery over ALC the following rules apply:
FLUTEは、ALCを超えるファイル配信のために使用されている場合は、次の規則が適用されます。
* The ALC/LCT session is called file delivery session.
* ALC / LCTセッションは、ファイル配信セッションと呼ばれています。
* The ALC/LCT concept of 'object' denotes either a 'file' or a 'File Delivery Table Instance' (section 3.2)
*「オブジェクト」のALC / LCTのコンセプトは「ファイル」または「ファイル配信表インスタンス」（セクション3.2）のいずれかを表し、
* 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 RFC 3451 [3] for the LCT definition of the Close Session flag, and see Section 4.2 of RFC 3450 [2] for an example of its use within an ALC packet.
* TOIフィールドはALC（セッションの終了をシグナリング）を1に設定閉じるセッション（A）フラグとFLUTEセッションにおいて送信されたパケットとそれがない含まれていることを除いて、FLUTEセッション内で送信されたALCパケット内に含まれなければなりませんペイロード（任意のファイルまたはFDTのための情報を運ぶんが）TOIを運ぶないものとします。 [3]閉じるセッションフラグのLCT定義、及び[2] ALCパケット内のその使用例については、RFC 3450のセクション4.2を参照RFC 3451のセクション5.1を参照。
* The TOI value '0' is reserved for delivery of File Delivery Table Instances. Each File Delivery Table Instance is uniquely identified by an FDT Instance ID.
* TOI値は「0」ファイル配信表インスタンスの配信のために予約されています。各ファイル配信表インスタンスを一意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によってスコープされ、さらに、TOIとFDTインスタンスオブジェクトのための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 nor exhaustive.
ファイル配信テーブル（FDT）は、ファイル配信セッション内で配信されるファイルに関連する様々な属性を記述するための手段を提供します。以下のリストは、そのような属性の例であり、相互に排他的でも網羅するものではありません。
Attributes related to the delivery of 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符号化IDと、該当する場合、FECインスタンスIDを含む）FECオブジェクト伝送情報
- Size of the transport 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で指定されました）
- MIME media type of file
- ファイルのMIMEメディアタイプ
- 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 is included in each ALC/LCT data packet during the delivery of the file, and thus the TOI carried in the file description entry is how the receiver determines which ALC/LCT data packets contain information about which file. Each file description entry may also contain one or more descriptors that map the above-mentioned attributes to the file.
論理的には、FDTはセッションで配信されるファイルのファイル記述エントリのセットです。各ファイル記述は、説明及びURIがファイルを識別するファイルのTOIを含まなければなりません。 TOIは、ファイルの配信中に各ALC / LCTデータパケットに含まれているので、ファイル記述エントリで運ばTOIは、受信機がALC / LCTデータパケットは、ファイルに関する情報を含むかを決定する方法です。各ファイル記述エントリは、ファイルに上記の属性をマップする一の以上の記述子を含んでいてもよいです。
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, is not considered a 'file' belonging to the file delivery session. Handling of these unmapped TOIs (TOIs that are not resolved by the FDT) is out of scope of this specification.
各ファイル配信セッションは、特定のセッションにローカルであるFDTを持たなければなりません。 FDTは、セッション内に現れる各ファイルのTOIにマッピングされたファイル記述を提供しなければなりません。 ALCセッション内で配信が、FDTに記述されていないオブジェクトは、ファイル配信セッションに属する「ファイル」とみなされていません。これらのマッピングされていないTOIS（FDTによって解決されていないTOIS）の取り扱いについては、この仕様の範囲外です。
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, a subset of, a superset of, or complement any other FDT Instance. A certain FDT Instance may be repeated several 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 complete FDT of the file delivery session.
ファイル配信セッション内でFDTは、FDTインスタンスとして配信されます。 FDTインスタンスは、FDTの1つまたは複数のファイル記述エントリが含まれています。任意のFDTインスタンスのスーパーセットのサブセットに等しいこと、または他の任意のFDTインスタンスを補完することができます。特定のFDTインスタンスは、（より高いFDTインスタンスID番号を持つ）後続のFDTインスタンスは、送信された後も、セッション中に複数回繰り返してもよいです。各FDTインスタンスは、少なくとも一つのファイル記述と完全なFDTファイル配信セッションのほとんどに含まれています。
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 FDT database is an abstract concept, the structure and the maintaining 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.
*ファイル配信セッション内で配信ファイルごとにセッション内で送信された少なくとも一つの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 for FDT Instances is outside the scope of this specification.
*「0」のTOI値は、FDTインスタンスの送達のために確保されなければなりません。 FDTインスタンスの他のTOI値の使用は、本明細書の範囲外です。
* FDT Instance is identified by the use of a new fixed length LCT Header Extension EXT_FDT (defined later in this section). Each FDT Instance is uniquely identified within the file delivery session by its FDT Instance ID. Any ALC/LCT packet carrying FDT Instance (indicated by TOI = 0) MUST include EXT_FDT.
* FDTインスタンスは、新しい固定長LCTヘッダ拡張EXT_FDT（このセクションで定義される）の使用によって識別されます。各FDTインスタンスは一意にFDTインスタンスIDによって、ファイル配信セッション内で識別されます。 FDTインスタンス（TOI = 0で示される）を有する任意のALC / LCTパケットEXT_FDTを含まなければなりません。
* It is RECOMMENDED that FDT Instance that contains the file description entry for a file is sent prior to the sending of the described file within a file delivery session.
*ファイルのファイル記述エントリが含まれているFDTインスタンスは、前のファイル配信セッション内で記述されたファイルの送信に送信することをお勧めします。
* Within a file delivery session, any TOI > 0 MAY be described more than once. An example: previous FDT Instance 0 describes TOI of value '3'. Now, subsequent FDT Instances can either keep TOI '3' unmodified on the table, not include it, or complement the description. However, subsequent FDT Instances MUST NOT change the parameters already described for a specific TOI.
*ファイル配信セッションの中で、どのTOI> 0を複数回記述することができます。例：以前のFDTインスタンス0は、値のTOIを記述する「3」。さて、その後のFDTインスタンスは、テーブルの上にそのままTOI「3」を維持し、ないことを含め、または説明を補完することができます。しかし、その後のFDTインスタンスは、すでに特定のTOIのために説明されているパラメータを変更してはなりません。
* An FDT Instance is valid until its expiration time. The expiration time is expressed within the FDT Instance payload as a 32 bit data field. The value of the data field represents the 32 most significant bits of a 64 bit Network Time Protocol (NTP) [5] time value. These 32 bits provide an unsigned integer representing the time in seconds relative to 0 hours 1 January 1900. Handling of wraparound of the 32 bit time is outside the scope of NTP and FLUTE.
* FDTインスタンスは、その有効期限まで有効です。有効期限は、32ビット・データ・フィールドとしてFDTインスタンスのペイロード内で発現されます。データフィールドの値は、64ビットのネットワークタイムプロトコル（NTP）の32の最上位ビット[5]の時間値を表します。これらの32ビットは0時間に対して秒数を表す符号無し整数を提供する32ビット時間のラップアラウンドの1月1日1900取り扱いNTP及びFLUTEの範囲外です。
* The receiver SHOULD NOT use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance.
*受信機は、FDTインスタンスの有効期限を超えて受信したパケットを解釈するために、受信したFDTインスタンスを使用しないでください。
* A sender MUST use an expiry 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 FEC Encoding ID 0 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インスタンスの送信のためFEC符号化ID 0を使用することです。 （FEC符号化ID 0は、FLUTEのデフォルトであるので、これはソースブロック番号および符号化シンボルIDが16ビットずつの両方デフォルト長ことを意味することに注意してください。）
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. Thus, it is RECOMMENDED that FDT Instances describing a file be sent with at least as much reliability within a session (more often or with more FEC protection) as the files they describe. In particular, if FDT Instances are longer than one packet payload in length it is RECOMMENDED that an FEC code that provides protection against loss be used for delivering FDT Instances. How often the description of a file is sent in an FDT
一般的に、受信機は、ファイル自体を回復することができる前に、ファイルを記述するFDTインスタンスを受信する必要があります。この意味ではFDTインスタンスは、ファイルよりも高い優先度です。このように、彼らが記述するファイルとしてファイルを記述したFDTインスタンスは、セッション内（より頻繁以上のFEC保護で）少なくとも同じくらいの信頼性を備えて送信することが推奨されます。 FDTインスタンスは、長さが1つのパケットのペイロードよりも長い場合は特に、損失に対する保護を提供するFECコードは、FDTインスタンスを送達するために使用することを推奨しています。どのくらいの頻度でファイルの記述は、FDTに送信されます
Instance or how much FEC protection is provided for each FDT Instance (if the FDT Instance is longer than one packet payload) is dependent on the particular application and outside the scope of this document.
（FDTインスタンスが長い1つのパケットのペイロードを超える場合）FEC保護は各FDTインスタンスのために提供されているどのくらいのインスタンスまたは特定のアプリケーションにこの文書の範囲外に依存しています。
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. The FDT Instance Header is placed in the same way as any other LCT extension header. There MAY be other LCT extension headers in use.
FDTインスタンスはTOI = 0とし、必要な追加LCTヘッダ拡張でALCパケットで運ばれるFDTインスタンスヘッダと呼ばれます。 FDTインスタンスヘッダ（EXT_FDT）が一意にファイル配信セッション内のFDTインスタンスを識別するFDTインスタンスIDを含んでいます。 FDTインスタンスヘッダは、他LCT拡張ヘッダと同じように配置されています。使用中の他のLCT拡張ヘッダがある可能性があります。
The LCT extension headers are followed by the FEC Payload ID, and finally the Encoding Symbols for the FDT Instance which contains one or more file description entries. A 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.
LCTの拡張ヘッダは、FECペイロードIDが続く、とされている最終的には1つ以上のファイル記述エントリが含まれているFDTインスタンスのための符号化シンボル。 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 the Figure 1 below. All integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. As defined in [2], all ALC/LCT packets are sent using UDP.
FDTインスタンスを運ぶALC / LCTパケットの全体的なフォーマットは、以下の図1に示されています。すべての整数フィールドは、最上位バイト（オクテット）最初、つまり、「ビッグエンディアン」または「ネットワーク順」形式で行われています。で定義されている[2]、すべてのALC / LCTパケットは、UDPを使用して送信されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) for FDT Instance |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall FDT Packet
図1 - 総合FDTパケット
FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific LCT header extension [3]. The Header Extension Type (HET) for the extension is 192. Its format is defined below:
FDTインスタンスヘッダ（EXT_FDT）はALC PI特定LCTヘッダ拡張、新しい固定長である[3]。拡張のヘッダ拡張タイプ（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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version of FLUTE (V), 4 bits:
FLUTE（V）、4ビットのバージョン：
This document specifies FLUTE version 1. Hence in any ALC packet that carries FDT Instance and that belongs to the file delivery session as specified in this specification MUST set this field to '1'.
この文書では、このフィールドを設定しなければなりません「1」FDTインスタンスを運び、この仕様書で指定されているが、ファイル配信セッションに属しているすべてのALCパケットにしたがってFLUTEバージョン1を指定します。
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 again from '0'. When wraparound from 2^20-1 to 0 occurs, 0 is considered higher than 2^20-1. A new FDT Instance reusing a previous FDT Instance ID number, due to wraparound, may not implicitly expire the previous FDT Instance with the same ID. It would be reasonable for
各ファイル配信セッションのためのFDTインスタンスの番号は「0」から開始し、後続の各FDTインスタンスの1だけインクリメントされます。最大値（2 ^ 20-1）に到達した後に、番号が「0」から再び始まります。 0に2 ^ 20-1からラップアラウンドするとき0、発生した2 ^ 20-1よりも高いと考えられます。ラップアラウンドのために、以前のFDTインスタンスID番号を、再利用する新しいFDTインスタンス、暗黙的に同じIDで以前のFDTインスタンスの有効期限が切れていないことがあります。それはのための合理的です
FLUTE Senders to only construct and deliver FDT Instances with wraparound IDs after the previous FDT Instance using the same ID has expired. However, mandatory receiver behavior for handling FDT Instance ID wraparound and other special situations (for example, missing FDT Instance IDs resulting in larger increments than one) is outside the scope of this specification and left to individual implementations of FLUTE.
FLUTE送信者のみ構築し、同じIDを使用して、以前のFDTインスタンスの有効期限が切れた後にラップアラウンドのIDでFDTインスタンスを提供します。しかしながら、（例えば、1より大きい増分で得られたFDTインスタンスIDが欠落）FDTインスタンスIDの回り込みやその他の特殊な状況を処理するための必須の受信機の動作は、本明細書の範囲外であるとFLUTEの個々の実装に任さ。
The FDT Instance contains file description entries that provide the mapping functionality described in 3.2 above.
FDTインスタンスは、上記3.2に記載されたマッピング機能を提供するファイル記述エントリを含んでいます。
The FDT Instance is an XML structure that has a single root element "FDT-Instance". The "FDT-Instance" element MUST contain "Expires" attribute, which tells the expiry time of the FDT Instance. In addition, the "FDT-Instance" element MAY contain the "Complete" attribute (boolean), which, when TRUE, signals 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 identical file parameters to those already given in this and previous FDT Instances). For example, this may be used to provide a complete list of files in an entire FLUTE session (a "complete FDT").
FDTインスタンスは、単一のルート要素「FDTインスタンス」を有するXML構造です。 「FDTインスタンス」要素は、FDTインスタンスの有効期限を伝える属性を、「有効期限」が含まれなければなりません。また、「FDTインスタンス」要素が高いとのどちらかFDTインスタンスという、全く新しいデータはこのセッション内で将来のFDTインスタンスに設けられていないされる、ときTRUE、信号（すなわち、属性（boolean）を「完了」を含むかもしれID番号が使用されることはありませんか、それらが使用されている場合のみ、既にこのおよび以前のFDTインスタンス）で与えられたものと同一のファイルのパラメータを提供します。たとえば、これは全体のFLUTEセッション（「完全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インスタンス」要素は、FDTインスタンスのすべてのファイルのための共通のパラメータを与える属性を含むかもしれません。これらの属性は、「ファイル」要素内の個々のファイルのために提供することができます。同じ属性が「FDTインスタンス」および「ファイル」要素の両方に表示されている場合、「ファイル」要素で提供属性の値が優先されます。
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 "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 MIME field name and the XML attribute value corresponds to the value of the MIME field body. 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 above. "Content-Location" MUST be assigned a valid URI as defined in [6].
XML構造内の「ファイル」要素の属性は、ファイル配信セッションに配信されたファイルに指定された属性を表します。 XMLの値は名前がMIMEのフィールド名に対応しており、XMLの属性値がMIMEフィールド本体の値に対応する属性。それぞれの「ファイル」要素は、「TOI」と「コンテンツ・場所」とは、少なくとも2つの属性を含まなければなりません。上記セクション3.3に記載されているように、「TOI」有効TOI値を割り当てなければなりません。 [6]で定義されるように、「コンテンツロケーション」は、有効なURIを割り当てなければなりません。
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インスタンス」要素と「ファイル」要素には、以下が具体的に指摘されているの他の属性を含むかもしれません。
* Where the MIME type is described, the attribute "Content-Type" MUST be used for the purpose as defined in [6].
MIMEタイプが記載されている場合、[6]で定義されるよう*、属性「コンテンツタイプ」は、目的のために使用されなければなりません。
* Where the length is described, the attribute "Content-Length" MUST be used for the purpose as defined in [6]. The transfer length is defined to be the length of the object transported in bytes. 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 bytes 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.
長さが記載されている場合、[6]で定義されるよう*、属性「コンテンツ長」とは、目的のために使用されなければなりません。転送長はバイト単位で被搬送物の長さであると定義されます。ブロック構造は、ファイルのソースブロックを回復するために適用されるFECデコーダ、および転送長のために知られている必要があるソースがしばしば適切ソースブロックの構造を決定するために必要とされるので、受信機に転送長を伝えるためにしばしば重要ですファイルの。コンテンツのエンコーディングを輸送する前に、ファイルに適用されるので、「コンテンツ・エンコード」属性が使用されている場合、一般的に、元のファイルの長さと転送長さの違いがあります。ファイルがないコンテンツ輸送前に符号化される（したがって、「コンテンツ・エンコーディング」属性が使用されていない）場合、転送長は、元のファイルの長さであり、この場合には、「コンテンツ長」はまた、転送長であります。ファイルがコンテンツ輸送前に符号化される（したがって、「コンテンツ・エンコーディング」属性が使用されている）場合に圧縮を転送する必要があるバイト数を減らすために輸送の前に適用される場合には、例えば、次に転送長は、一般に元のファイルの長さとは異なる、この場合には属性「転送長は、」転送長を運ぶために使用されるかもしれません。
* Where the content encoding scheme is described, the attribute "Content-Encoding" MUST be used for the purpose as defined in [6].
コンテンツの符号化方式が記載されている場合、[6]で定義されるよう*、属性「コンテンツエンコード」は目的のために使用されなければなりません。
* Where the MD5 message digest is described, the attribute "Content-MD5" MUST be used for the purpose as defined in [6].
MD5メッセージダイジェストが記載されている場合、[6]で定義されるよう*、属性の「Content-MD5」は、目的のために使用されなければなりません。
* The FEC Object Transmission Information attributes as described in section 5.2.
5.2節で説明したように* FECオブジェクト伝送情報は、属性。
The following specifies the XML Schema [8][9] for FDT Instance:
以下は、FDTインスタンスの[9] [8] XMLスキーマを指定します。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:fl="http://www.example.com/flute" elementFormDefault:xs="qualified" targetNamespace:xs="http://www.example.com/flute"> <xs:element name="FDT-Instance"> <xs:complexType> <xs:sequence>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのxmlns：XSの= "http://www.w3.org/2001/XMLSchema" のxmlns：FL = "のhttp：// WWW .example.comと/フルート」のelementFormDefault：XS = "資格" のtargetNamespace：XS = "http://www.example.com/flute"> <XS：要素名= "FDTインスタンス"> <XS：complexTypeの> < XS：シーケンス>
<xs:element name="File" maxOccurs="unbounded"> <xs:complexType> <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:unsignedLong" 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:anyAttribute processContents="skip"/> </xs:complexType> </xs:element> </xs:sequence>
<XS：要素名= "ファイル" のmaxOccurs = "無制限"> <XS：complexTypeの> <XS：属性名= "コンテンツの場所" タイプ= "XS：anyURIの" 使用は= "必要" /> <XS：属性名= "TOI" タイプ= "XS：POSITIVEINTEGER" 使用= "必要" /> <XS：属性名= "のContent-Length" タイプ= "XS：なunsignedLong" 使用= "オプション" /> <XS：属性名=」転送長 "タイプ= "XS：なunsignedLong" 使用= "オプション"/> <XS：属性名は= "Content-Typeの" タイプ= "XS：文字列" 使用= "オプション"/> <XS：属性名="コンテンツエンコーディング "タイプ= "XS：文字列" 使用= "オプション"/> <XS：属性名= "のContent-MD5" タイプ= "XS：base64Binaryの" 使用= "オプション"/> <XS：属性名=" FEC-OTI-FECエンコード-ID」タイプ= "XS：なunsignedLong" 使用= "オプション" /> <XS：属性名= "FEC-OTI-FEC-インスタンス-ID" タイプ= "XS：なunsignedLong" 使用= "オプション" /> <XS：属性名= "FEC-OTI-最大ソースブロック長" タイプ= "XS：なunsignedLong" 使用= "オプション" /> <XS：属性名= "FEC-OTI-エンコーディング-symbol長 "タイプ= "XS：なunsignedLong" 使用= "オプション"/> <XS：属性名= "FEC-OTI-マックス・ナンバー・オブ・エンコーディング・シンボル" タイプ=" XS：UN signedLong」使用= "オプション" /> <XS：anyAttributeはのprocessContents = "/> </ XS" スキップ：complexTypeの> </ XS：要素> </ XS：シーケンス>
<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:unsignedLong" 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:anyAttribute processContents="skip"/> </xs:complexType> </xs:element> </xs:schema>
<XSは：属性名= "有効期限" タイプ= "XS：文字列" 使用= "必要" /> <XS：属性名= "コンプリート" タイプ= "XS：ブール" 使用= "オプション" /> <XS：属性名前= "Content-Typeの" タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "コンテンツエンコーディング" タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名前= "FEC-OTI-FECエンコード-ID" タイプ= "XS：なunsignedLong" 使用= "オプション" /> <XS：属性名= "FEC-OTI-FEC-インスタンス-ID" タイプ= "XS：なunsignedLongオプション "/> <XS：属性名=" "=使う" FEC-OTI-最大ソースブロック長 "タイプ= "XS：なunsignedLong" 使用= "オプション"/> <XS：属性名=" FEC- OTI-符号化シンボル長」タイプ= "XS：なunsignedLong" 使用= "オプション" /> <XS：属性名= "FEC-OTI-マックス・ナンバー・オブ・エンコーディング・シンボル" タイプ= "XS：なunsignedLong"使用= "オプション" /> <XS：anyAttributeはのprocessContents = "スキップ" /> </ XS：complexTypeの> </ XS：要素> </ XS：スキーマ>
Any valid FDT Instance must use the above XML Schema. This way FDT provides extensibility to support 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.).
任意の有効なFDTインスタンスは、上記のXMLスキーマを使用する必要があります。この方法では、FDTは、ファイル記述エントリ内のプライベート属性をサポートするための拡張性を提供します。ものとすることができる、例えば、ファイル（タイミング、パケット送信レート、等）の送達に関連する属性。
In case the basic FDT XML Schema is extended in terms of new descriptors, for attributes applying to a single file, those MUST be placed within the attributes of the element "File". For attributes 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 descriptors applied in the FDT are in the format of MIME fields and are either defined in the HTTP/1.1 specification [6] or another well-known specification.
場合は、基本的なFDT XMLスキーマは、単一のファイルに適用する属性に対して、新しい記述子の面で拡張され、それらは、要素「ファイル」の属性の中に置かなければなりません。現在FDTインスタンスによって記述されたすべてのファイルに適用する属性の場合、それらの要素「FDTインスタンス」の中に置かなければなりません。 FDTに適用新しい記述子はMIMEフィールドの形式で、いずれかのHTTP / 1.1仕様書[6]又は他の周知の仕様で定義されていることが推奨されます。
The FDT Instance itself MAY be content encoded, for example compressed. This specification defines FDT Instance Content Encoding Header (EXT_CENC). EXT_CENC is a new fixed length, ALC PI specific LCT header extension [3]. The Header Extension Type (HET) for the
FDTインスタンス自体は、例えば、圧縮のために、コンテンツ符号化することができます。この仕様は、FDTインスタンスのコンテンツエンコードのヘッダー（EXT_CENC）を定義します。 EXT_CENC新しい固定長であり、ALC PI特定LCTヘッダ拡張[3]。ヘッダ拡張タイプ（HET）
extension is 193. If the FDT Instance is content encoded, the EXT_CENC MUST be used to signal the content encoding type. In that case, EXT_CENC header extension MUST be used in all ALC packets carrying the same FDT Instance ID. Consequently, when 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, the EXT_CENC MUST NOT be used in any packet carrying the FDT Instance. The format of EXT_CENC is defined below:
拡張は、FDTインスタンスがコンテンツ符号化されている場合、EXT_CENCコンテンツ符号化タイプを通知するために使用されなければならない193です。その場合、EXT_CENCヘッダ拡張子は同じFDTインスタンスIDを運ぶすべてのALCパケットで使用されなければなりません。 EXT_CENCヘッダが使用される場合、結果として、それは適切なFDTインスタンスヘッダ（EXT_FDT）と一緒に使用されなければなりません。ファイル配信セッション内では、コンテンツのエンコードされたコンテンツエンコードとFDTインスタンスではありませんFDTインスタンスは、両方表示されることがあります。コンテンツのエンコーディングが指定FDTインスタンスのために使用されていない場合は、EXT_CENCは、FDTインスタンスを運ぶ任意のパケットに使用してはいけません。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Content Encoding Algorithm (CENC), 8 bits:
コンテンツ符号化アルゴリズム（CENC）、8ビット：
This field signals the content encoding algorithm used in the FDT Instance payload. The definition of this field is outside the scope of this specification. Applicable content encoding algorithms include, for example, ZLIB [10], DEFLATE [16] and GZIP [17].
このフィールドは、FDTインスタンスのペイロードに使用されるコンテンツの符号化アルゴリズムに信号を送ります。このフィールドの定義は、この仕様の範囲外です。該当するコンテンツの符号化アルゴリズムは、例えば、ZLIB [10]、DEFLATE [16]およびGZIP [17]が挙げられます。
Reserved, 16 bits:
予約され、16ビット：
This field MUST be set to all '0'.
このフィールドは、すべて「0」に設定しなければなりません。
The delivered files are carried as transport 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.
配信ファイルは、ファイル配信セッション中（TOISで識別）トランスポート・オブジェクトとして搭載されています。 FDTインスタンスを含むすべてのこれらのオブジェクトは、任意の順序で、セッション内で互いに平行に多重化することができる、すなわち、一つのファイルのためのパケットは、セッション内の他のファイルのためのパケットまたは他の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 MAY 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.
複数のFDTインスタンスは、この場合にTOI = 0を使用して、単一のセッションで送達することができる、次のFDTインスタンスの送信を開始する前に、以前のFDTインスタンスの送信を終了することが推奨されます。しかし、予期しないネットワーク条件に、FDTインスタンスのパケットがインターリーブされるかもしれません。受信機は、パケットがFDTインスタンスを一意EXT_FDTヘッダで運ばれ、そのFDTインスタンスIDによって識別されるための情報を含むFDTインスタンスを決定することができます。
ALC/LCT has a concept of channels and congestion control. There are four scenarios FLUTE is envisioned to be applied.
ALC / LCTはチャンネルと輻輳制御の概念を持っています。 FLUTEが適用されることが想定される4つのシナリオがあります。
(a) Use a single channel and a single-rate congestion control protocol.
（a）は、単一チャネルおよびシングルレート輻輳制御プロトコルを使用します。
(b) Use 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 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 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）のように、ファイル配信セッションのためのただ一つのチャネル、の概念を使用するときに直感的にその納期に対するオブジェクトの配信のために定義されている「後」「前」と。
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 complete the delivery of the second object 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 transport object must complete 'prior' to the second one, it is RECOMMENDED that only a single channel is used for the file delivery session.
複数のチャネルは、（b）及び（d）のように、使用されている場合は、そのオブジェクトが他の「前」に送達されたことを述べることは簡単ではありません。オブジェクトは、第2のオブジェクトの配信が開始される前にそれらのチャネルの一つ以上に配信されるように開始することができます。しかし、複数のチャネル/層の使用は、最初の前に、第2のオブジェクトの配信を完了することができます。これは、オブジェクトが単一チャネルを使用して順次配信されている問題ではありません。 FLUTEのアプリケーションは最初のトランスポート・オブジェクトは、第1に「前」完了しなければならない必須または重要な要件を有する場合したがって、単一のチャネルがファイル配信セッションのために使用することが推奨されます。
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 is 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 ok 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 ok to put all the packets for an FDT Instance into the higher layers that only high rate receivers will receive.
1. FDTインスタンスのパケットが送信される層には、低レート受信機が接合されていないために、それらの層に向かって付勢されるべきではありません。例えば、（この層は妥当な時間でより高いレートの受信機にFDTを提供するために十分なパケットを運ぶ場合）最下層にFDTインスタンスのすべてのパケットを入れてOKですが、すべてを入れてOKではありません唯一の高レート受信機が受信するより高い層への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 FEC Encoding ID 0 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以外のFEC符号化は、FDTインスタンスを送達するために使用されるべきか。この場合には、ネットワークにおけるパケットロスが存在しない場合でも、これは、低レート受信機は、FDTインスタンスのために送信されるすべてのパケットを受信しないであろう。
FLUTE inherits the use of FEC building block [4] 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. In this section, two methods are specified for FLUTE for this purpose: the use of ALC specific LCT extension header EXT_FTI [2] and the use of FDT.
FLUTEは、ALCからFECビルディングブロック[4]の使用を継承します。 ALCを超えるファイル配信のためのFLUTEを使用する場合はFECオブジェクト伝送情報は、ファイル配信セッションの中で、バンド送達されなければなりません。 ALC特定LCT拡張ヘッダEXT_FTIの使用[2]とFDTの使用：このセクションでは、二つの方法は、この目的のためにFLUTEのために指定されています。
The receiver of file delivery session MUST support delivery of FEC Object Transmission Information using the 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 FDT.
EXT_FTIの使用とFDTの使用：ファイル配信セッションの受信機は、受信機は両方の方法をサポートしなければならない0以外のTOI値についてTOI値0を使用して実施FDTインスタンスのEXT_FTIを使用してFECオブジェクト伝送情報の配信をサポートしなければなりません。
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 FDT (or both). Section 5.1 describes the required FEC Object Transmission Information that MUST be delivered to receivers for various FEC Encoding IDs. In addition, it describes the delivery using EXT_FTI. Section 5.2 describes the delivery using FDT.
受信機に配信される必要があるFECオブジェクト伝送情報は、EXT_FTIを使用するか、FDT（又は両方）を使用して送達されているか否かを正確に同じでなければなりません。 5.1節では、さまざまなFEC符号化IDの受信機に配信されなければならない必要なFECオブジェクト伝送情報を記述しています。また、EXT_FTIを使用して送達を記載します。 5.2節は、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 prioritizes the sources in the following way (in the order of decreasing priority).
与えられたTOIに関するFECオブジェクト伝送情報は、複数の情報源から入手可能です。この場合には、ファイル配信セッションの受信機は、（優先度の高いものから順に）次のようにソースを優先することを推奨されています。
As specified in [2], the EXT_FTI header extension is intended to carry the FEC Object Transmission Information for an object in-band. It is left up to individual implementations to decide how frequently and in which ALC packets the EXT_FTI header extension is included. In environments with higher packet loss rate, the EXT_FTI might need to be included more frequently in ALC packets than in environments with low error probability. The EXT_FTI MUST be included in at least one sent ALC packet for each FDT Instance.
で指定されるように、[2]、EXT_FTIヘッダ拡張は、インバンドオブジェクトのFECオブジェクト伝送情報を搬送することが意図されています。どのくらいの頻度とするALCがEXT_FTIヘッダ拡張が含まれているパケットを決定するために、個々の実装に一任されています。高いパケット損失率を持つ環境では、EXT_FTIは低い誤り確率を持つ環境ではよりALCパケットに、より頻繁に含まれる必要があります。 EXT_FTI各FDTインスタンスの少なくとも一つの送信されたALCパケットに含まれなければなりません。
The ALC specification does not define the format or the processing of the EXT_FTI header extension. The following sections specify EXT_FTI when used in FLUTE.
ALC仕様はフォーマットまたはEXT_FTIヘッダ拡張子の処理を定義していません。 FLUTEで使用する場合は、次のセクションでは、EXT_FTIを指定します。
In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint field of the ALC/LCT header.
FLUTEは、FEC符号化ID（8ビット）ALC / LCTヘッダのコードポイントフィールドで搬送されます。
The general EXT_FTI format specifies the structure and those attributes of FEC Object Transmission Information that are applicable to any FEC Encoding ID.
一般EXT_FTI形式は、構造および任意のFEC符号化IDに適用されるFECオブジェクト伝送情報のこれらの属性を指定します。
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 = 64 | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Instance ID | FEC Enc. ID Specific Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Type (HET), 8 bits:
ヘッダ拡張タイプ（HET）、8ビット：
64 as defined in [2].
64で定義されている[2]。
Header Extension Length (HEL), 8 bits:
ヘッダ拡張長（HEL）、8ビット：
The length of the whole Header Extension field, expressed in multiples of 32-bit words. This length includes the FEC Encoding ID specific format part.
全体ヘッダー拡張フィールドの長さは、32ビットワードの倍数で表しました。この長さは、FEC符号化ID、特定のフォーマットの部分を含みます。
Transfer Length, 48 bits:
転送長、48ビット：
The length of the transport object that carries the file in bytes. (This is the same as the file length if the file is not content encoded.)
バイト単位のファイルを運ぶトランスポート・オブジェクトの長さ。 （ファイルがコンテンツエンコードされていない場合、これは、ファイルの長さと同じです。）
FEC Instance ID, optional, 16 bits:
FECインスタンスID、オプション、16ビット：
This field is used for FEC Instance ID. It is only present if the value of FEC Encoding ID is in the range of 128-255. When the value of FEC Encoding ID is in the range of 0-127, this field is set to 0.
このフィールドは、FECインスタンスIDに使用されます。 FEC符号化IDの値が128〜255の範囲内にある場合にのみ存在します。 FEC符号化IDの値は0〜127の範囲にある場合、このフィールドは0に設定されています。
FEC Encoding ID Specific Format:
FEC符号化ID特定の形式：
Different FEC encoding schemes will need different sets of encoding parameters. Thus, the structure and length of this field depends on FEC Encoding ID. The next sections specify structure of this field for FEC Encoding ID numbers 0, 128, 129, and 130.
異なるFEC符号化方式は、符号化パラメータの異なるセットが必要になります。したがって、このフィールドの構成及び長さは、FEC符号化IDに依存します。次のセクションでは、FEC符号化ID番号0、128、129、及び130のために、このフィールドの構造を指定します。
FEC Encoding ID 0 is 'Compact No-Code FEC' (Fully-Specified) [7]. FEC Encoding ID 128 is 'Small Block, Large Block and Expandable FEC' (Under-Specified) [4]. FEC Encoding ID 130 is 'Compact FEC' (Under-Specified) [7]. For these FEC Encoding IDs, the FEC Encoding ID specific format of EXT_FTI is defined as follows.
FEC符号化IDは0（完全に指定された） 'コンパクト無コードFEC' である[7]。 FEC符号化ID 128（アンダー指定された）「小ブロック、大ブロック及び拡張FEC」である[4]。 FEC符号化ID 130 [7]（アンダー指定された） 'コンパクトFEC' です。次のようにこれらのFEC符号化IDについて、EXT_FTIのFEC符号化ID特定のフォーマットが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding Symbol Length, 16 bits:
シンボル長をコードする、16ビット：
Length of Encoding Symbol in bytes.
バイト単位での符号化シンボルの長さ。
All Encoding Symbols of a transport object MUST be equal to this length, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another Encoding Symbol is computed based on this source symbol to ensure the same interpretation of this Encoding Symbol value by the sender and receiver. However, this padding does not actually need to be sent with the data of the last source symbol.
トランスポート・オブジェクトのすべての符号化シンボルが最後のソースブロックの最後のソースシンボルのオプションを除いて、この長さに等しくなければならない（その結果、冗長なパディングは、この最後のシンボルに必須ではありません）。別の符号化シンボルは、送信側と受信側で、この符号化シンボル値の同じ解釈を確保するために、このソースシンボルに基づいて計算されている場合、この最後のソースシンボルは、論理的にゼロでパディングされなければなりません。しかし、このパディングが実際に最後のソースシンボルのデータを送信する必要はありません。
Maximum Source Block Length, 32 bits:
最大ソースブロック長、32ビット：
The maximum number of source symbols per source block.
ソースブロック当たりのソースシンボルの最大数。
This EXT_FTI specification requires that an algorithm is known to both sender and receivers for determining the size of all source blocks of the transport object that carries the file identified by the TOI (or within the FDT Instance identified by the TOI and the FDT Instance ID). The algorithm SHOULD be the same for all files using the same FEC Encoding ID within a session.
本EXT_FTI仕様は、アルゴリズムは（TOIとFDTインスタンスIDによって識別又はFDTインスタンス内）TOIによって識別されるファイルを運ぶトランスポート・オブジェクトのすべてのソースブロックのサイズを決定するために、送信者と受信機の両方に知られていることが必要。このアルゴリズムは、セッション内の同じFEC符号化IDを使用して、すべてのファイルに対して同じでなければなりません。
Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this use.
セクション5.1.2.3は、この使用は推奨されるアルゴリズムを記述しています。
For the FEC Encoding IDs 0, 128 and 130, this algorithm is the only well known way the receiver can determine the length of each source block. Thus, the algorithm does two things: (a) it tells the receiver the length of each particular source block as it is receiving packets for that source block - this is essential to all of these FEC schemes; and, (b) it provides the source block structure immediately to the receiver so that the receiver can determine where to save recovered source blocks at the beginning of the reception of data packets for the file - this is an optimization which is essential for some implementations.
FEC符号化IDは0、128及び130のために、このアルゴリズムは、受信機が各ソースブロックの長さを決定することができる唯一の周知の方法です。したがって、このアルゴリズムは、2つのことを行います。それは、そのソースブロックのパケットを受信しているとして、（A）は、受信機をそれぞれの特定のソースブロックの長さを伝える - これは、これらのFECのスキームのすべてに不可欠です。受信機は、ここでファイルのデータパケットの受信の開始時に回収されたソースブロックを保存するかを決定することができるようにと、（b）は、それが受信機に直ちにソースブロック構造を提供する - これは、いくつかの実装のために必須である最適化です。
Small Block Systematic FEC (Under-Specified). The FEC Encoding ID specific format of EXT_FTI is defined as follows.
小ブロックシステマティックFEC（指定アンダー）。次のようにEXT_FTIのFEC符号化ID特定のフォーマットが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length | Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding Symbol Length, 16 bits:
シンボル長をコードする、16ビット：
Length of Encoding Symbol in bytes.
バイト単位での符号化シンボルの長さ。
All Encoding Symbols of a transport object MUST be equal to this length, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another Encoding Symbol is computed based on this source symbol to ensure the same interpretation of this Encoding Symbol value by the sender and receiver. However, this padding need not be actually sent with the data of the last source symbol.
トランスポート・オブジェクトのすべての符号化シンボルが最後のソースブロックの最後のソースシンボルのオプションを除いて、この長さに等しくなければならない（その結果、冗長なパディングは、この最後のシンボルに必須ではありません）。別の符号化シンボルは、送信側と受信側で、この符号化シンボル値の同じ解釈を確保するために、このソースシンボルに基づいて計算されている場合、この最後のソースシンボルは、論理的にゼロでパディングされなければなりません。しかし、このパディングが実際に最後のソースシンボルのデータと一緒に送信する必要はありません。
Maximum Source Block Length, 16 bits:
最大ソースブロック長、16ビット：
The maximum number of source symbols per source block.
ソースブロック当たりのソースシンボルの最大数。
Maximum Number of Encoding Symbols, 16 bits:
符号化シンボル、16ビットの最大数：
Maximum number of Encoding Symbols that can be generated for a source block.
ソースブロックに対して生成することができる符号化シンボルの最大数。
This EXT_FTI specification requires that an algorithm is known to both sender and receivers for determining the size of all source blocks of the transport object that carries the file identified by the TOI (or within the FDT Instance identified by the TOI and the FDT Instance ID). The algorithm SHOULD be the same for all files using the same FEC Encoding ID within a session.
本EXT_FTI仕様は、アルゴリズムは（TOIとFDTインスタンスIDによって識別又はFDTインスタンス内）TOIによって識別されるファイルを運ぶトランスポート・オブジェクトのすべてのソースブロックのサイズを決定するために、送信者と受信機の両方に知られていることが必要。このアルゴリズムは、セッション内の同じFEC符号化IDを使用して、すべてのファイルに対して同じでなければなりません。
Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this use. For FEC Encoding ID 129 the FEC Payload ID in each data packet already contains the source block length for the source block corresponding to the Encoding Symbol carried in the data packet. Thus, the algorithm for computing source blocks for FEC Encoding ID 129 could be to just use the source block lengths carried in data packets within the FEC Payload ID. However, the algorithm described in Section 5.1.2.3 is useful for the receiver to compute the source block structure at the beginning of the reception of data packets for the file. If the algorithm described in Section 5.1.2.3 is used then it MUST be the case that the source block lengths that appear in data packets agree with the source block lengths calculated by the algorithm.
セクション5.1.2.3は、この使用は推奨されるアルゴリズムを記述しています。 FEC符号化IDの各データパケット129 FECペイロードIDは、既にデータパケットで運ばれた符号化シンボルに対応するソースブロックのソースブロック長を含んでいます。このように、FEC符号化ID 129のためのソースブロックを計算するためのアルゴリズムは、単にFECペイロードID内のデータパケットで運ばれたソースブロック長を使用することができました。しかしながら、セクション5.1.2.3に説明されたアルゴリズムは、ファイルのためのデータパケットの受信の開始時にソースブロック構造を計算する受信機のために有用です。セクション5.1.2.3に説明されたアルゴリズムが使用される場合、それはデータパケットに現れるソースブロック長がアルゴリズムによって計算ソースブロック長と一致する場合でなければなりません。
This algorithm computes a source block structure so that all source blocks are as close to being equal length as possible. A first number of source blocks are of the same larger length, and the remaining second number of source blocks are sent of the same smaller length. The total number of source blocks (N), the first number of source blocks (I), the second number of source blocks (N-I), the larger length (A_large) and the smaller length (A_small) are calculated thus,
このアルゴリズムは、すべてのソースブロックができるだけ等しい長さに近くなるように、ソースブロック構造を計算します。ソースブロックの最初の数は同じ大きい長さのものであり、ソースブロックの残りの第2の数は、同じ短い長さで送信されます。ソースブロックの総数（N）、ソースブロック（I）、ソースブロックの第二の数（N-I）、より大きな長さ（A_large）と小さい長さ（A_small）はこのようにして算出されているの最初の数、
Input: B -- Maximum Source Block Length, i.e., the maximum number of source symbols per source block L -- Transfer Length in bytes E -- Encoding Symbol Length in bytes
入力：B - 最大ソースブロック長、即ち、ソースブロックL当たりのソースシンボルの最大数 - バイトEに転送長 - バイトで符号化シンボルの長さ
Output: N -- The number of source blocks into which the transport object is partitioned.
出力：N - トランスポート・オブジェクトがパーティション化されている先のソースブロックの数。
The number and lengths of source symbols in each of the N source blocks.
N個のソースブロックの各ソースシンボルの数と長さ。
Algorithm: (a) The number of source symbols in the transport object is computed as T = L/E rounded up to the nearest integer. (b) The transport object is partitioned into N source blocks, where N = T/B rounded up to the nearest integer (c) The average length of a source block, A = T/N (this may be non-integer) (d) A_large = A rounded up to the nearest integer (it will always be the case that the value of A_large is at most B) (e) A_small = A rounded down to the nearest integer (if A is an integer A_small = A_large, and otherwise A_small = A_large - 1) (f) The fractional part of A, A_fraction = A - A_small (g) I = A_fraction * N (I is an integer between 0 and N-1) (h) Each of the first I source blocks consists of A_large source symbols, each source symbol is E bytes in length. Each of the remaining N-I source blocks consist of A_small source symbols, each source symbol is E bytes in length except that the last source symbol of the last source block is L-(((L-1)/E) rounded down to the nearest integer)*E bytes in length.
アルゴリズム：T = L / Eは、最も近い整数に切り上げたように（A）トランスポート・オブジェクト内のソースシンボルの数が計算されます。 （b）は、トランスポート・オブジェクトは、A = T / N（これは非整数であり得る）（N = T / Bは、最も近い整数（C）は、ソースブロックの平均長に切り上げNソースブロックに分割されD）A_large = Aは、それが常にA_largeの値は（（E）A_small = Aは、最も近い整数に切り捨て）最もBである場合であろう（最も近い整数に切り上げAは整数A_small = A_largeである場合、それ以外A_small = A_large - 1）（f）はAの小数部を、A_fraction = A - A_small（G）I = A_fraction * N（Iは0からN-1の間の整数である）、（H）第Iの各ソースブロックはA_largeのソースシンボルから成り、各ソースシンボルは、長さEバイトです。残りNIのソースブロックの各々はA_smallのソースシンボルから成り、各ソースシンボルが最後のソースブロックの最後のソースシンボルがLであることを除いて、長さがEバイトである - （（（L-1）/ E）が最寄りに切り捨て整数）* Eは、長さがバイト。
Note, this algorithm does not imply implementation by floating point arithmetic and integer arithmetic may be used to avoid potential floating point rounding errors.
このアルゴリズムは小数点演算及び整数演算は、潜在的な浮動小数点丸め誤差を回避するために使用することができるフローティングによる実装を意味するものではないことに注意してください。
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. For future FEC Encoding IDs, if the attributes listed below do not fulfill the needs of describing the FEC Object Transmission Information then additional new attributes MAY be used.
FDTは、「FDTインスタンス」またはFDT構造の「ファイル」要素内の適切な属性を使用して各ファイルのFECオブジェクト伝送情報を提供します。将来のFECエンコーディングIDについて、以下に示す属性は、FECオブジェクト伝送情報を記述するのニーズを満たしていない場合は、追加の新しい属性使用されるかもしれません。
* "Transfer-Length" is semantically equivalent with the field "Transfer Length" of EXT_FTI.
*「転送長」EXT_FTIのフィールド「転送長」と意味的に等価です。
* "FEC-OTI-FEC-Encoding-ID" is semantically equivalent with the field "FEC Encoding ID" as carried in the Codepoint field of the ALC/LCT header.
*「FEC-OTI-FECエンコーディング-IDは」ALC / LCTヘッダのコードポイントフィールドで運ばれるよう、フィールド「FEC符号化ID」と意味的に等価です。
* "FEC-OTI-FEC-Instance-ID" is semantically equivalent with the field "FEC Instance ID" of EXT_FTI.
* "FEC-OTI-FEC-インスタンス-IDは、" フィールドEXT_FTIの "FECインスタンスID" と意味的に等価です。
* "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent with the field "Maximum Source Block Length" of EXT_FTI for FEC Encoding IDs 0, 128 and 130, and semantically equivalent with the field "Maximum Source Block Length" of EXT_FTI for FEC Encoding ID 129.
*「FEC-OTI-最大ソースブロック長」FEC符号化IDは0、128及び130のためのEXT_FTIのフィールド「最大ソースブロック長」と意味的に同等、およびフィールド「最大ソースブロック長」と意味的に同等ですFEC符号化ID 129用EXT_FTIの。
* "FEC-OTI-Encoding-Symbol-Length" is semantically equivalent with the field "Encoding Symbol Length" of EXT_FTI for FEC Encoding IDs 0, 128, 129 and 130.
*「FEC-OTI-符号化シンボル長さ」FEC符号化IDは0、128、129及び130のためのEXT_FTIのフィールド「符号化シンボル長」と意味的に等価です。
* "FEC-OTI-Max-Number-of-Encoding-Symbols" is semantically equivalent with the field "Maximum Number of Encoding Symbols" of EXT_FTI for FEC Encoding ID 129.
*「FEC-OTI-最大数-の符号化シンボル」フィールドFEC符号化ID 129のためEXT_FTIの「符号化シンボルの最大数」の意味的に等価です。
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
represents the entry point from which thereafter the receiver
operation falls into the scope of this specification. According
to [2], the transport parameters of an ALC/LCT session that the
receiver needs to know are:
* 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の使用において暗黙的であり、これは、セッションが複数のオブジェクト（すべてのFLUTEセッションは、複数のオブジェクトのパケットを運ぶ）のためのパケットを運ぶか否かの指示のALC要件を満たします。
Optionally, the following parameters MAY be associated with the session (Note, 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 FDT;
* FEC符号化ID及びFECインスタンスIDをデフォルトのFEC符号化ID 0は、FDTの送達のために使用されていません。
* Content Encoding format if optional content encoding of 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.
*セッションが注目されているファイルが含まれていることを、まず第一に、受信機に伝えるいくつかの情報。
It is envisioned that these parameters would be described according to some session description syntax (such as SDP [12] or XML based) and held in a file which would be acquired by the receiver before the FLUTE session begins by means of some transport protocol (such as Session Announcement Protocol [11], email, HTTP [6], SIP [22], manual pre-configuration, 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.
（FLUTEセッションは、いくつかのトランスポート・プロトコルを用いて開始される前に受信器によって取得されるであろうこれらのパラメータは、（例えば、SDP [12]、またはXMLベースのような）いくつかのセッション記述の構文に従って記述し、ファイル内に保持されることが想定されますそのようなセッションアナウンスメントプロトコル[11]、電子メール、HTTP [6]、SIP [22]、手動の事前設定、等）しかしながら、受信機は、上記のパラメータを発見する方法は、この文書の範囲外であります、それはLCTとALCのためにあるよう。特に、この仕様は、強制または任意のメカニズムを排除するものではありません。
The security considerations that apply to, and are described in, ALC [2], LCT [3] and FEC [4] also apply to FLUTE. In addition, any security considerations that apply to any congestion control building block used in conjunction with FLUTE also apply to FLUTE.
適用され、に記載されているセキュリティ上の考慮事項は、ALCは、[2]、LCT [3]及びFEC [4]また、FLUTEに適用されます。また、FLUTEと組み合わせて使用されるすべての輻輳制御ビルディングブロックに適用されるセキュリティ上の考慮事項はまた、FLUTEに適用されます。
Because of the use of FEC, FLUTE is especially vulnerable to denial-of-service attacks by attackers that try to send forged packets to the session which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of the FDT or file by receivers. Like ALC, FLUTE is particularly affected by such an attack because many receivers may receive the same forged packet. A malicious attacker may spoof file packets and cause incorrect recovery of a file.
そのためFECの使用、FLUTEは成功した再構成を防止または受信機によってFDTまたはファイルの大部分の不正確な再構成を引き起こすセッションに偽造パケットを送信しようとする攻撃者によって、サービス拒否攻撃に対して特に脆弱です。多くの受信機が同じ偽造パケットを受信することもできるので、ALCのように、FLUTEは特に、このような攻撃の影響を受けています。悪意のある攻撃者は、ファイルのパケットを偽装し、ファイルの不正な回復を引き起こす可能性があります。
Even more damaging, a malicious forger may spoof FDT Instance packets, for example sending packets with erroneous FDT-Instance fields. Many attacks can follow this approach. For instance a malicious attacker may alter the Content-Location field of TOI 'n', to make it point to a system file or a user configuration file. Then, TOI 'n' can carry a Trojan Horse or some other type of virus. It is thus STRONGLY RECOMMENDED that the FLUTE delivery service at the receiver does not have write access to the system files or directories, or any other critical areas. As described for MIME [20][21], special consideration should be paid to the security implications of any MIME types that can cause the remote execution of any actions in the recipient's environment. Note, RFC 1521 [21] describes important security issues for this environment, even though its protocol is obsoleted by RFC 2048 [20].
さらにより損傷、悪意のある偽造者は、誤ったFDTインスタンスのフィールドを持つパケットを送信例えば、FDTインスタンスのパケットを偽造することができます。多くの攻撃は、このアプローチに従うことができます。たとえば、悪意のある攻撃者は、それがシステムファイルやユーザーの設定ファイルを指すようにするために、TOI「N」の内容-Locationフィールドを変更することができます。その後、TOI「N」をトロイの木馬やウイルスの他のいくつかのタイプを運ぶことができます。したがって、強く、受信機におけるFLUTE配信サービスは、システムファイルやディレクトリ、または任意の他の重要な領域への書き込みアクセス権を持っていないことが推奨されます。 MIME [20] [21]のために説明したように、特別な配慮は、受信者の環境内のすべてのアクションのリモート実行を引き起こす可能性があります任意のMIMEタイプのセキュリティへの影響に留意する必要があります。注、RFC 1521 [21]は、そのプロトコルはRFC 2048 [20]によって廃止されていても、このような環境のための重要なセキュリティ上の問題について説明します。
Another example is generating a bad Content-MD5 sum, leading receivers to reject the associated file that will be declared corrupted. The Content-Encoding can also be modified, which also prevents the receivers to correctly handle the associated file. These examples show that the FDT information is critical to the FLUTE delivery service.
別の例は、破損したと宣言され、関連するファイルを拒否するように受信機をリードし、悪いのContent-MD5サムを生成しています。コンテンツのエンコーディングはまた、受信機が正しく関連付けられているファイルを処理するために防止する、変更することができます。これらの例は、FDT情報がFLUTE配信サービスに不可欠であることを示しています。
At the application level, it is RECOMMENDED that an integrity check on the entire received object be done once the object is reconstructed to ensure it is the same as the sent object, especially for objects that are FDT Instances. Moreover, in order to obtain strong cryptographic integrity protection a digital signature verifiable by the receiver SHOULD be used to provide this application level integrity check. However, if even one corrupted or forged packet is used to reconstruct the object, it is likely that the received object will be reconstructed incorrectly. This will appropriately cause the integrity check to fail and, in this case, the inaccurately reconstructed object SHOULD be discarded. Thus, the acceptance of a single forged packet can be an effective denial of service attack for distributing objects, but an object integrity check at least prevents inadvertent use of inaccurately reconstructed objects. The specification of an application level integrity check of the received object is outside the scope of this document.
アプリケーションレベルでは、オブジェクトが、それが送信されたオブジェクトと同じであることを確認するために再構築されると、全体の受信されたオブジェクト上の整合性チェックは特にFDTインスタンスであるオブジェクトのために、行われることが推奨されます。また、強力な暗号化、完全性保護を得るために受信機によって検証デジタル署名は、このアプリケーションレベルの整合性チェックを提供するために使用されるべきです。一つでも壊れているか、または偽造パケットがオブジェクトを再構築するために使用されている場合は、受信したオブジェクトが誤って再構築される可能性があります。これは、適切に整合性チェックが失敗すると、この場合には、不正確に再構築されたオブジェクトが破棄されるべき原因になります。したがって、単一の偽造パケットの受け入れは、オブジェクトを配布するためのサービス攻撃の効果的な拒否することができますが、オブジェクトの整合性チェックは、少なくとも不正確に再構築されたオブジェクトの不注意な使用を防止します。受信したオブジェクトのアプリケーションレベルの整合性チェックの仕様は、この文書の範囲外です。
At the packet level, it is RECOMMENDED that a packet level authentication be used to ensure that each received packet is an authentic and uncorrupted packet containing FEC data for the object arriving from the specified sender. Packet level authentication has the advantage that corrupt or forged packets can be discarded individually and the received authenticated packets can be used to accurately reconstruct the object. Thus, the effect of a denial of service attack that injects forged packets is proportional only to the number of forged packets, and not to the object size. Although there is currently no IETF standard that specifies how to do multicast packet level authentication, TESLA [14] is a known multicast packet authentication scheme that would work.
パケットレベルでは、パケットレベルの認証は、各受信パケットが指定された送信者から到着するオブジェクトのためのFECデータを含む真正と破損していないパケットであることを確実にするために使用することを推奨されています。パケットレベルの認証が破損または偽造パケットが個別に廃棄することができ、受信された認証パケットが正確にオブジェクトを再構成するために使用することができるという利点を有します。したがって、偽造パケットを注入するサービス拒否攻撃の影響は、偽造パケットの数にではなく、オブジェクトのサイズに比例します。マルチキャストパケットレベルの認証を行う方法を指定する一切IETF標準は現在ありませんが、テスラ[14]は働くだろう既知のマルチキャストパケットの認証方式です。
In addition to providing protection against reconstruction of inaccurate objects, packet level authentication can also provide some protection against denial of service attacks on the multiple rate congestion control. Attackers can try to inject forged packets with incorrect congestion control information into the multicast stream, thereby potentially adversely affecting network elements and receivers downstream of the attack, and much less significantly the rest of the network and other receivers. Thus, it is also RECOMMENDED that packet level authentication be used to protect against such attacks. TESLA [14] can also be used to some extent to limit the damage caused by such attacks. However, with TESLA a receiver can only determine if a packet is authentic several seconds after it is received, and thus an attack against the congestion control protocol can be effective for several seconds before the receiver can react to slow down the session reception rate.
不正確なオブジェクトの再構築に対する保護を提供することに加えて、パケットレベルの認証は、複数のレート混雑制御上のサービス妨害攻撃に対する何らかの保護を提供することができます。攻撃者は、攻撃の下流のネットワーク要素と受信機に影響を与える、とはるかに少ない大幅にネットワークの他の部分と他のレシーバ、それによって潜在的に有害な、マルチキャストストリームに間違った輻輳制御情報を偽造パケットを注入しようとすることができます。したがって、また、パケットレベルの認証は、このような攻撃から保護するために使用することをお勧めします。 TESLA [14]また、このような攻撃によって引き起こされる損傷を制限するために、ある程度使用することができます。しかし、TESLAと受信機は、それが受信された後、パケットが真正数秒であり、受信機は、セッションの受信速度を遅くするために反応することができる前に、輻輳制御プロトコルに対するこのような攻撃は、数秒間有効であることができるかどうかを決定することができます。
Reverse Path Forwarding checks SHOULD be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path.
逆方向パス転送チェックがマルチキャストツリーデータパスに偽造パケットを注入悪い薬剤の可能性を制限するために受信機に送信者からのパスに沿ってすべてのネットワークルータとスイッチで有効にされるべきです。
A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect health of the network in the path between the sender and the receiver, and may also affect the reception rates of other receivers joined to the session. It is therefore 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.
複数レート輻輳制御構築ブロックの誤ったまたは破損実装と受信機は、送信機と受信機との間の経路内のネットワークの健康に影響を与えることができ、また、他の受信機の受信レートに影響を与える可能性があるセッションに参加しました。したがって、受信機は、彼らがセッションに参加するために必要なセッション記述を受ける前に、正当として自分自身を識別するために要求されることが推奨されます。どのように受信機が正当として自分自身を識別することは、この文書の範囲外です。
Another vulnerability of FLUTE is the potential of receivers obtaining an incorrect Session Description for the session. The consequences of this could be 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 disrupting traffic in portions of the network. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate Session Descriptions from authorized senders. How this is done is outside the scope of this document.
FLUTEの別の脆弱性は、セッションのために間違ったセッション記述を取得する受信機の可能性です。これの結果は、間違ったセッション記述を持つ、正当な受信機が正しくセッションコンテンツを受信することができない、または受信機が誤って、それによってネットワークの一部でトラフィックを中断、彼らがすることができるよりもはるかに高いレートで受信しようということである可能性があります。これらの問題を回避するために、対策は受信機が唯一認可された送信者からの正当なセッションの説明を受け入れることを確認するために、ソースの認証を使用することにより、例えば、間違ったセッションの説明を受け入れることから、レシーバを防ぐために取られることが推奨されます。これはどのように行われ、この文書の範囲外です。
No information in this specification is directly subject to IANA registration. However, building blocks components used by ALC may introduce additional IANA considerations. In particular, the FEC building block used by FLUTE does require IANA registration of the FEC codec used.
本明細書中の情報は、IANA登録に直接の対象ではありません。しかし、ALCによって使用されるビルディングブロックコンポーネントは、追加のIANAの考慮を導入することができます。具体的には、FLUTEによって使用されるFECビルディングブロックを用いるFECコーデックのIANA登録を必要としません。
The following persons have contributed to this specification: Brian Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma, Jani Peltotalo, Sami Peltotalo, Topi Pohjolainen, and Lorenzo Vicisano. The authors would like to thank all the contributors for their valuable work in reviewing and providing feedback regarding this specification.
次の人はこの仕様に貢献してきた：ブライアン・アダムソン、マーク・ハンドリー、エサJalonen、ロジャーKermode、ユハ・ペッカLuoma、ヤニPeltotalo、サミPeltotalo、トピPohjolainen、及びロレンツォVicisanoを。著者は、この仕様に関するフィードバックを見直し、提供する彼らの貴重な仕事のためのすべての貢献に感謝したいと思います。
Normative References
引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[2]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、およびJ.クロウクロフト、RFC 3450 "非同期階層は（ALC）プロトコルインスタンス化コーディング"、2002年12月。
[3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[3]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "階層化符号化トランスポート（LCT）ビルディングブロック"、RFC 3451、2002年12月。
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[4]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 3452、2002年12月。
[5] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[5]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装"、RFC 1305、1992年3月。
[6] 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.
[6]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[7] Luby, M. and L. Vicisano, "Compact Forward Error Correction (FEC) Schemes", RFC 3695, February 2004.
[7]ルビー、M.およびL. Vicisano、 "コンパクト前方誤り訂正（FEC）スキーム"、RFC 3695、2004年2月。
[8] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation, May 2001.
[8]トンプソン、H.、ブナ、D.、マロニー、M.およびN.メンデルゾーン、 "XMLスキーマパート1：構造"、W3C勧告、2001年5月。
[9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C Recommendation, May 2001.
[9]ビロン、P.およびA.マルホトラ、 "XMLスキーマパート2：データ型"、W3C勧告、2001年5月。
Informative References
参考文献
[10] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[10]ドイツ、P.及びJ-L。 Gailly氏、 "ZLIB圧縮データフォーマット仕様バージョン3.3"、RFC 1950、1996年5月。
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[11]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[12] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[12]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[13] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[13]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[14] Perrig, A., Canetti, R., Song, D., and J. Tygar, "Efficient and Secure Source Authentication for Multicast, Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46.", February 2001.
[14] Perrig、A.、カネッティ、R.、歌、D.、およびJ. Tygar、 "マルチキャスト、ネットワークと分散システムセキュリティシンポジウム、NDSS 2001、PP。35-46。ための効率的で安全なソース認証"、 2001年2月。
[15] Holbrook, H., "A Channel Model for Multicast, Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California", August 2001.
[15]ホルブルック、H.、「マルチキャスト、博士論文、スタンフォード大学、コンピュータサイエンス学部、スタンフォード大学、カリフォルニアのためのチャネルモデル」、2001年8月。
[16] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[16]ドイツ、P.、 "DEFLATE圧縮データフォーマット仕様バージョン1.3"、RFC 1951、1996年5月。
[17] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[17]ドイツ、P.、 "GZIPファイル形式の仕様バージョン4.3"、RFC 1952、1996年5月。
[18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[18] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[19] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[19]イーストレーク、D.、Reagle、J.、およびD.ソロ "（拡張マークアップ言語）、XML署名の構文および処理"、RFC 3275、2002年3月。
[20] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[20]解放され、N.、Klensin、J.、およびJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、RFC 2048、1996年11月。
[21] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 1521, November 1996.
[21]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 1521、1996年11月。
[22] 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.
[22]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
Appendix A. Receiver operation (informative)
付録A.レシーバ動作（参考）
This section gives an example 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 pair: (source IP address, Transport Session Identifier). The receiver also obtains the destination IP addresses and respective ports associated with the file delivery session.
（送信元IPアドレス、トランスポートセッション識別子）：1.受信機はペアによって識別されるファイル配信セッションの記述を取得します。受信機はまた、宛先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, 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. Receiver recovers an object. An object can be recovered when an appropriate set of packets containing Encoding Symbols for the transport object have 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. If the recovered object was an FDT Instance with FDT Instance ID 'N', the receiver parses the payload of the instance 'N' of FDT and updates its FDT database accordingly. The receiver identifies FDT Instances within a file delivery session by the EXT_FDT header extension. Any object that is delivered using EXT_FDT header extension is an FDT Instance, uniquely identified by the FDT Instance ID. Note that TOI '0' is exclusively reserved for FDT delivery.
回収されたオブジェクトは、FDTインスタンスID「N」とFDTインスタンスであった場合、受信機は、FDTの「N」インスタンスのペイロードを構文解析し、それに応じてFDTデータベースを更新6。受信機は、EXT_FDTヘッダ拡張子でファイル配信セッション内のFDTインスタンスを識別する。 EXT_FDTヘッダ拡張を使用して送達される任意のオブジェクトは、一意FDTインスタンスIDによって識別され、FDTインスタンスです。 TOI「0」が排他的に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 file with the given properties. The receiver also checks that received content length matches with the description in the database. Optionally, if MD5 checksum has been used, the receiver checks that calculated MD5 matches with 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 digestive, etc.) is 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 3. Otherwise end.
9.ファイル配信セッションの終了時間に達していない場合はそれ以外のバックエンド3に行きます。
Appendix B. Example of FDT Instance (informative)
FDTインスタンスの付録B.例（参考）
<?xml version="1.0" encoding="UTF-8"?> <FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fl="http://www.example.com/flute" xsi:schemaLocation="http://www.example.com/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>
<？xml version = "1.0" エンコード= "UTF-8"？> <FDT-インスタンスのxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance" のxmlns：FL = "のhttp：/ /www.example.com/flute //www.example： "XSI：schemaLocationのは= "http://www.example.com/flute-fdt.xsd 2890842807 "> <ファイルのContent-場所=" HTTP"=期限" .COM /メニュー/ tracklist.html」TOI = "1" のContent-Type = "text / htmlの" /> <ファイルのContent-場所= "http://www.example.com/tracks/track1.mp3" TOI = "2" のContent-Length = "6100" のContent-Type = "オーディオ/ mp3" のContent-エンコード= "gzipでの" Content-MD5 = "+ VP5IrWploFkZWc11iLDdA ==" いくつかの-プライベート拡張タグ= "ABC123" /> < / FDTインスタンス>
Authors' Addresses
著者のアドレス
Toni Paila Nokia Itamerenkatu 11-13 Helsinki FIN-00180 Finland
トニPailaノキアItamerenkatu 11-13 FIN-00180ヘルシンキフィンランド
EMail: toni.paila@nokia.com
メールアドレス：toni.paila@nokia.com
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA 94538 USA
マイケル・ルビーデジタル噴水39141シビックセンター博士スイート300フリーモント、CA 94538 USA
EMail: luby@digitalfountain.com
メールアドレス：luby@digitalfountain.com
Rami Lehtonen TeliaSonera Hatanpaan valtatie 18 Tampere FIN-33100 Finland
ラミLehtonenのテリアソネラHatanpaanハイウェイ18 FIN-33100タンペレフィンランド
EMail: rami.lehtonen@teliasonera.com
メールアドレス：rami.lehtonen@teliasonera.com
Vincent Roca INRIA Rhone-Alpes 655, av. de l'Europe Montbonnot St Ismier cedex 38334 France
ヴィンセントロカINRIAローヌ・アルプ655、AV。フランス38334 CEDEXドゥヨーロッパMontbonnotセントIsmier
EMail: vincent.roca@inrialpes.fr
メールアドレス：vincent.roca@inrialpes.fr
Rod Walsh Nokia Visiokatu 1 Tampere FIN-33720 Finland
ロッド・ウォルシュノキアビジョンストリート1 FIN-33720タンペレフィンランド
EMail: rod.walsh@nokia.com
メールアドレス：rod.walsh@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。