Internet Engineering Task Force (IETF) T. Paila
Request for Comments: 6726 Nokia
Obsoletes: 3926 R. Walsh
Category: Standards Track Nokia/TUT
ISSN: 2070-1721 M. Luby
Qualcomm Technologies, Inc.
V. Roca
INRIA
R. Lehtonen
TeliaSonera
November 2012
Internet Engineering Task Force (IETF) T. Paila
Request for Comments: 6726 Nokia
Obsoletes: 3926 R. Walsh
Category: Standards Track Nokia/TUT
ISSN: 2070-1721 M. Luby
Qualcomm Technologies, Inc.
V. Roca
INRIA
R. Lehtonen
TeliaSonera
November 2012
FLUTE - File Delivery over Unidirectional Transport
长笛-通过单向传输传递文件
Abstract
摘要
This document defines File Delivery over Unidirectional Transport (FLUTE), a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC 3926.
本文档定义了单向传输上的文件传递（FLUTE），这是一种通过Internet单向传递文件的协议，特别适用于多播网络。该规范建立在异步分层编码的基础上，异步分层编码是为大规模可伸缩多播分发而设计的基本协议。本文件废除了RFC 3926。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6726.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6726.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicability Statement ....................................5
1.1.1. The Target Application Space ........................5
1.1.2. The Target Scale ....................................5
1.1.3. Intended Environments ...............................5
1.1.4. Weaknesses ..........................................6
2. Conventions Used in This Document ...............................6
3. File Delivery ...................................................7
3.1. File Delivery Session ......................................8
3.2. File Delivery Table .......................................10
3.3. Dynamics of FDT Instances within a File Delivery Session ..12
3.4. Structure of FDT Instance Packets .........................15
3.4.1. Format of FDT Instance Header ......................16
3.4.2. Syntax of FDT Instance .............................17
3.4.3. Content Encoding of FDT Instance ...................21
3.5. Multiplexing of Files within a File Delivery Session ......22
4. Channels, Congestion Control, and Timing .......................23
5. Delivering FEC Object Transmission Information .................24
6. Describing File Delivery Sessions ..............................26
1. Introduction ....................................................3
1.1. Applicability Statement ....................................5
1.1.1. The Target Application Space ........................5
1.1.2. The Target Scale ....................................5
1.1.3. Intended Environments ...............................5
1.1.4. Weaknesses ..........................................6
2. Conventions Used in This Document ...............................6
3. File Delivery ...................................................7
3.1. File Delivery Session ......................................8
3.2. File Delivery Table .......................................10
3.3. Dynamics of FDT Instances within a File Delivery Session ..12
3.4. Structure of FDT Instance Packets .........................15
3.4.1. Format of FDT Instance Header ......................16
3.4.2. Syntax of FDT Instance .............................17
3.4.3. Content Encoding of FDT Instance ...................21
3.5. Multiplexing of Files within a File Delivery Session ......22
4. Channels, Congestion Control, and Timing .......................23
5. Delivering FEC Object Transmission Information .................24
6. Describing File Delivery Sessions ..............................26
7. Security Considerations ........................................27
7.1. Problem Statement .........................................27
7.2. Attacks against the Data Flow .............................28
7.2.1. Access to Confidential Files .......................28
7.2.2. File Corruption ....................................28
7.3. Attacks against the Session Control Parameters and
Associated Building Blocks ................................30
7.3.1. Attacks against the Session Description ............30
7.3.2. Attacks against the FDT Instances ..................31
7.3.3. Attacks against the ALC/LCT Parameters .............31
7.3.4. Attacks against the Associated Building Blocks .....32
7.4. Other Security Considerations .............................32
7.5. Minimum Security Recommendations ..........................33
8. IANA Considerations ............................................34
8.1. Registration of the FDT Instance XML Namespace ............34
8.2. Registration of the FDT Instance XML Schema ...............34
8.3. Registration of the application/fdt+xml Media Type ........35
8.4. Creation of the FLUTE Content Encoding Algorithms
Registry ..................................................36
8.5. Registration of LCT Header Extension Types ................36
9. Acknowledgments ................................................36
10. Contributors ..................................................37
11. Change Log ....................................................37
11.1. RFC 3926 to This Document ................................37
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................41
Appendix A. Receiver Operation (Informative) ......................44
Appendix B. Example of FDT Instance (Informative) .................45
7. Security Considerations ........................................27
7.1. Problem Statement .........................................27
7.2. Attacks against the Data Flow .............................28
7.2.1. Access to Confidential Files .......................28
7.2.2. File Corruption ....................................28
7.3. Attacks against the Session Control Parameters and
Associated Building Blocks ................................30
7.3.1. Attacks against the Session Description ............30
7.3.2. Attacks against the FDT Instances ..................31
7.3.3. Attacks against the ALC/LCT Parameters .............31
7.3.4. Attacks against the Associated Building Blocks .....32
7.4. Other Security Considerations .............................32
7.5. Minimum Security Recommendations ..........................33
8. IANA Considerations ............................................34
8.1. Registration of the FDT Instance XML Namespace ............34
8.2. Registration of the FDT Instance XML Schema ...............34
8.3. Registration of the application/fdt+xml Media Type ........35
8.4. Creation of the FLUTE Content Encoding Algorithms
Registry ..................................................36
8.5. Registration of LCT Header Extension Types ................36
9. Acknowledgments ................................................36
10. Contributors ..................................................37
11. Change Log ....................................................37
11.1. RFC 3926 to This Document ................................37
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................41
Appendix A. Receiver Operation (Informative) ......................44
Appendix B. Example of FDT Instance (Informative) .................45
This document defines FLUTE version 2, a protocol for unidirectional delivery of files over the Internet. This specification is not backwards compatible with the previous experimental version defined in [RFC3926] (see Section 11 for details). The specification builds on Asynchronous Layered Coding (ALC), version 1 [RFC5775], the base protocol designed for massively scalable multicast distribution. ALC defines transport of arbitrary binary objects. For file delivery applications, mere transport of objects is not enough, however. The end systems need to know what the objects actually represent. This document specifies a technique called FLUTE -- a mechanism for signaling and mapping the properties of files to concepts of ALC in a way that allows receivers to assign those parameters for received objects. Consequently, throughout this document the term 'file' relates to an 'object' as discussed in ALC. Although this
本文档定义了FLUTE版本2，这是一种通过Internet单向传递文件的协议。本规范与[RFC3926]中定义的先前实验版本不向后兼容（详见第11节）。该规范建立在异步分层编码（ALC）版本1[RFC5775]的基础上，该版本是为大规模可伸缩多播分发而设计的基本协议。ALC定义了任意二进制对象的传输。然而，对于文件传递应用程序，仅仅传输对象是不够的。终端系统需要知道对象实际代表什么。本文档指定了一种称为FLUTE的技术，这是一种将文件属性发信号并映射到ALC概念的机制，允许接收者为接收到的对象分配这些参数。因此，在本文件中，“文件”一词与ALC中讨论的“对象”相关。虽然这
specification frequently makes use of multicast addressing as an example, the techniques are similarly applicable for use with unicast addressing.
规范经常使用多播寻址作为示例，这些技术同样适用于单播寻址。
This document defines a specific transport application of ALC, adding the following specifications:
本文件定义了ALC的特定运输应用，增加了以下规范：
- Definition of a file delivery session built on top of ALC, including transport details and timing constraints.
- 在ALC之上构建的文件传递会话的定义，包括传输详细信息和时间限制。
- In-band signaling of the transport parameters of the ALC session.
- ALC会话传输参数的带内信令。
- In-band signaling of the properties of delivered files.
- 传送文件属性的带内信令。
- Details associated with the multiplexing of multiple files within a session.
- 与会话中多个文件的多路复用相关的详细信息。
This specification is structured as follows. Section 3 begins by defining the concept of the file delivery session. Following that, it introduces the File Delivery Table, which forms the core part of this specification. Further, it discusses multiplexing issues of transmission objects within a file delivery session. Section 4 describes the use of congestion control and channels with FLUTE. Section 5 defines how the Forward Error Correction (FEC) Object Transmission Information is to be delivered within a file delivery session. Section 6 defines the required parameters for describing file delivery sessions in a general case. Section 7 outlines security considerations regarding file delivery with FLUTE. Last, there are two informative appendices. Appendix A describes an envisioned receiver operation for the receiver of the file delivery session. Readers who want to see a simple example of FLUTE in operation should refer to Appendix A right away. Appendix B gives an example of a File Delivery Table.
本规范的结构如下所示。第3节首先定义文件交付会话的概念。然后，介绍了文件传递表，它构成了本规范的核心部分。此外，本文还讨论了文件传递会话中传输对象的多路复用问题。第4节描述了拥塞控制的使用和具有长笛的信道。第5节定义了如何在文件传递会话中传递前向纠错（FEC）对象传输信息。第6节定义了在一般情况下描述文件交付会话所需的参数。第7节概述了有关使用FLUTE交付文件的安全注意事项。最后，有两个资料性附录。附录A描述了文件交付会话接收器的预期接收器操作。读者若想看到一个简单的长笛操作示例，请立即参阅附录a。附录B给出了文件交付表的示例。
This specification contains part of the definitions necessary to fully specify a Reliable Multicast Transport (RMT) protocol in accordance with [RFC2357].
本规范包含根据[RFC2357]完全指定可靠多播传输（RMT）协议所需的部分定义。
This document obsoletes [RFC3926], which contained a previous version of this specification and was published in the "Experimental" category. This Proposed Standard specification is thus based on [RFC3926] and has been updated according to accumulated experience and growing protocol maturity since the publication of [RFC3926]. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
本文件废弃了[RFC3926]，其中包含本规范的早期版本，并以“实验”类别发布。因此，本拟议标准规范以[RFC3926]为基础，并根据[RFC3926]发布以来积累的经验和不断增长的协议成熟度进行了更新。上述经验既适用于本规范本身，也适用于与本规范使用相关的拥塞控制策略。
The differences between [RFC3926] and this document are listed in Section 11.
第11节列出了[RFC3926]与本文件之间的差异。
This document updates ALC [RFC5775] and Layered Coding Transport (LCT) [RFC5651] in the sense that it defines two new header extensions, EXT_FDT and EXT_CENC.
本文档更新了ALC[RFC5775]和分层编码传输（LCT）[RFC5651]，因为它定义了两个新的报头扩展：EXT_FDT和EXT_CENC。
FLUTE is applicable to the delivery of large and small files to many hosts, using delivery sessions of several seconds or more. For instance, FLUTE could be used for the delivery of large software updates to many hosts simultaneously. It could also be used for continuous, but segmented, data such as time-lined text for subtitling -- potentially leveraging its layering inheritance from ALC and LCT to scale the richness of the session to the congestion status of the network. It is also suitable for the basic transport of metadata, for example, Session Description Protocol (SDP) [RFC4566] files that enable user applications to access multimedia sessions.
FLUTE适用于使用几秒钟或更长时间的传递会话向许多主机传递大小文件。例如，FLUTE可用于同时向多台主机交付大型软件更新。它还可以用于连续但分段的数据，如用于字幕的时间线文本——潜在地利用其从ALC和LCT继承的分层功能，将会话的丰富性扩展到网络的拥塞状态。它还适用于元数据的基本传输，例如会话描述协议（SDP）[RFC4566]文件，该文件允许用户应用程序访问多媒体会话。
Massive scalability is a primary design goal for FLUTE. IP multicast is inherently massively scalable, but the best-effort service that it provides does not provide session management functionality, congestion control, or reliability. FLUTE provides all of this by using ALC and IP multicast without sacrificing any of the inherent scalability of IP multicast.
大规模的可扩展性是长笛的主要设计目标。IP多播本质上是大规模可扩展的，但它提供的尽力而为服务不提供会话管理功能、拥塞控制或可靠性。长笛通过使用ALC和IP多播提供了所有这些，而不牺牲IP多播固有的可伸缩性。
All of the environmental requirements and considerations that apply to the RMT building blocks used by FLUTE shall also apply to FLUTE. These are the ALC protocol instantiation [RFC5775], the LCT building block [RFC5651], and the FEC building block [RFC5052].
所有适用于长笛所用RMT积木的环境要求和注意事项也应适用于长笛。这些是ALC协议实例化[RFC5775]、LCT构建块[RFC5651]和FEC构建块[RFC5052]。
FLUTE can be used with both multicast and unicast delivery, but its primary application is for unidirectional multicast file delivery. FLUTE requires connectivity between a sender and receivers but does not require connectivity from receivers to a sender. Because of its low expectations, FLUTE works with most types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks.
FLUTE可用于多播和单播传输，但其主要应用是单向多播文件传输。FLUTE需要发送方和接收方之间的连接，但不需要从接收方到发送方的连接。由于期望值较低，长笛适用于大多数类型的网络，包括局域网、广域网、内部网、互联网、非对称网络、无线网络和卫星网络。
FLUTE is compatible with both IPv4 and IPv6, as no part of the packet is IP version specific. FLUTE works with both multicast models: Any-Source Multicast (ASM) [RFC1112] and Source-Specific Multicast (SSM) [PAPER.SSM].
FLUTE与IPv4和IPv6都兼容，因为数据包的任何部分都不是特定于IP版本的。FLUTE同时适用于两种多播模型：任意源多播（ASM）[RFC1112]和源特定多播（SSM）[PAPER.SSM]。
FLUTE is applicable for both shared networks, such as the Internet, with a suitable congestion control building block; and provisioned/ controlled networks, such as wireless broadcast radio systems, with a traffic-shaping building block.
长笛适用于两个共享网络，如互联网，具有合适的拥塞控制构建块；以及具有业务整形构建块的供应/控制网络，例如无线广播无线电系统。
FLUTE congestion control protocols depend on the ability of a receiver to change multicast subscriptions between multicast groups supporting different rates and/or layered codings. If the network does not support this, then the FLUTE congestion control protocols may not be amenable to such a network.
长笛拥塞控制协议依赖于接收器在支持不同速率和/或分层编码的多播组之间更改多播订阅的能力。如果网络不支持这一点，那么长笛拥塞控制协议可能不适合这样的网络。
FLUTE can also be used for point-to-point (unicast) communications. At a minimum, implementations of ALC MUST support the Wave and Equation Based Rate Control (WEBRC) [RFC3738] multiple-rate congestion control scheme [RFC5775]. However, since WEBRC has been designed for massively scalable multicast flows, it is not clear how appropriate it is to the particular case of unicast flows. Using a separate point-to-point congestion control scheme is another alternative. How to do that is outside the scope of the present document.
长笛也可用于点对点（单播）通信。ALC的实现至少必须支持基于波动和方程的速率控制（WEBRC）[RFC3738]多速率拥塞控制方案[RFC5775]。然而，由于WEBRC是为大规模可伸缩的多播流设计的，因此不清楚它对于单播流的特定情况有多合适。使用单独的点到点拥塞控制方案是另一种选择。如何做到这一点超出了本文件的范围。
FLUTE provides reliability using the FEC building block. This will reduce the error rate as seen by applications. However, FLUTE does not provide a method for senders to verify the reception success of receivers, and the specification of such a method is outside the scope of this document.
FLUTE使用FEC构建块提供可靠性。这将降低应用程序所看到的错误率。然而，FLUTE并未为发送方提供验证接收方接收成功的方法，此类方法的规范不在本文件范围内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terms "object" and "transmission object" are consistent with the definitions in ALC [RFC5775] and LCT [RFC5651]. The terms "file" and "source object" are pseudonyms for "object".
术语“对象”和“传输对象”与ALC[RFC5775]和LCT[RFC5651]中的定义一致。术语“文件”和“源对象”是“对象”的笔名。
Asynchronous Layered Coding [RFC5775] is a protocol designed for delivery of arbitrary binary objects. It is especially suitable for massively scalable, unidirectional multicast distribution. ALC provides the basic transport for FLUTE, and thus FLUTE inherits the requirements of ALC.
异步分层编码[RFC5775]是一种为传送任意二进制对象而设计的协议。它特别适用于大规模可扩展的单向多播分发。ALC为Sleet提供了基本的传输，因此Sleet继承了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.
举个例子，让我们考虑一个5200字节的文件。http://www.example.com/docs/file.txt". 使用该示例，以下属性描述了需要通过文件传递协议传递的属性。
* Identifier of the file, expressed as a URI [RFC3986]. The identifier MAY provide a location for the file. In the above example: "http://www.example.com/docs/file.txt".
* 文件的标识符，表示为URI[RFC3986]。标识符可以提供文件的位置。在上面的示例中：http://www.example.com/docs/file.txt".
* File name (usually, this can be concluded from the URI). In the above example: "file.txt".
* 文件名（通常可以从URI得出结论）。在上面的示例中：“file.txt”。
* File type, expressed as Internet Media Types (often referred to as "Media Types"). In the above example: "text/plain".
* 文件类型，表示为Internet媒体类型（通常称为“媒体类型”）。在上面的示例中：“text/plain”。
* File size, expressed in octets. In the above example: "5200". If the file is content encoded, then this is the file size before content encoding.
* 文件大小，以八位字节表示。在上面的例子中：“5200”。如果文件是内容编码的，则这是内容编码之前的文件大小。
* Content encoding of the file, within transport. In the above example, the file could be encoded using ZLIB [RFC1950]. In this case, the size of the transmission object carrying the file would probably differ from the file size. The transmission object size is delivered to receivers as part of the FLUTE protocol.
* 传输中文件的内容编码。在上面的示例中，可以使用ZLIB[RFC1950]对文件进行编码。在这种情况下，承载文件的传输对象的大小可能与文件大小不同。传输对象大小作为FLUTE协议的一部分传递给接收器。
* Security properties of the file, such as digital signatures, message digests, etc. For example, one could use S/MIME [RFC5751] as the content encoding type for files with this authentication wrapper, and one could use XML Digital Signatures (XML-DSIG) [RFC3275] to digitally sign the file. XML-DSIG can also be used to provide tamper prevention, e.g., in the Content-Location field. Content encoding is applied to file data before FEC protection.
* 文件的安全属性，如数字签名、消息摘要等。例如，可以使用S/MIME[RFC5751]作为具有此身份验证包装器的文件的内容编码类型，也可以使用XML数字签名（XML-DSIG）[RFC3275]对文件进行数字签名。XML-DSIG还可用于提供篡改预防，例如在内容位置字段中。内容编码在FEC保护之前应用于文件数据。
For each unique file, FLUTE encodes the attributes listed above and other attributes as children of an XML file element. A table of XML file elements is transmitted as a special file called a 'File Delivery Table' (FDT), which is further described in the next subsection and in Section 3.2.
对于每个唯一的文件，FLUTE将上面列出的属性和其他属性编码为XML文件元素的子元素。XML文件元素表作为一个称为“文件传递表”（FDT）的特殊文件进行传输，下一小节和第3.2节将对此进行进一步描述。
ALC is a protocol instantiation of the Layered Coding Transport (LCT) building block [RFC5651]. Thus, ALC inherits the session concept of LCT. In this document, we will use the concept of the ALC/LCT session to collectively denote the interchangeable terms "ALC session" and "LCT session".
ALC是分层编码传输（LCT）构造块[RFC5651]的协议实例。因此，ALC继承了LCT的会话概念。在本文件中，我们将使用ALC/LCT会话的概念来共同表示可互换术语“ALC会话”和“LCT会话”。
An ALC/LCT session consists of a set of logically grouped ALC/LCT channels associated with a single sender sending ALC/LCT packets for one or more objects. An ALC/LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel.
ALC/LCT会话由一组逻辑分组的ALC/LCT通道组成，这些通道与为一个或多个对象发送ALC/LCT数据包的单个发送方关联。ALC/LCT信道由发送方和发送方与信道关联的地址的组合定义。接收机加入信道以开始接收发送方发送到信道的数据包，接收机离开信道以停止从信道接收数据包。
One of the fields carried in the ALC/LCT header is the Transport Session Identifier (TSI), an integer carried in a field of size 16, 32, or 48 bits (note that the TSI may be carried by other means, in which case it is absent from the LCT header [RFC5651]). The (source IP address, TSI) pair uniquely identifies a session. Note that the TSI is scoped by the IP address, so the same TSI may be used by several source IP addresses at once. Thus, the receiver uses the (source IP address, TSI) pair from each packet to uniquely identify the session sending each packet. When a session carries multiple objects, the Transmission Object Identifier (TOI) field within the ALC/LCT header names the object used to generate each packet. Note that each object is associated with a unique TOI within the scope of a session.
ALC/LCT报头中携带的字段之一是传输会话标识符（TSI），一个在大小为16、32或48位的字段中携带的整数（注意，TSI可以通过其他方式携带，在这种情况下，它不在LCT报头[RFC5651]）。（源IP地址，TSI）对唯一标识会话。请注意，TSI的作用域是由IP地址确定的，因此同一TSI可以同时由多个源IP地址使用。因此，接收机使用来自每个分组的（源IP地址，TSI）对来唯一地标识发送每个分组的会话。当会话承载多个对象时，ALC/LCT报头中的传输对象标识符（TOI）字段命名用于生成每个数据包的对象。请注意，每个对象都与会话范围内的唯一TOI相关联。
A FLUTE session consistent with this specification MUST use FLUTE version 2 as specified in this document. Thus, all sessions consistent with this specification MUST set the FLUTE version to 2. The FLUTE version is carried within the EXT_FDT Header Extension (defined in Section 3.4.1) in the ALC/LCT layer. A FLUTE session consistent with this specification MUST use ALC version 1 as specified in [RFC5775], and LCT version 1 as specified in [RFC5651].
符合本规范的长笛会话必须使用本文件规定的长笛版本2。因此，符合本规范的所有会话必须将长笛版本设置为2。长笛版本在ALC/LCT层的EXT_FDT头延伸（定义见第3.4.1节）内进行。符合本规范的长笛会话必须使用[RFC5775]中规定的ALC版本1和[RFC5651]中规定的LCT版本1。
If multiple FLUTE sessions are sent to a channel, then receivers MUST determine the FLUTE protocol version, based on version fields and the (source IP address, TSI) pair carried in the ALC/LCT header of the packet. Note that when a receiver first begins receiving packets, it
如果多个长笛会话被发送到一个信道，那么接收机必须根据版本字段和数据包的ALC/LCT报头中携带的（源IP地址，TSI）对来确定长笛协议的版本。请注意，当接收器第一次开始接收数据包时
might not know the FLUTE protocol version, as not every LCT packet carries the EXT_FDT header (containing the FLUTE protocol version). A new receiver MAY keep an open binding in the LCT protocol layer between the TSI and the FLUTE protocol version, until the EXT_FDT header arrives. Alternatively, a new receiver MAY discover a binding between TSI and FLUTE protocol version via a session discovery protocol that is out of scope of this document.
可能不知道FLUTE协议版本，因为并非每个LCT数据包都携带EXT_FDT头（包含FLUTE协议版本）。新的接收器可以在TSI和FLUTE协议版本之间的LCT协议层中保持开放绑定，直到EXT_FDT报头到达。或者，新的接收器可以通过超出本文档范围的会话发现协议来发现TSI和长笛协议版本之间的绑定。
If the sender's IP address is not accessible to receivers, then packets that can be received by receivers contain an intermediate IP address. In this case, the TSI is scoped by this intermediate IP address of the sender for the duration of the session. As an example, the sender may be behind a Network Address Translation (NAT) device that temporarily assigns an IP address for the sender. In this case, the TSI is scoped by the intermediate IP address assigned by the NAT. As another example, the sender may send its original packets using IPv6, but some portions of the network may not be IPv6 capable. Thus, there may be an IPv6-to-IPv4 translator that changes the IP address of the packets to a different IPv4 address. In this case, receivers in the IPv4 portion of the network will receive packets containing the IPv4 address, and thus the TSI for them is scoped by the IPv4 address. How the IP address of the sender to be used to scope the session by receivers is delivered to receivers, whether it is the sender's IP address or an intermediate IP address, is outside the scope of this document.
如果接收方无法访问发送方的IP地址，则接收方可以接收的数据包包含一个中间IP地址。在这种情况下，TSI在会话期间由发送方的这个中间IP地址确定范围。例如，发送方可能位于临时为发送方分配IP地址的网络地址转换（NAT）设备后面。在这种情况下，TSI的作用域是NAT分配的中间IP地址。作为另一示例，发送方可以使用IPv6发送其原始分组，但是网络的某些部分可能不支持IPv6。因此，可能存在将数据包的IP地址更改为不同IPv4地址的IPv6到IPv4转换器。在这种情况下，网络IPv4部分中的接收器将接收包含IPv4地址的数据包，因此它们的TSI由IPv4地址限定。如何将发送方的IP地址（无论是发送方的IP地址还是中间IP地址）传递给接收方以确定接收方会话的范围不在本文档的范围之内。
When FLUTE is used for file delivery over ALC, the ALC/LCT session is called a file delivery session, and the ALC/LCT concept of 'object' denotes either a 'file' or a 'File Delivery Table Instance' (Section 3.2).
当FLUTE用于通过ALC进行文件传递时，ALC/LCT会话称为文件传递会话，“对象”的ALC/LCT概念表示“文件”或“文件传递表实例”（第3.2节）。
Additionally, the following rules apply:
此外，以下规则适用：
* The TOI field MUST be included in ALC packets sent within a FLUTE session, with the exception that ALC packets sent in a FLUTE session with the Close Session (A) flag set to 1 (signaling the end of the session) and that contain no payload (carrying no information for any file or FDT) SHALL NOT carry the TOI. See Section 5.1 of [RFC5651] for the LCT definition of the Close Session flag, and see Section 4.2 of [RFC5775] for an example of the use of a TOI within an ALC packet.
* TOI字段必须包含在长笛会话中发送的ALC数据包中，但在长笛会话中发送的ALC数据包（关闭会话（a）标志设置为1（表示会话结束）且不包含有效负载（不包含任何文件或FDT的信息）不得携带TOI。有关关闭会话标志的LCT定义，请参见[RFC5651]的第5.1节；有关ALC数据包中TOI的使用示例，请参见[RFC5775]的第4.2节。
* The TOI value '0' is reserved for the delivery of File Delivery Table Instances. Each non-expired File Delivery Table Instance is uniquely identified by an FDT Instance ID within the EXT_FDT header defined in Section 3.4.1.
* TOI值“0”保留用于传递文件传递表实例。每个未过期的文件传递表实例由第3.4.1节定义的EXT_FDT头中的FDT实例ID唯一标识。
* Each file in a file delivery session MUST be associated with a TOI (>0) in the scope of that session.
* 文件传递会话中的每个文件都必须与该会话范围内的TOI（>0）相关联。
* Information carried in the headers and the payload of a packet is scoped by the source IP address and the TSI. Information particular to the object carried in the headers and the payload of a packet is further scoped by the TOI for file objects, and is further scoped by both the TOI and the FDT Instance ID for FDT Instance objects.
* 数据包的报头和有效载荷中携带的信息由源IP地址和TSI限定范围。对于文件对象，报头中携带的特定于对象的信息和数据包的有效载荷由TOI进一步限定范围，对于FDT实例对象，由TOI和FDT实例ID进一步限定范围。
The File Delivery Table (FDT) provides a means to describe various attributes associated with files that are to be delivered within the file delivery session. The following lists are examples of such attributes and are not intended to be mutually exclusive or exhaustive.
文件传递表（FDT）提供了一种方法来描述与文件传递会话中要传递的文件相关联的各种属性。以下列表是此类属性的示例，并非相互排斥或详尽无遗。
Attributes related to the delivery of a file:
与文件传递相关的属性：
- TOI value that represents the file
- 表示文件的TOI值
- FEC Object Transmission Information (including the FEC Encoding ID and, if relevant, the FEC Instance ID)
- FEC对象传输信息（包括FEC编码ID和FEC实例ID（如果相关））
- Size of the transmission object carrying the file
- 承载文件的传输对象的大小
- Aggregate rate of sending packets to all channels
- 向所有通道发送数据包的聚合速率
Attributes related to the file itself:
与文件本身相关的属性：
- Name, Identification, and Location of file (specified by the URI)
- 文件的名称、标识和位置（由URI指定）
- Media type of file
- 文件的媒体类型
- Size of file
- 文件大小
- Encoding of file
- 文件编码
- Message digest of file
- 文件的消息摘要
Some of these attributes MUST be included in the file description entry for a file; others are optional, as defined in Section 3.4.2.
其中一些属性必须包含在文件的文件描述条目中；如第3.4.2节所定义，其他为可选。
Logically, the FDT is a set of file description entries for files to be delivered in the session. Each file description entry MUST include the TOI for the file that it describes and the URI identifying the file. The TOI carried in each file description entry
从逻辑上讲，FDT是会话中要传递的文件的一组文件描述条目。每个文件描述条目必须包括它所描述的文件的TOI和标识该文件的URI。每个文件描述条目中包含的TOI
is how FLUTE names the ALC/LCT data packets used for delivery of the file. Each file description entry may also contain one or more descriptors that map the above-mentioned attributes to the file.
是FLUTE如何命名用于传递文件的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, other than the FDT itself, is not considered a 'file' belonging to the file delivery session. This object received with an unmapped TOI (non-zero TOI that is not resolved by the FDT) SHOULD in general be ignored by a FLUTE receiver. The details of how to do that are out of scope of this specification.
每个文件传递会话必须具有给定会话本地的FDT。FDT必须为会话中出现的每个文件提供映射到TOI的文件描述条目。在ALC会话中传递但FDT中未描述的对象（FDT本身除外）不被视为属于文件传递会话的“文件”。使用未映射TOI（FDT未解析的非零TOI）接收的该对象通常应被长笛接收器忽略。有关如何执行此操作的详细信息超出本规范的范围。
Note that a client that joins an active file delivery session MAY receive data packets for a TOI > 0 before receiving any FDT Instance (see Section 3.3 for recommendations on how to limit the probability that this situation will occur). Even if the TOI is not mapped to any file description entry, this is hopefully a transient situation. When this happens, system performance might be improved by caching such packets within a reasonable time window and storage size. Such optimizations are use-case and implementation specific, and further details are beyond the scope of this document.
请注意，加入活动文件传递会话的客户端可能会在接收任何FDT实例之前接收TOI>0的数据包（有关如何限制这种情况发生的可能性的建议，请参阅第3.3节）。即使TOI没有映射到任何文件描述条目，这也可能是暂时的情况。发生这种情况时，可以通过在合理的时间窗口和存储大小内缓存此类数据包来提高系统性能。此类优化是特定于用例和实现的，进一步的细节超出了本文档的范围。
Within the file delivery session, the FDT is delivered as FDT Instances. An FDT Instance contains one or more file description entries of the FDT. Any FDT Instance can be equal to, be a subset of, be a superset of, overlap with, or complement any other FDT Instance. A certain FDT Instance may be repeated multiple times during a session, even after subsequent FDT Instances (with higher FDT Instance ID numbers) have been transmitted. Each FDT Instance contains at least a single file description entry and at most the exhaustive set of file description entries of the files being delivered in the file delivery session.
在文件传递会话中，FDT作为FDT实例传递。FDT实例包含FDT的一个或多个文件描述条目。任何FDT实例都可以等于、是任何其他FDT实例的子集、超集、重叠或补充。某个FDT实例可能在会话期间重复多次，即使在随后的FDT实例（具有更高的FDT实例ID号）被传输之后也是如此。每个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 the FDT database is an abstract concept, the structure and the maintenance of the FDT database are left to individual implementations and are thus out of scope of this specification.
由于FDT数据库是一个抽象概念，因此FDT数据库的结构和维护由单独的实现来决定，因此超出了本规范的范围。
The following rules define the dynamics of the FDT Instances within a file delivery session:
以下规则定义文件传递会话中FDT实例的动态：
* For every file delivered within a file delivery session, there MUST be a file description entry included in at least one FDT Instance sent within the session. A file description entry contains at a minimum the mapping between the TOI and the URI.
* 对于在文件传递会话中传递的每个文件，必须在会话中发送的至少一个FDT实例中包含一个文件描述条目。文件描述条目至少包含TOI和URI之间的映射。
* An FDT Instance MAY appear in any part of the file delivery session, and packets for an FDT Instance MAY be interleaved with packets for other files or other FDT Instances within a session.
* FDT实例可出现在文件递送会话的任何部分中，并且FDT实例的分组可与会话内的其他文件或其他FDT实例的分组交错。
* The TOI value of '0' MUST be reserved for delivery of FDT Instances. The use of other TOI values (i.e., an integer > 0) for FDT Instances is outside the scope of this specification.
* 必须保留“0”的TOI值以传递FDT实例。FDT实例使用其他TOI值（即大于0的整数）超出本规范的范围。
* The FDT Instance is identified by the use of a new fixed-length LCT Header Extension, EXT_FDT (defined later in this section). Each non-expired FDT Instance is uniquely identified within the file delivery session by its FDT Instance ID, carried by the EXT_FDT Header Extension. Any ALC/LCT packet carrying an FDT Instance MUST include EXT_FDT.
* FDT实例通过使用新的固定长度LCT头扩展EXT_FDT（本节稍后定义）来识别。每个未过期的FDT实例在文件传递会话中通过其FDT实例ID（由EXT_FDT头扩展名携带）进行唯一标识。任何携带FDT实例的ALC/LCT数据包必须包含EXT_FDT。
* It is RECOMMENDED that an FDT Instance that contains the file description entry for a file be sent at least once before sending the described file within a file delivery session. This recommendation is intended to minimize the amount of file data that may be received by receivers in advance of the FDT Instance containing the entry for a file (such data must either be speculatively buffered or discarded). Note that this possibility cannot be completely eliminated, since the first transmission of FDT data might be lost.
* 建议在文件传递会话中发送所述文件之前，至少发送一次包含文件描述条目的FDT实例。本建议旨在最大限度地减少接收器在包含文件条目的FDT实例之前可能接收到的文件数据量（此类数据必须被推测性缓冲或丢弃）。请注意，这种可能性无法完全消除，因为FDT数据的第一次传输可能会丢失。
* Within a file delivery session, any TOI > 0 MAY be described more than once. For example, a previous FDT Instance 0 describes a TOI of value '3'. Now, subsequent FDT Instances can either keep TOI '3' unmodified in the table, not include it, or augment the description. However, subsequent FDT Instances MUST NOT change the parameters already described for a specific TOI.
* 在文件传递会话中，任何TOI>0都可以被描述多次。例如，先前的FDT实例0描述了值为“3”的TOI。现在，后续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 UTF-8 decimal representation of a 32-bit unsigned integer. The value of this integer represents the 32 most significant bits of a 64-bit Network Time Protocol (NTP) [RFC5905] time value. These 32 bits provide an unsigned integer representing the time in
* FDT实例在其过期之前是有效的。失效时间在FDT实例有效负载中表示为32位无符号整数的UTF-8十进制表示。此整数的值表示64位网络时间协议（NTP）[RFC5905]时间值的32个最高有效位。这32位提供了一个表示时间的无符号整数
seconds relative to 0 hours 1 January 1900 in the case of the prime epoch (era 0) [RFC5905]. The handling of time wraparound (to happen in 2036) requires that the associated epoch be considered. In any case, both a sender and a receiver easily determine to which (136-year) epoch the FDT Instance expiration time value pertains by choosing the epoch for which the expiration time is closest in time to the current time.
对于主纪元（纪元0），相对于1900年1月1日0小时的秒数[RFC5905]。时间环绕（将于2036年发生）的处理需要考虑相关的历元。在任何情况下，发送方和接收方都可以通过选择到期时间在时间上最接近当前时间的历元来轻松确定FDT实例到期时间值所属的历元（136年）。
Here is an example. Let us imagine that a new FLUTE session is started on February 7th, 2036, 0h, i.e., at NTP time 4,294,944,000, a few hours before the end of epoch 0. In order to define an FDT Instance valid for the next 48 hours, The FLUTE sender sets an expiry time of 149,504. This FDT Instance will expire exactly on February 9th, 2036, 0h. A client that receives this FDT Instance on the 7th, 0h, just after it has been sent, immediately understands that this value corresponds to epoch 1. A client that joins the session on February 8th, 0h, i.e., at NTP time 63,104, epoch 1, immediately understands that the 149,504 NTP timestamp corresponds to epoch 1.
这里有一个例子。让我们想象一个新的长笛课程在2036年2月7日0点开始，即NTP时间4294944000，在第0纪元结束前几个小时。为了定义在接下来48小时内有效的FDT实例，FLUTE发送器将到期时间设置为149504。此FDT实例将于2036年2月9日0时到期。在第7天0h收到此FDT实例的客户机在发送后立即知道此值对应于历元1。在0小时2月8日（即NTP时间63104，历元1）加入会话的客户端立即了解149504 NTP时间戳对应于历元1。
* The space of FDT Instance IDs is limited by the associated field size (i.e., 20 bits) in the EXT_FDT Header Extension (Section 3.4.1). Therefore, senders should take care to always have a large enough supply of available FDT Instance IDs when specifying FDT expiration times.
* FDT实例ID的空间受到EXT_FDT头扩展（第3.4.1节）中相关字段大小（即20位）的限制。因此，在指定FDT过期时间时，发送方应注意始终提供足够多的可用FDT实例ID。
* The receiver MUST NOT use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance.
* 接收器不得使用接收到的FDT实例来解释FDT实例过期后接收到的数据包。
* A sender MUST use an expiration time in the future upon creation of an FDT Instance relative to its Sender Current Time (SCT).
* 发送方必须在将来创建FDT实例时使用相对于其发送方当前时间（SCT）的过期时间。
* Any FEC Encoding ID MAY be used for the sending of FDT Instances. The default is to use the Compact No-Code FEC Encoding ID 0 [RFC5445] for the sending of FDT Instances. (Note that since FEC Encoding ID 0 is the default for FLUTE, this implies that Source Block Number and Encoding Symbol ID lengths both default to 16 bits each.)
* 任何FEC编码ID均可用于发送FDT实例。默认情况下，使用紧凑的无代码FEC编码ID 0[RFC5445]发送FDT实例。（注意，由于FEC编码ID 0是长笛的默认值，这意味着源块编号和编码符号ID长度都默认为16位。）
* If the receiver does not support the FEC Scheme indicated by the FEC Encoding ID, the receiver MUST NOT decode the associated FDT.
* 如果接收机不支持由FEC编码ID指示的FEC方案，则接收机不得解码相关的FDT。
* It is RECOMMENDED that the mechanisms used for file attribute delivery SHOULD achieve a delivery probability that is higher than the file recovery probability and the file attributes SHOULD be delivered at this higher priority before the delivery of the associated files begins.
* 建议用于文件属性传递的机制的传递概率应高于文件恢复概率，并且在相关文件的传递开始之前，应以更高的优先级传递文件属性。
Generally, a receiver needs to receive an FDT Instance describing a file before it is able to recover the file itself. In this sense, FDT Instances are of higher priority than files. Additionally, a FLUTE sender SHOULD assume that receivers will not receive all packets pertaining to FDT Instances. The way FDT Instances are transmitted has a large impact on satisfying the recommendation above. When there is a single file transmitted in the session, one way to satisfy the recommendation above is to repeatedly transmit on a regular enough basis FDT Instances describing the file while the file is being transmitted. If an FDT Instance is longer than one packet payload in length, it is RECOMMENDED that an FEC code that provides protection against loss be used for delivering this FDT Instance. When there are multiple files in a session concurrently being transmitted to receivers, the way the FDT Instances are structured and transmitted also has a large impact. As an example, a way to satisfy the recommendation above is to transmit an FDT Instance that describes all files currently being transmitted, and to transmit this FDT Instance reliably, using the same techniques as explained for the case when there is a single file transmitted in a session. If instead the concurrently transmitted files are described in separate FDT Instances, another way to satisfy this recommendation is to transmit all the relevant FDT Instances reliably, using the same techniques as explained for the case when there is a single file transmitted in a session.
通常，接收器需要接收描述文件的FDT实例，然后才能恢复文件本身。从这个意义上讲，FDT实例的优先级高于文件。此外，长笛发送方应假设接收方不会接收与FDT实例有关的所有数据包。FDT实例的传输方式对满足上述建议有很大影响。当在会话中传输单个文件时，满足上述建议的一种方法是在传输文件时，在足够规则的基础上重复传输描述该文件的FDT实例。如果FDT实例的长度超过一个数据包有效载荷，建议使用FEC代码来提供该FDT实例的丢失保护。当会话中有多个文件同时传输到接收器时，FDT实例的结构和传输方式也会产生很大的影响。作为示例，满足上述建议的一种方法是传输描述当前正在传输的所有文件的FDT实例，并使用与在会话中传输单个文件时所解释的相同技术可靠地传输该FDT实例。相反，如果在单独的FDT实例中描述并发传输的文件，则满足该建议的另一种方法是使用与在会话中传输单个文件的情况相同的技术可靠地传输所有相关FDT实例。
In any case, how often the description of a file is sent in an FDT Instance, how often an FDT Instance is sent, and how much FEC protection is provided for an FDT Instance (if longer than one packet payload) are dependent on the particular application and are outside the scope of this document.
在任何情况下，文件描述在FDT实例中发送的频率、FDT实例发送的频率以及为FDT实例提供的FEC保护的程度（如果超过一个数据包有效载荷）取决于特定的应用，并且不在本文档的范围内。
Sometimes the various attributes associated with files that are to be delivered within the file delivery session are sent out-of-band. The details of how this is done are out of the scope of this document. However, it is still RECOMMENDED that any out-of-band transmission be managed in such a way that a receiver will be able to recover the attributes associated with a file at least as reliably as the receiver is able to receive enough packets containing encoding symbols to recover the file. For example, the probability of a randomly chosen receiver being able to recover a given file can often be estimated based on a statistical model of reception conditions, the amount of data transmitted, and the properties of any Forward Error Correction in use. The recommendation above suggests that mechanisms used for file attribute delivery should achieve a higher delivery probability than the file recovery probability. The sender MAY also continue sending the various file attributes in-band, in addition to the out-of-band transmission.
有时，与要在文件传递会话中传递的文件相关联的各种属性会被发送到带外。如何完成此操作的详细信息不在本文档的范围内。然而，仍然建议以这样的方式来管理任何带外传输，即接收机将能够恢复与文件相关联的属性，至少与接收机能够接收包含编码符号的足够数据包以恢复文件一样可靠。例如，随机选择的接收机能够恢复给定文件的概率通常可以基于接收条件的统计模型、发送的数据量以及所使用的任何前向纠错的特性来估计。上述建议表明，用于文件属性传递的机制应实现比文件恢复概率更高的传递概率。除了带外传输之外，发送方还可以继续在带内发送各种文件属性。
FDT Instances are carried in ALC packets with TOI = 0 and with an additional REQUIRED LCT Header extension called the FDT Instance Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance ID that uniquely identifies FDT Instances within a file delivery session. Placement of the FDT Instance Header is the same as that of any other LCT Header Extension. There MAY be other LCT Header Extensions in use.
FDT实例在TOI=0的ALC数据包中传输，并带有一个称为FDT实例头的额外必需LCT头扩展。FDT实例头（EXT_FDT）包含唯一标识文件传递会话中FDT实例的FDT实例ID。FDT实例头的位置与任何其他LCT头扩展的位置相同。可能正在使用其他LCT标头扩展。
The FDT Instance is encoded for transmission, like any other object, using an FEC Scheme (which MAY be the Compact No-Code FEC Scheme). The LCT Header Extensions are followed by the FEC Payload ID, and finally the Encoding Symbols for the FDT Instance, which contains one or more file description entries. An FDT Instance MAY span several ALC packets -- the number of ALC packets is a function of the file attributes associated with the FDT Instance. The FDT Instance Header is carried in each ALC packet carrying the FDT Instance. The FDT Instance Header is identical for all ALC/LCT packets for a particular FDT Instance.
与任何其他对象一样，FDT实例使用FEC方案（可以是紧凑的无码FEC方案）进行编码以用于传输。LCT头扩展之后是FEC有效负载ID，最后是FDT实例的编码符号，该实例包含一个或多个文件描述条目。FDT实例可能跨越多个ALC数据包——ALC数据包的数量是与FDT实例相关联的文件属性的函数。FDT实例报头携带在携带FDT实例的每个ALC包中。对于特定FDT实例的所有ALC/LCT数据包，FDT实例头是相同的。
The overall format of ALC/LCT packets carrying an FDT Instance is depicted in Figure 1 below. All integer fields are carried in "big-endian" or "network order" format (i.e., most significant byte (octet) first). As defined in [RFC5775], all ALC/LCT packets are sent using UDP.
下面的图1描述了携带FDT实例的ALC/LCT数据包的总体格式。所有整数字段都以“big-endian”或“network-order”格式（即，最高有效字节（octet）优先）携带。如[RFC5775]中所定义，所有ALC/LCT数据包都使用UDP发送。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT Header Extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FLUTE Payload: Encoding Symbol(s)
~ (for FDT Instance in an FDT packet) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT Header Extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FLUTE Payload: Encoding Symbol(s)
~ (for FDT Instance in an FDT packet) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Overall FDT Packet
图1：总体FDT数据包
The FDT Instance Header (EXT_FDT) is a new fixed-length, ALC Protocol-Instantiation-specific LCT Header Extension [RFC5651]. The Header Extension Type (HET) for the extension is 192. Its format is defined below:
FDT实例头（EXT_FDT）是一种新的固定长度、ALC协议实例化特定LCT头扩展[RFC5651]。扩展的头扩展类型（HET）为192。其格式定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EXT_FDT Format
图2:EXT_FDT格式
Version of FLUTE (V), 4 bits:
长笛版本（V），4位：
This document specifies FLUTE version 2. Hence, in any ALC packet that carries an FDT Instance and that belongs to the file delivery session as specified in this specification MUST set this field to '2'.
本文件规定了长笛版本2。因此，在任何携带FDT实例且属于本规范中指定的文件传递会话的ALC数据包中，必须将此字段设置为“2”。
FDT Instance ID, 20 bits:
FDT实例ID，20位：
For each file delivery session, the numbering of FDT Instances starts from '0' and is incremented by one for each subsequent FDT Instance. After reaching the maximum value (2^20-1), the numbering starts from the smallest FDT Instance ID value assigned to an expired FDT Instance. When wraparound from a greater FDT Instance ID value to a smaller FDT Instance ID value occurs, the smaller FDT Instance ID value is considered logically higher than the greater FDT Instance ID value. Then, the subsequent FDT Instances are assigned the next available smallest FDT Instance ID value, in order to always keep the FDT Instance ID values logically increasing.
对于每个文件传递会话，FDT实例的编号从“0”开始，并为每个后续FDT实例增加一个。达到最大值（2^20-1）后，编号从指定给过期FDT实例的最小FDT实例ID值开始。当从较大的FDT实例ID值概括为较小的FDT实例ID值时，在逻辑上认为较小的FDT实例ID值高于较大的FDT实例ID值。然后，为后续FDT实例分配下一个可用的最小FDT实例ID值，以便始终保持FDT实例ID值在逻辑上不断增加。
Senders MUST NOT reuse an FDT Instance ID value that is already in use for a non-expired FDT Instance. Sender behavior when all the FDT Instance IDs are used by non-expired FEC Instances is outside the scope of this specification and left to individual implementations of FLUTE. Receipt of an FDT Instance that reuses an FDT Instance ID value that is currently used by a non-expired FDT Instance MUST be considered an error case. Receiver behavior in this case (e.g., leave the session or ignore the new FDT Instance) is outside the scope of this specification and left to individual implementations of FLUTE. Receivers MUST be ready to handle FDT Instance ID wraparound and situations where missing FDT Instance IDs result in increments larger than one.
发送方不得重用已用于未过期FDT实例的FDT实例ID值。未过期的FEC实例使用所有FDT实例ID时的发送方行为不在本规范的范围内，由FLUTE的单独实现决定。接收到重用未过期FDT实例当前使用的FDT实例ID值的FDT实例必须视为错误情况。这种情况下的接收器行为（例如，离开会话或忽略新的FDT实例）不在本规范的范围内，由FLUTE的单独实现决定。接收器必须准备好处理FDT实例ID环绕以及缺少FDT实例ID导致增量大于1的情况。
The FDT Instance contains file description entries that provide the mapping functionality described in Section 3.2 above.
FDT实例包含提供上文第3.2节所述映射功能的文件描述条目。
The FDT Instance is an Extensible Markup Language (XML) structure that has a single root element "FDT-Instance". The "FDT-Instance" element MUST contain the "Expires" attribute, which provides the expiration time of the FDT Instance. In addition, the "FDT-Instance" element MAY contain the "Complete" attribute, a boolean that can be either set to '1' or 'true' for TRUE, or '0' or 'false' for FALSE. When TRUE, the "Complete" attribute signals that this "FDT Instance" includes the set of "File" entries that exhausts both the set of files delivered so far and the set of files to be delivered in the session. This implies that no new data will be provided in future FDT Instances within this session (i.e., that either FDT Instances with higher ID numbers will not be used or, if they are used, will only provide file parameters identical to those already given in this and previous FDT Instances). The "Complete" attribute is therefore used to provide a complete list of files in an entire FLUTE session (a "complete FDT"). Note that when all the FDT Instances received so far have no "Complete" attribute, the receiver MUST consider that the session is not complete and that new data MAY be provided in future FDT Instances. This is equivalent to receiving FDT Instances having the "Complete" attribute set to FALSE.
FDT实例是一种可扩展标记语言（XML）结构，它有一个根元素“FDT实例”。“FDT Instance”元素必须包含“Expires”属性，该属性提供FDT实例的过期时间。此外，“FDT Instance”元素可能包含“Complete”属性，该布尔值可以设置为“1”或“true”表示true，或设置为“0”或“false”表示false。如果为TRUE，“Complete”属性表示该“FDT实例”包括一组“File”条目，该条目将用尽目前为止交付的文件集和会话中要交付的文件集。这意味着在本次会话的未来FDT实例中不会提供新数据（即，不会使用ID号更高的FDT实例，或者如果使用，将只提供与本次和以前FDT实例中已给出的文件参数相同的文件参数）。因此，“Complete”属性用于提供整个长笛会话中文件的完整列表（“Complete FDT”）。注意，当到目前为止接收到的所有FDT实例都没有“完整”属性时，接收方必须考虑会话不完整，并且可以在将来的FDT实例中提供新的数据。这相当于接收将“Complete”属性设置为FALSE的FDT实例。
The "FDT-Instance" element MAY contain attributes that give common parameters for all files of an FDT Instance. These attributes MAY also be provided for individual files in the "File" element. Where the same attribute appears in both the "FDT-Instance" and the "File" elements, the value of the attribute provided in the "File" element takes precedence.
“FDT实例”元素可能包含为FDT实例的所有文件提供公共参数的属性。还可以为“File”元素中的单个文件提供这些属性。如果相同属性同时出现在“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实例中只有一个文件描述条目。每个条目由元素“File”表示，它是FDT实例结构的子元素。
The attributes of the "File" element in the XML structure represent the attributes given to the file that is delivered in the file delivery session. The value of the XML attribute name corresponds to the MIME field name, and the XML attribute value corresponds to the value of the MIME field body [RFC2045]. Each "File" element MUST contain at least two attributes: "TOI" and "Content-Location". "TOI" MUST be assigned a valid TOI value as described in Section 3.3. "Content-Location" [RFC2616] MUST be assigned a syntactically valid URI, as defined in [RFC3986], which identifies the file to be delivered. For example, it can be a URI with the "http" or "file"
XML结构中“File”元素的属性表示在文件传递会话中传递的文件的属性。XML属性名的值对应于MIME字段名，XML属性值对应于MIME字段正文的值[RFC2045]。每个“文件”元素必须至少包含两个属性：“TOI”和“内容位置”。必须按照第3.3节所述为“TOI”分配有效的TOI值。“内容位置”[RFC2616]必须分配一个语法有效的URI，如[RFC3986]中所定义，该URI标识要传递的文件。例如，它可以是带有“http”或“file”的URI
URI scheme. Only one "Content-Location" attribute is allowed for each file. The "Content-Location" field MUST be considered a string that identifies a file (i.e., two different strings are two different identifiers). Any use of the "Content-Location" field for anything else other than to identify the object is out of scope of this specification. The semantics for any two "File" elements declaring the same "Content-Location" but differing "TOI" is that the element appearing in the FDT Instance with the greater FDT Instance ID is considered to declare a newer instance (e.g., version) of the same "File".
URI方案。每个文件只允许有一个“内容位置”属性。“内容位置”字段必须被视为标识文件的字符串（即，两个不同的字符串是两个不同的标识符）。将“内容位置”字段用于除标识对象以外的任何其他用途都不在本规范的范围内。声明相同“内容位置”但不同“TOI”的任何两个“文件”元素的语义是，出现在FDT实例中具有更大FDT实例ID的元素被视为声明相同“文件”的较新实例（例如，版本）。
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实例”元素和“文件”元素还可能包含其他属性，具体指出以下属性：
* The attribute "Content-Type" SHOULD be included and, when present, MUST be used for the purpose defined in [RFC2616].
* 应包括“内容类型”属性，如果存在，则必须用于[RFC2616]中定义的目的。
* Where the length is described, the attribute "Content-Length" MUST be used for the purpose defined in [RFC2616]. The transfer length is defined to be the length of the object transported in octets. It is often important to convey the transfer length to receivers, because the source block structure needs to be known for the FEC decoder to be applied to recover source blocks of the file, and the transfer length is often needed to properly determine the source block structure of the file. There generally will be a difference between the length of the original file and the transfer length if content encoding is applied to the file before transport, and thus the "Content-Encoding" attribute is used. If the file is not content encoded before transport (and thus the "Content-Encoding" attribute is not used), then the transfer length is the length of the original file, and in this case the "Content-Length" is also the transfer length. However, if the file is content encoded before transport (and thus the "Content-Encoding" attribute is used), e.g., if compression is applied before transport to reduce the number of octets that need to be transferred, then the transfer length is generally different than the length of the original file, and in this case the attribute "Transfer-Length" MAY be used to carry the transfer length.
* 如果描述了长度，则属性“内容长度”必须用于[RFC2616]中定义的目的。传输长度定义为以八位字节为单位传输的对象的长度。将传输长度传递给接收机通常很重要，因为要应用FEC解码器来恢复文件的源块，需要知道源块结构，并且通常需要传输长度来正确确定文件的源块结构。如果在传输之前对文件应用内容编码，则原始文件的长度和传输长度之间通常会有差异，因此使用“内容编码”属性。如果文件在传输之前未进行内容编码（因此未使用“内容编码”属性），则传输长度为原始文件的长度，在这种情况下，“内容长度”也是传输长度。然而，如果文件在传输之前进行内容编码（因此使用“内容编码”属性），例如，如果在传输之前应用压缩以减少需要传输的八位字节数，则传输长度通常不同于原始文件的长度，在这种情况下，属性“传输长度”可用于承载传输长度。
* Whenever content encoding is applied, the attribute "Content-Encoding" MUST be included. Whenever the attribute "Content-Encoding" is included, it MUST be used as described in [RFC2616].
* 无论何时应用内容编码，都必须包括“内容编码”属性。每当包含属性“内容编码”时，必须按照[RFC2616]中的说明使用该属性。
* Where the MD5 message digest is described, the attribute "Content-MD5" MUST be used for the purpose defined in [RFC2616]. Note that the goal is to provide a decoded object integrity service in cases where transmission and/or FLUTE/ALC processing errors may occur (the probability of collision is in that case negligible). It MUST NOT be regarded as a security mechanism (see Section 7 for information regarding security measures).
* 如果描述了MD5消息摘要，则属性“Content-MD5”必须用于[RFC2616]中定义的目的。注意，目标是在可能发生传输和/或长笛/ALC处理错误的情况下提供解码对象完整性服务（在这种情况下，碰撞的概率可以忽略不计）。不得将其视为安全机制（有关安全措施的信息，请参见第7节）。
* The FEC Object Transmission Information attributes are described in Section 5.
* FEC对象传输信息属性在第5部分中描述。
The following specifies the XML Schema [XML-Schema-Part-1] [XML-Schema-Part-2] for the FDT Instance:
以下内容指定FDT实例的XML模式[XML-Schema-Part-1][XML-Schema-Part-2]：
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:ietf:params:xml:ns:fdt"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:fdt"
elementFormDefault="qualified">
<xs:element name="FDT-Instance" type="FDT-InstanceType"/>
<xs:complexType name="FDT-InstanceType">
<xs:sequence>
<xs:element name="File" type="FileType" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Expires"
type="xs:string"
use="required"/>
<xs:attribute name="Complete"
type="xs:boolean"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:ietf:params:xml:ns:fdt"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:fdt"
elementFormDefault="qualified">
<xs:element name="FDT-Instance" type="FDT-InstanceType"/>
<xs:complexType name="FDT-InstanceType">
<xs:sequence>
<xs:element name="File" type="FileType" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Expires"
type="xs:string"
use="required"/>
<xs:attribute name="Complete"
type="xs:boolean"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="FileType">
<xs:sequence>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Content-Location"
type="xs:anyURI"
use="required"/>
<xs:attribute name="TOI"
type="xs:positiveInteger"
use="required"/>
<xs:attribute name="Content-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Transfer-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-MD5"
type="xs:base64Binary"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="FileType">
<xs:sequence>
<xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Content-Location"
type="xs:anyURI"
use="required"/>
<xs:attribute name="TOI"
type="xs:positiveInteger"
use="required"/>
<xs:attribute name="Content-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Transfer-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-MD5"
type="xs:base64Binary"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedByte"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:schema>
END
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Scheme-Specific-Info"
type="xs:base64Binary"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:schema>
END
Figure 3: XML Schema for the FDT Instance
图3:FDT实例的XML模式
Any valid FDT Instance MUST use the above XML Schema. This way, FDT provides extensibility to support private elements and private attributes within the file description entries. Those could be, for example, the attributes related to the delivery of the file (timing, packet transmission rate, etc.). Unsupported private elements and attributes SHOULD be silently ignored by a FLUTE receiver.
任何有效的FDT实例都必须使用上述XML模式。通过这种方式，FDT提供了可扩展性，以支持文件描述条目中的私有元素和私有属性。例如，这些可以是与文件的交付相关的属性（定时、分组传输速率等）。不受支持的私有元素和属性应由长笛接收器静默忽略。
In case the basic FDT XML Schema is extended in terms of new descriptors (attributes or elements), for descriptors applying to a single file, those MUST be placed within the element "File". For descriptors applying to all files described by the current FDT Instance, those MUST be placed within the element "FDT-Instance". It is RECOMMENDED that the new attributes applied in the FDT be in the format of message header fields and be either defined in the HTTP/1.1 specification [RFC2616] or another well-known specification, or in an IANA registry [IANAheaderfields]. However, this specification doesn't prohibit the use of other formats to allow private attributes to be used when interoperability is not a concern.
如果基本FDT XML模式根据新描述符（属性或元素）进行扩展，那么对于应用于单个文件的描述符，这些描述符必须放在元素“file”中。对于应用于当前FDT实例描述的所有文件的描述符，这些描述符必须放在元素“FDT实例”中。建议FDT中应用的新属性采用消息头字段的格式，并在HTTP/1.1规范[RFC2616]或其他知名规范或IANA注册表[IANAheaderfields]中定义。但是，本规范并不禁止在互操作性不受关注的情况下使用其他格式来允许使用私有属性。
The FDT Instance itself MAY be content encoded (e.g., compressed). This specification defines the FDT Instance Content Encoding Header (EXT_CENC). EXT_CENC is a new fixed-length LCT Header Extension [RFC5651]. The Header Extension Type (HET) for the extension is 193. If the FDT Instance is content encoded, EXT_CENC MUST be used to signal the content encoding type. In that case, the EXT_CENC Header Extension MUST be used in all ALC packets carrying the same FDT Instance ID. Consequently, when the EXT_CENC header is used, it MUST be used together with a proper FDT Instance Header (EXT_FDT). Within a file delivery session, FDT Instances that are not content encoded and FDT Instances that are content encoded MAY both appear. If
FDT实例本身可以是内容编码的（例如，压缩的）。本规范定义了FDT实例内容编码头（EXT_CENC）。EXT_CENC是一种新的固定长度LCT报头扩展[RFC5651]。扩展的标题扩展类型（HET）为193。如果FDT实例是内容编码的，则必须使用EXT_CENC来表示内容编码类型。在这种情况下，所有携带相同FDT实例ID的ALC数据包中都必须使用EXT_CENC报头扩展。因此，使用EXT_CENC报头时，它必须与适当的FDT实例报头（EXT_FDT）一起使用。在文件传递会话中，可能同时出现未进行内容编码的FDT实例和进行内容编码的FDT实例。如果
content encoding is not used for a given FDT Instance, EXT_CENC MUST NOT be used in any packet carrying the FDT Instance. The format of EXT_CENC is defined below:
内容编码不用于给定的FDT实例，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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 193 | CENC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EXT_CENC Format
图4:EXT_CENC格式
Content Encoding Algorithm (CENC), 8 bits:
内容编码算法（CENC），8位：
This field signals the content encoding algorithm used in the FDT Instance payload. This subsection reserves the Content Encoding Algorithm values 0, 1, 2, and 3 for null, ZLIB [RFC1950], DEFLATE [RFC1951], and GZIP [RFC1952], respectively.
此字段表示FDT实例有效负载中使用的内容编码算法。本小节分别为null、ZLIB[RFC1950]、DEFLATE[RFC1951]和GZIP[RFC1952]保留内容编码算法值0、1、2和3。
Reserved, 16 bits:
保留，16位：
This field MUST be set to all '0's. This field MUST be ignored on reception.
此字段必须设置为所有“0”。接收时必须忽略此字段。
The delivered files are carried as transmission objects (identified with TOIs) in the file delivery session. All these objects, including the FDT Instances, MAY be multiplexed in any order and in parallel with each other within a session; i.e., packets for one file may be interleaved with packets for other files or other FDT Instances within a session.
在文件传递会话中，传递的文件作为传输对象（用TOI标识）携带。所有这些对象，包括FDT实例，可以在会话内以任何顺序并彼此并行地复用；i、 例如，一个文件的分组可以与会话内的其他文件或其他FDT实例的分组交织。
Multiple FDT Instances MAY be delivered in a single session using TOI = 0. In this case, it is RECOMMENDED that the sending of a previous FDT Instance SHOULD end before the sending of the next FDT Instance starts. However, due to unexpected network conditions, packets for the FDT Instances might be interleaved. A receiver can determine which FDT Instance a packet contains information about, since the FDT Instances are uniquely identified by their FDT Instance ID carried in the EXT_FDT headers.
可以使用TOI=0在单个会话中交付多个FDT实例。在这种情况下，建议在开始发送下一个FDT实例之前，结束发送前一个FDT实例。然而，由于意外的网络条件，FDT实例的数据包可能是交错的。接收器可以确定数据包包含关于哪个FDT实例的信息，因为FDT实例是由EXT_FDT报头中携带的FDT实例ID唯一标识的。
ALC/LCT has a concept of channels and congestion control. There are four scenarios in which FLUTE is envisioned to be applied.
ALC/LCT具有信道和拥塞控制的概念。有四种情况下，长笛是设想应用。
(a) Use of a single channel and a single-rate congestion control protocol.
(a) 使用单通道和单速率拥塞控制协议。
(b) Use of multiple channels and a multiple-rate congestion control protocol. In this case, the FDT Instances MAY be delivered on more than one channel.
(b) 使用多通道和多速率拥塞控制协议。在这种情况下，FDT实例可以在多个信道上交付。
(c) Use of a single channel without congestion control supplied by ALC, but only when in a controlled network environment where flow/congestion control is being provided by other means.
(c) 使用ALC提供的无拥塞控制的单通道，但仅当在通过其他方式提供流量/拥塞控制的受控网络环境中时。
(d) Use of multiple channels without congestion control supplied by ALC, but only when in a controlled network environment where flow/congestion control is being provided by other means. In this case, the FDT Instances MAY be delivered on more than one channel.
(d) 使用ALC提供的无拥塞控制的多个信道，但仅当在通过其他方式提供流量/拥塞控制的受控网络环境中时。在这种情况下，FDT实例可以在多个信道上交付。
When using just one channel for a file delivery session, as in (a) and (c), the notion of 'prior' and 'after' are intuitively defined for the delivery of objects with respect to their delivery times.
如（a）和（c）中所述，在文件传递会话中仅使用一个通道时，“之前”和“之后”的概念是根据对象的传递时间直观地定义的。
However, if multiple channels are used, as in (b) and (d), it is not straightforward to state that an object was delivered 'prior' to the other. An object may begin to be delivered on one or more of those channels before the delivery of a second object begins. However, the use of multiple channels/layers may mean that the delivery of the second object is completed before the first. This is not a problem when objects are delivered sequentially using a single channel. Thus, if the application of FLUTE has a mandatory or critical requirement that the first transmission object must complete 'prior' to the second one, it is RECOMMENDED that only a single channel be used for the file delivery session.
但是，如果使用了多个通道，如（b）和（d）中所述，则不能直接说明对象是“在”另一个之前交付的。在第二个对象的交付开始之前，可以在一个或多个通道上开始交付对象。然而，使用多个通道/层可能意味着第二对象的交付在第一对象之前完成。当使用单个通道按顺序交付对象时，这不是问题。因此，如果FLUTE的应用具有强制性或关键性要求，即第一个传输对象必须在第二个传输对象之前完成，则建议仅将单个通道用于文件传递会话。
Furthermore, if multiple channels are used, then a receiver joined to the session at a low reception rate will only be joined to the lower layers of the session. Thus, since the reception of FDT Instances is of higher priority than the reception of files (because the reception of files depends on the reception of an FDT Instance describing it), the following are RECOMMENDED:
此外，如果使用多个信道，则以低接收速率加入会话的接收机将仅加入会话的较低层。因此，由于FDT实例的接收比文件的接收具有更高的优先级（因为文件的接收取决于描述它的FDT实例的接收），因此建议如下：
1. The layers to which packets for FDT Instances are sent SHOULD NOT be biased towards those layers to which lower-rate receivers are not joined. For example, it is okay to put all the packets for an FDT Instance into the lowest layer (if this layer carries enough packets to deliver the FDT to higher-rate receivers in a reasonable amount of time), but it is not okay to put all the packets for an FDT Instance into the higher layers that only higher-rate receivers will receive.
1. FDT实例的数据包发送到的层不应偏向低速率接收器未连接到的层。例如，可以将FDT实例的所有数据包放入最低层（如果该层承载足够的数据包，以便在合理的时间内将FDT传送到更高速率的接收器），但不能将FDT实例的所有数据包放入只有更高速率的接收器才能接收的更高层。
2. If FDT Instances are generally longer than one Encoding Symbol in length and some packets for FDT Instances are sent to layers that lower-rate receivers do not receive, an FEC encoding other than Compact No-Code FEC Encoding ID 0 [RFC5445] SHOULD be used to deliver FDT Instances. This is because in this case, even when there is no packet loss in the network, a lower-rate receiver will not receive all packets sent for an FDT Instance.
2. 如果FDT实例的长度通常大于一个编码符号，并且FDT实例的一些数据包被发送到低速率接收器不接收的层，则应使用FEC编码而不是紧凑的无码FEC编码ID 0[RFC5445]来交付FDT实例。这是因为在这种情况下，即使网络中没有分组丢失，低速率接收器也不会接收为FDT实例发送的所有分组。
FLUTE inherits the use of the FEC building block [RFC5052] from ALC. When using FLUTE for file delivery over ALC, the FEC Object Transmission Information MUST be delivered in-band within the file delivery session. There are two methods to achieve this: the use of the ALC-specific LCT Header Extension EXT_FTI [RFC5775] and the use of the FDT. The latter method is specified in this section. The use of EXT_FTI requires repetition of the FEC Object Transmission Information to ensure reception (though not necessarily in every packet) and thus may entail higher overhead than the use of the FDT, but may also provide more timely delivery of the FEC Object Transmission Information.
FLUTE继承了ALC对FEC构建块[RFC5052]的使用。当通过ALC使用FLUTE进行文件传递时，FEC对象传输信息必须在文件传递会话内的频带内传递。有两种方法可以实现这一点：使用ALC专用LCT报头扩展EXT_FTI[RFC5775]和使用FDT。本节规定了后一种方法。使用EXT_FTI需要重复FEC对象传输信息以确保接收（尽管不一定在每个分组中），因此可能需要比使用FDT更高的开销，但也可能提供更及时的FEC对象传输信息的传递。
The receiver of a file delivery session MUST support delivery of FEC Object Transmission Information using EXT_FTI for the FDT Instances carried using TOI value 0. For the TOI values other than 0, the receiver MUST support both methods: the use of EXT_FTI and the use of the FDT.
对于使用TOI值0携带的FDT实例，文件传递会话的接收器必须支持使用EXT_FTI传递FEC对象传输信息。对于除0以外的TOI值，接收器必须支持两种方法：使用EXT_FTI和使用FDT。
The FEC Object Transmission Information that needs to be delivered to receivers MUST be exactly the same whether it is delivered using EXT_FTI or using the FDT (or both). The FEC Object Transmission Information that MUST be delivered to receivers is defined by the FEC Scheme. This section describes the delivery using the FDT.
无论是使用EXT_FTI还是使用FDT（或两者）交付，需要交付给接收机的FEC对象传输信息必须完全相同。必须交付给接收机的FEC对象传输信息由FEC方案定义。本节描述了使用FDT的交付。
The FEC Object Transmission Information regarding a given TOI may be available from several sources. In this case, it is RECOMMENDED that the receiver of the file delivery session prioritize the sources in the following way (in order of decreasing priority).
关于给定TOI的FEC对象传输信息可以从多个源获得。在这种情况下，建议文件传递会话的接收者按以下方式（按优先级降低的顺序）对源进行优先级排序。
1. FEC Object Transmission Information that is available in EXT_FTI.
1. 在EXT_FTI中可用的FEC对象传输信息。
2. FEC Object Transmission Information that is available in the FDT.
2. FDT中可用的FEC对象传输信息。
The FDT delivers FEC Object Transmission Information for each file using an appropriate attribute within the "FDT-Instance" or the "File" element of the FDT structure.
FDT使用FDT结构的“FDT实例”或“文件”元素中的适当属性为每个文件传递FEC对象传输信息。
* "Transfer-Length" carries the "Transfer-Length" Object Transmission Information element defined in [RFC5052].
* “传输长度”携带[RFC5052]中定义的“传输长度”对象传输信息元素。
* "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object Transmission Information element defined in [RFC5052], as carried in the Codepoint field of the ALC/LCT header.
* “FEC OTI FEC编码ID”携带[RFC5052]中定义的“FEC编码ID”对象传输信息元素，如ALC/LCT报头的代码点字段中所携带的。
* "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object Transmission Information element defined in [RFC5052] for Under-Specified FEC Schemes.
* “FEC OTI FEC实例ID”携带[RFC5052]中为指定FEC方案定义的“FEC实例ID”对象传输信息元素。
* "FEC-OTI-Maximum-Source-Block-Length" carries the "Maximum-Source-Block-Length" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.
* 如果FEC方案需要，“FEC OTI最大源块长度”携带[RFC5052]中定义的“最大源块长度”对象传输信息元素。
* "FEC-OTI-Encoding-Symbol-Length" carries the "Encoding-Symbol-Length" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.
* 如果FEC方案需要，“FEC OTI编码符号长度”携带[RFC5052]中定义的“编码符号长度”对象传输信息元素。
* "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the "Max-Number-of-Encoding-Symbols" Object Transmission Information element defined in [RFC5052], if required by the FEC Scheme.
* 如果FEC方案需要，“FEC OTI最大编码符号数”携带[RFC5052]中定义的“最大编码符号数”对象传输信息元素。
* "FEC-OTI-Scheme-Specific-Info" carries the "encoded Scheme-specific FEC Object Transmission Information" as defined in [RFC5052], if required by the FEC Scheme.
* 如果FEC方案需要，“FEC OTI方案特定信息”携带[RFC5052]中定义的“编码方案特定FEC对象传输信息”。
In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be carried in the Codepoint field of the ALC/LCT header. When the FEC Object Transmission Information for this TOI is delivered through the FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the Codepoint field of all packets for this TOI MUST be the same.
在FLUTE中，给定TOI的FEC编码ID（8位）必须在ALC/LCT报头的代码点字段中携带。当通过FDT传递该TOI的FEC对象传输信息时，则该TOI的所有分组的相关“FEC OTI FEC Encoding ID”属性和码点字段必须相同。
To start receiving a file delivery session, the receiver needs to know transport parameters associated with the session. Interpreting these parameters and starting the reception therefore represent the entry point from which thereafter the receiver operation falls into the scope of this specification. According to [RFC5775], the transport parameters of an ALC/LCT session that the receiver needs to know are:
要开始接收文件传递会话，接收方需要知道与会话相关联的传输参数。因此，解释这些参数并开始接收代表入口点，此后接收器操作从该入口点落入本规范的范围。根据[RFC5775]，接收机需要知道的ALC/LCT会话的传输参数为：
* The source IP address;
* 源IP地址；
* The number of channels in the session;
* 会话中的频道数；
* The destination IP address and port number for each channel in the session;
* 会话中每个通道的目标IP地址和端口号；
* The Transport Session Identifier (TSI) of the session;
* 会话的传输会话标识符（TSI）；
* An indication that the session is a FLUTE session. The need to demultiplex objects upon reception is implicit in any use of FLUTE, and this fulfills the ALC requirement of an indication of whether or not a session carries packets for more than one object (all FLUTE sessions carry packets for more than one object).
* 表示该会话是长笛会话的指示。接收时解复用对象的需要隐含在任何长笛的使用中，这满足ALC要求，即指示会话是否携带多个对象的数据包（所有长笛会话携带多个对象的数据包）。
Optionally, the following parameters MAY be associated with the session (note that the list is not exhaustive):
可选地，以下参数可能与会话关联（请注意，列表并非详尽无遗）：
* The start time and end time of the session;
* 会话的开始时间和结束时间；
* FEC Encoding ID and FEC Instance ID when the default FEC Encoding ID 0 is not used for the delivery of the FDT;
* 当默认FEC编码ID 0未用于FDT的传递时，FEC编码ID和FEC实例ID；
* Content encoding format if optional content encoding of the FDT Instance is used, e.g., compression;
* 内容编码格式（如果使用FDT实例的可选内容编码，例如压缩）；
* Some information that tells receiver, in the first place, that the session contains files that are of interest;
* 一些信息首先告诉接收者会话包含感兴趣的文件；
* Definition and configuration of a congestion control mechanism for the session;
* 会话拥塞控制机制的定义和配置；
* Security parameters relevant for the session;
* 与会议有关的安全参数；
* FLUTE version number.
* 长笛版本号。
It is envisioned that these parameters would be described according to some session description syntax (such as SDP [RFC4566] or XML based) and held in a file that would be acquired by the receiver before the FLUTE session begins by means of some transport protocol (such as the Session Announcement Protocol (SAP) [RFC2974], email, HTTP [RFC2616], SIP [RFC3261], manual preconfiguration, etc.). However, the way in which the receiver discovers the above-mentioned parameters is out of scope of this document, as it is for LCT and ALC. In particular, this specification does not mandate or exclude any mechanism.
可以设想，这些参数将根据一些会话描述语法（例如SDP[RFC4566]或基于XML）进行描述，并保存在一个文件中，该文件将在长笛会话开始之前通过一些传输协议（例如会话公告协议（SAP）[RFC2974]，电子邮件，HTTP[RFC2616]由接收器获取，SIP[RFC3261]，手动预配置等）。然而，与LCT和ALC一样，接收方发现上述参数的方式超出了本文件的范围。特别是，本规范不强制或排除任何机制。
A content delivery system is potentially subject to attacks. Attacks may target:
内容交付系统可能受到攻击。攻击的目标可能是：
* the network (to compromise the routing infrastructure, e.g., by creating congestion),
* 网络（破坏路由基础设施，如造成拥塞），
* the Content Delivery Protocol (CDP) (e.g., to compromise the normal behavior of FLUTE), or
* 内容交付协议（CDP）（例如，损害长笛的正常行为），或
* the content itself (e.g., to corrupt the files being transmitted).
* 内容本身（例如，损坏正在传输的文件）。
These attacks can be launched either:
这些攻击可以通过以下方式发起：
* against the data flow itself (e.g., by sending forged packets),
* 针对数据流本身（例如，通过发送伪造数据包），
* against the session control parameters (e.g., by corrupting the session description, the FDT Instances, or the ALC/LCT control parameters) that are sent either in-band or out-of-band, or
* 针对带内或带外发送的会话控制参数（例如，通过破坏会话描述、FDT实例或ALC/LCT控制参数），或
* against some associated building blocks (e.g., the congestion control component).
* 针对一些相关的构建块（例如，拥塞控制组件）。
In the following sections, we provide more details on these possible attacks and sketch some possible countermeasures. We provide recommendations in Section 7.5.
在以下部分中，我们将提供有关这些可能的攻击的更多详细信息，并概述一些可能的对策。我们在第7.5节中提供了建议。
Let us consider attacks against the data flow first. At the least, the following types of attacks exist:
让我们先考虑对数据流的攻击。至少存在以下类型的攻击：
* attacks that are meant to give access to a confidential file (e.g., in the case of non-free content) and
* 旨在访问机密文件的攻击（例如，在非免费内容的情况下），以及
* attacks that try to corrupt the file being transmitted (e.g., to inject malicious code within a file, or to prevent a receiver from using a file, which is a kind of denial of service (DoS)).
* 试图破坏正在传输的文件的攻击（例如，在文件中插入恶意代码，或阻止接收者使用文件，这是一种拒绝服务（DoS））。
Access control to the file being transmitted is typically provided by means of encryption. This encryption can be done over the whole file, i.e., before applying FEC protection (e.g., by the content provider, before submitting the file to FLUTE), or can be done on a packet-by-packet basis (e.g., when IPsec/ESP [RFC4303] is used; see Section 7.5). If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used.
对正在传输的文件的访问控制通常通过加密的方式提供。这种加密可以在整个文件上完成，即在应用FEC保护之前（例如，由内容提供商在将文件提交给FLUTE之前），或者可以在分组的基础上完成（例如，当使用IPsec/ESP[RFC4303]时；参见第7.5节）。如果涉及保密性，建议使用其中一种解决方案。
Protection against corruptions (e.g., if an attacker sends forged packets) is achieved by means of a content integrity verification/ sender authentication scheme. This service can be provided at the file level, i.e., before applying content encoding and FEC encoding. In that case, a receiver has no way to identify which symbol(s) is(are) corrupted if the file is detected as corrupted. This service can also be provided at the packet level, i.e., after applying content encoding and FEC encoding, on a packet-by-packet basis. In this case, after removing all corrupted packets, the file may be in some cases recovered from the remaining correct packets.
通过内容完整性验证/发送方身份验证方案实现对损坏的保护（例如，如果攻击者发送伪造数据包）。该服务可以在文件级别提供，即在应用内容编码和FEC编码之前。在这种情况下，如果检测到文件已损坏，则接收器无法识别哪些符号已损坏。该服务也可以在分组级别上提供，即，在应用内容编码和FEC编码之后，以分组为基础。在这种情况下，删除所有损坏的数据包后，在某些情况下，可能会从剩余的正确数据包中恢复文件。
Integrity protection applied at the file level has the advantage of lower overhead, since only relatively few bits are added to provide the integrity protection compared to the file size. However, it has the disadvantage that it cannot distinguish between correct packets and corrupt packets, and therefore correct packets, which may form the majority of packets received, may be unusable. Integrity protection applied at the packet level has the advantage that it can distinguish between correct and corrupt packets, at the cost of additional per-packet overhead.
在文件级别应用的完整性保护具有开销较低的优点，因为与文件大小相比，只添加相对较少的位来提供完整性保护。然而，它的缺点是无法区分正确的数据包和损坏的数据包，因此，可能构成所接收数据包的大多数的正确数据包可能无法使用。在数据包级别应用的完整性保护的优点是，它可以区分正确的数据包和损坏的数据包，但代价是增加每个数据包的开销。
Several techniques can provide this source authentication/content integrity service:
有几种技术可以提供此源身份验证/内容完整性服务：
* At the file level, the file MAY be digitally signed (e.g., by using RSA Probabilistic Signature Scheme Public-Key Cryptography Standards version 1.5 (RSASSA-PKCS1-v1_5) [RFC3447]). This signature enables a receiver to check the file's integrity once the file has been fully decoded. Even if digital signatures are computationally expensive, this calculation occurs only once per file, which is usually acceptable.
* 在文件级别，可以对文件进行数字签名（例如，通过使用RSA概率签名方案公钥加密标准版本1.5（RSASSA-PKCS1-v1_5）[RFC3447]）。此签名使接收者能够在文件完全解码后检查文件的完整性。即使数字签名在计算上很昂贵，但每个文件只进行一次计算，这通常是可以接受的。
* At the packet level, each packet can be digitally signed [RFC6584]. A major limitation is the high computational and transmission overheads that this solution requires. To avoid this problem, the signature may span a set of symbols (instead of a single one) in order to amortize the signature calculation, but if a single symbol is missing, the integrity of the whole set cannot be checked.
* 在数据包级别，每个数据包都可以进行数字签名[RFC6584]。一个主要的限制是该解决方案需要较高的计算和传输开销。为避免此问题，签名可能跨越一组符号（而不是单个符号），以便分摊签名计算，但如果缺少单个符号，则无法检查整个符号集的完整性。
* At the packet level, a Group-Keyed Message Authentication Code (MAC) [RFC2104] [RFC6584] scheme can be used; an example is using HMAC-SHA-256 with a secret key shared by all the group members, senders, and receivers. This technique creates a cryptographically secured digest of a packet that is sent along with the packet. The Group-Keyed MAC scheme does not create prohibitive processing load or transmission overhead, but it has a major limitation: it only provides a group authentication/ integrity service, since all group members share the same secret group key, which means that each member can send a forged packet. It is therefore restricted to situations where group members are fully trusted (or in association with another technique as a pre-check).
* 在分组级别，可以使用组密钥消息认证码（MAC）[RFC2104][RFC6584]方案；例如，使用HMAC-SHA-256时，所有组成员、发送方和接收方共享一个密钥。这种技术创建一个加密安全的数据包摘要，该摘要随数据包一起发送。组密钥MAC方案不会产生禁止性的处理负载或传输开销，但它有一个主要限制：它只提供组身份验证/完整性服务，因为所有组成员共享相同的组密钥，这意味着每个成员都可以发送伪造的包。因此，它仅限于组成员完全受信任（或与另一种技术关联作为预检查）的情况。
* At the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] [RFC5776] is an attractive solution that is robust to losses, provides a true authentication/ integrity service, and does not create any prohibitive processing load or transmission overhead. However, checking a packet requires a small delay (a second or more) after its reception.
* 在数据包级别，定时高效流丢失容忍认证（TESLA）[RFC4082][RFC5776]是一个具有吸引力的解决方案，它对丢失具有鲁棒性，提供真正的认证/完整性服务，并且不会产生任何禁止性的处理负载或传输开销。然而，检查数据包需要在接收后有一个小的延迟（一秒或更长）。
* At the packet level, IPsec/ESP [RFC4303] can be used to check the integrity and authenticate the sender of all the packets being exchanged in a session (see Section 7.5).
* 在数据包级别，IPsec/ESP[RFC4303]可用于检查会话中交换的所有数据包的完整性并对发送方进行身份验证（见第7.5节）。
Techniques relying on public key cryptography (digital signatures and TESLA during the bootstrap process, when used) require that public keys be securely associated to the entities. This can be achieved by
依靠公钥加密技术（使用引导过程中的数字签名和特斯拉）的技术要求公钥与实体安全关联。这可以通过以下方式实现：
a Public Key Infrastructure (PKI), or by a Pretty Good Privacy (PGP) Web of Trust, or by pre-distributing the public keys of each group member.
公钥基础设施（PKI），或通过相当好的隐私（PGP）信任网，或通过预分发每个组成员的公钥。
Techniques relying on symmetric key cryptography (Group-Keyed MAC) require that a secret key be shared by all group members. This can be achieved by means of a group key management protocol, or simply by pre-distributing the secret key (but this manual solution has many limitations).
依赖对称密钥加密（组密钥MAC）的技术要求所有组成员共享密钥。这可以通过组密钥管理协议或简单地通过预分发密钥来实现（但此手动解决方案有许多限制）。
It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate. Nonetheless, in case there is any concern of the threat of file corruption, it is RECOMMENDED that at least one of these techniques be used.
由了解目标应用程序领域的安全需求和特性的开发人员和部署人员来定义哪种解决方案最合适。尽管如此，如果担心文件损坏的威胁，建议至少使用其中一种技术。
7.3. Attacks against the Session Control Parameters and Associated Building Blocks
7.3. 对会话控制参数和相关构建块的攻击
Let us now consider attacks against the session control parameters and the associated building blocks. The attacker has at least the following opportunities to launch an attack:
现在让我们考虑对会话控制参数和相关的构建块的攻击。攻击者至少有以下机会发起攻击：
* the attack can target the session description,
* 攻击的目标可能是会话描述，
* the attack can target the FDT Instances,
* 攻击可以针对FDT实例，
* the attack can target the ALC/LCT parameters, carried within the LCT header, or
* 攻击的目标可能是LCT头中携带的ALC/LCT参数，或者
* the attack can target the FLUTE associated building blocks (e.g., the multiple-rate congestion control protocol).
* 攻击可针对与长笛相关的构建块（例如，多速率拥塞控制协议）。
The consequences of these attacks are potentially serious, since they might compromise the behavior of the content delivery system itself.
这些攻击的后果可能很严重，因为它们可能会损害内容交付系统本身的行为。
A FLUTE receiver may potentially obtain an incorrect session description for the session. The consequence of this is that legitimate receivers with the wrong session description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby possibly disrupting other traffic in the network.
长笛接收器可能会获取不正确的会话描述。其结果是，具有错误会话描述的合法接收器无法正确接收会话内容，或者接收器无意中尝试以远高于其能力的速率接收，从而可能中断网络中的其他通信。
To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions. One such measure is source authentication to ensure that receivers only
为了避免这些问题，建议采取措施防止接收者接受错误的会话描述。其中一个措施是源身份验证，以确保仅接收
accept legitimate session descriptions from authorized senders. How these measures are achieved is outside the scope of this document, since this session description is usually carried out-of-band.
接受来自授权发件人的合法会话描述。如何实现这些措施超出了本文件的范围，因为本课程描述通常在带外进行。
Corrupting the FDT Instances is one way to create a DoS attack. For example, the attacker changes the MD5 sum associated to a file. This possibly leads a receiver to reject the files received, no matter whether the files have been correctly received or not.
破坏FDT实例是造成DoS攻击的一种方法。例如，攻击者更改与文件关联的MD5总和。这可能导致接收者拒绝接收到的文件，无论文件是否正确接收。
Corrupting the FDT Instances is also a way to make the reception process more costly than it should be. This can be achieved by changing the FEC Object Transmission Information when the FEC Object Transmission Information is included in the FDT Instance. For example, an attacker may corrupt the FDT Instance in such a way that Reed-Solomon over GF(2^^16) would be used instead of GF(2^^8) with FEC Encoding ID 2. This may significantly increase the processing load while compromising FEC decoding.
破坏FDT实例也是一种使接收过程的成本高于其应有成本的方法。这可以通过在FDT实例中包括FEC对象传输信息时改变FEC对象传输信息来实现。例如，攻击者可能损坏FDT实例，从而使用GF（2^^16）上的Reed Solomon代替FEC编码ID为2的GF（2^^8）。这可能会显著增加处理负载，同时影响FEC解码。
More generally, because FDT Instance data is structured using the XML language by means of an XML media type, many of the security considerations described in [RFC3023] and [RFC3470] also apply to such data.
更一般地说，由于FDT实例数据是通过XML媒体类型使用XML语言构造的，因此[RFC3023]和[RFC3470]中描述的许多安全注意事项也适用于此类数据。
It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the FDT Instances. To that purpose, one of the countermeasures mentioned above (Section 7.2.2) SHOULD be used. These measures will either be applied on a packet level or globally over the whole FDT Instance object. Additionally, XML digital signatures [RFC3275] are a way to protect the FDT Instance by digitally signing it. When there is no packet-level integrity verification scheme, it is RECOMMENDED to rely on XML digital signatures of the FDT Instances.
因此，建议采取措施保证FDT实例的完整性并检查发送方的身份。为此，应采用上述对策之一（第7.2.2节）。这些措施要么应用于数据包级别，要么全局应用于整个FDT实例对象。此外，XML数字签名[RFC3275]是一种通过数字签名来保护FDT实例的方法。当并没有包级完整性验证方案时，建议依赖FDT实例的XML数字签名。
By corrupting the ALC/LCT header (or header extensions), one can execute attacks on the underlying ALC/LCT implementation. For example, sending forged ALC packets with the Close Session flag (A) set to one can lead the receiver to prematurely close the session. Similarly, sending forged ALC packets with the Close Object flag (B) set to one can lead the receiver to prematurely give up the reception of an object.
通过破坏ALC/LCT头（或头扩展），可以对底层ALC/LCT实现执行攻击。例如，发送关闭会话标志（A）设置为1的伪造ALC数据包可能导致接收器过早关闭会话。类似地，发送带有关闭对象标志（B）设置为1的伪造ALC分组会导致接收机过早地放弃接收对象。
It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the ALC packets received. To that purpose, one of the countermeasures mentioned above (Section 7.2.2) SHOULD be used.
因此，建议采取措施来保证所接收ALC数据包的完整性并检查发送方的身份。为此，应采用上述对策之一（第7.2.2节）。
Let us first focus on the congestion control building block, which may be used in the ALC session. A receiver with an incorrect or corrupted implementation of the multiple-rate congestion control building block may affect the health of the network in the path between the sender and the receiver. That may also affect the reception rates of other receivers who joined the session.
让我们首先关注拥塞控制构建块，它可能会在ALC会话中使用。具有多速率拥塞控制构建块的不正确或损坏实现的接收器可能会影响发送方和接收器之间路径中的网络健康。这也可能影响加入会话的其他接收器的接收速率。
When the congestion control building block is applied with FLUTE, it is RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the session description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document. If authenticating a receiver does not prevent this receiver from launching an attack, this authentication will enable the network operator to identify him and to take countermeasures.
当使用FLUTE应用拥塞控制构建块时，建议要求接收者在接收加入会话所需的会话描述之前将自己标识为合法。接收人如何认定自己合法不在本文件范围内。如果对接收者进行身份验证不能阻止该接收者发起攻击，则此身份验证将使网络运营商能够识别他并采取对策。
When the congestion control building block is applied with FLUTE, it is also RECOMMENDED that a packet-level authentication scheme be used, as explained in Section 7.2.2. Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control requires a rapid reaction. It is therefore RECOMMENDED [RFC5775] that a receiver using TESLA quickly reduce its subscription level when the receiver believes that congestion did occur, even if the packet has not yet been authenticated. Therefore, TESLA will not prevent DoS attacks where an attacker makes the receiver believe that congestion occurred. This is an issue for the receiver, but this will not compromise the network. Other authentication methods that do not feature this delayed authentication could be preferred, or a Group-Keyed MAC scheme could be used in parallel with TESLA to prevent attacks launched from outside of the group.
如第7.2.2节所述，当使用FLUTE应用拥塞控制构建块时，还建议使用数据包级认证方案。其中一些，如特斯拉，只提供延迟认证服务，而拥塞控制需要快速反应。因此，建议[RFC5775]使用特斯拉的接收器在认为确实发生了拥塞时快速降低其订阅级别，即使数据包尚未通过身份验证。因此，特斯拉不会阻止DoS攻击，因为攻击者会让接收者相信发生了拥塞。这是接收器的问题，但不会影响网络。不具有延迟认证特征的其他认证方法可能是首选，或者组密钥MAC方案可以与TESLA并行使用，以防止从组外发起的攻击。
The security considerations that apply to, and are described in, ALC [RFC5775], LCT [RFC5651], and FEC [RFC5052] also apply to FLUTE, as FLUTE builds on those specifications. In addition, any security considerations that apply to any congestion control building block used in conjunction with FLUTE also apply to FLUTE.
适用于ALC[RFC5775]、LCT[RFC5651]和FEC[RFC5052]的安全注意事项以及其中所述的安全注意事项也适用于FLUTE，因为FLUTE建立在这些规范的基础上。此外，适用于与FLUTE一起使用的任何拥塞控制构建块的任何安全注意事项也适用于FLUTE。
Even if FLUTE defines a purely unidirectional delivery service, without any feedback information that would be sent to the sender, security considerations MAY require bidirectional communications. For instance, if an automated key management scheme is used, a bidirectional point-to-point channel is often needed to establish a shared secret between each receiver and the sender. Each shared secret can then be used to distribute additional keys to the associated receiver (e.g., traffic encryption keys).
即使FLUTE定义了一个纯粹的单向传递服务，但没有任何反馈信息会发送给发送者，出于安全考虑，可能需要双向通信。例如，如果使用自动密钥管理方案，则通常需要双向点到点信道来在每个接收方和发送方之间建立共享密钥。然后，可以使用每个共享密钥将附加密钥分发给相关接收器（例如，流量加密密钥）。
As an example, [MBMSsecurity] details a complete security framework for the Third Generation Partnership Project (3GPP) Multimedia Broadcast/Multicast Service (MBMS) that relies on FLUTE/ALC for Download Sessions. It relies on bidirectional point-to-point communications for User Equipment authentication and for key distribution, using the Multimedia Internet KEYing (MIKEY) protocol [RFC3830]. Because this security framework is specific to this use case, it cannot be reused as such for generic security recommendations in this specification. Instead, the following section introduces minimum security recommendations.
例如，[MBMSsecurity]详细介绍了第三代合作伙伴计划（3GPP）多媒体广播/多播服务（MBMS）的完整安全框架，该服务依赖于FLUTE/ALC进行下载会话。它依靠双向点对点通信，使用多媒体互联网密钥（MIKEY）协议[RFC3830]进行用户设备认证和密钥分发。由于此安全框架特定于此用例，因此不能将其重新用于本规范中的通用安全建议。相反，以下部分介绍了最低安全性建议。
We now introduce a mandatory-to-implement, but not necessarily to use, security configuration, in the sense of [RFC3365]. Since FLUTE relies on ALC/LCT, it inherits the "baseline secure ALC operation" of [RFC5775]. More precisely, security is achieved by means of IPsec/ ESP in transport mode. [RFC4303] explains that ESP can be used to potentially provide confidentiality, data origin authentication, content integrity, anti-replay, and (limited) traffic flow confidentiality. [RFC5775] specifies that the data origin authentication, content integrity, and anti-replay services SHALL be supported, and that the confidentiality service is RECOMMENDED. If a short-lived session MAY rely on manual keying, it is also RECOMMENDED that an automated key management scheme be used, especially in the case of long-lived sessions.
我们现在引入了一个强制的安全配置来实现（但不一定要使用），即[RFC3365]。由于FLUTE依赖于ALC/LCT，因此它继承了[RFC5775]的“基线安全ALC操作”。更准确地说，安全性是通过传输模式下的IPsec/ESP实现的。[RFC4303]解释了ESP可用于潜在地提供机密性、数据源身份验证、内容完整性、反重播和（有限的）流量机密性。[RFC5775]规定应支持数据源身份验证、内容完整性和防重播服务，并建议提供保密服务。如果短寿命会话可能依赖于手动密钥，则还建议使用自动密钥管理方案，尤其是在长寿命会话的情况下。
Therefore, the RECOMMENDED solution for FLUTE provides per-packet security, with data origin authentication, integrity verification, and anti-replay. This is sufficient to prevent most of the in-band attacks listed above. If confidentiality is required, a per-packet encryption SHOULD also be used.
因此，推荐的FLUTE解决方案提供了每个数据包的安全性，包括数据源身份验证、完整性验证和反重放。这足以防止上面列出的大多数带内攻击。如果需要保密，还应使用每包加密。
This specification contains five separate items upon which IANA has taken action:
本规范包含IANA已采取行动的五个独立项目：
1. Registration of the FDT Instance XML Namespace.
1. 注册FDT实例XML命名空间。
2. Registration of the FDT Instance XML Schema.
2. 注册FDT实例XML模式。
3. Registration of the application/fdt+xml Media Type.
3. 注册应用程序/fdt+xml媒体类型。
4. Registration of the Content Encoding Algorithms.
4. 内容编码算法的注册。
5. Registration of two LCT Header Extension Types (EXT_FDT and EXT_CENC).
5. 注册两种LCT标头扩展类型（EXT_FDT和EXT_CENC）。
IANA has registered the following new XML Namespace in the IETF XML "ns" registry [RFC3688] at http://www.iana.org/assignments/xml-registry/ns.html.
IANA已在IETF XML“ns”注册表[RFC3688]中注册了以下新的XML命名空间：http://www.iana.org/assignments/xml-registry/ns.html.
URI: urn:ietf:params:xml:ns:fdt
URI: urn:ietf:params:xml:ns:fdt
Registrant Contact: Toni Paila (toni.paila@gmail.com)
注册人联系人：Toni Paila（Toni。paila@gmail.com)
XML: N/A
XML：不适用
IANA has registered the following in the IETF XML "schema" registry [RFC3688] at http://www.iana.org/assignments/xml-registry/schema.html.
IANA已在IETF XML“模式”注册表[RFC3688]中注册了以下内容：http://www.iana.org/assignments/xml-registry/schema.html.
URI: urn:ietf:params:xml:schema:fdt
URI: urn:ietf:params:xml:schema:fdt
Registrant Contact: Toni Paila (toni.paila@gmail.com)
注册人联系人：Toni Paila（Toni。paila@gmail.com)
XML: The XML Schema specified in Section 3.4.2
XML：第3.4.2节中指定的XML模式
IANA has registered the following in the "Application Media Types" registry at http://www.iana.org/assignments/media-types/application/.
IANA已在“应用程序媒体类型”注册表中注册了以下内容：http://www.iana.org/assignments/media-types/application/.
Type name: application
类型名称：应用程序
Subtype name: fdt+xml
子类型名称：fdt+xml
Required parameters: none
所需参数：无
Optional parameters: charset="utf-8"
可选参数：charset=“utf-8”
Encoding considerations: binary (the FLUTE file delivery protocol does not impose any restriction on the objects it carries and in particular on the FDT Instance itself)
编码注意事项：二进制（长笛文件传递协议不对其承载的对象，特别是FDT实例本身施加任何限制）
Restrictions on usage: none
使用限制：无
Security considerations: fdt+xml data is passive and does not generally represent a unique or new security threat. However, there is some risk in sharing any kind of data, in that unintentional information may be exposed, and that risk applies to fdt+xml data as well.
安全注意事项：fdt+xml数据是被动的，通常不代表唯一或新的安全威胁。然而，共享任何类型的数据都有一定的风险，因为无意的信息可能会被暴露，并且这种风险也适用于fdt+xml数据。
Interoperability considerations: None
互操作性注意事项：无
Published specification: [RFC6726], especially noting Section 3.4.2. The specified FDT Instance functions as an actual media format of use to the general Internet community, and thus media type registration under the Standards Tree is appropriate to maximize interoperability.
已发布规范：[RFC6726]，特别注意第3.4.2节。指定的FDT实例作为一般Internet社区使用的实际媒体格式发挥作用，因此标准树下的媒体类型注册适用于最大限度地提高互操作性。
Applications that use this media type: file and object delivery applications and protocols (e.g., FLUTE).
使用此媒体类型的应用程序：文件和对象交付应用程序和协议（例如，FLUTE）。
Additional information:
其他信息：
Magic number(s): none
File extension(s): ".fdt" (e.g., if there is a need to store an
FDT Instance as a file)
Macintosh File Type Code(s): none
Magic number(s): none
File extension(s): ".fdt" (e.g., if there is a need to store an
FDT Instance as a file)
Macintosh File Type Code(s): none
Person and email address to contact for further information: Toni Paila (toni.paila@gmail.com)
联系人和电子邮件地址以获取更多信息：Toni Paila（Toni。paila@gmail.com)
Intended usage: Common
预期用途：普通
Author/Change controller: IETF
作者/变更控制员：IETF
IANA has created a new registry, "FLUTE Content Encoding Algorithms", with a reference to [RFC6726]; see Section 3.4.3. The registry entries consist of a numeric value from 0 to 255, inclusive, and may be registered using the Specification Required policy [RFC5226].
IANA创建了一个新的注册表，“长笛内容编码算法”，参考[RFC6726]；见第3.4.3节。注册表项由0到255（含0到255）的数值组成，可以使用规范要求的策略[RFC5226]进行注册。
The initial contents of the registry are as follows, with unspecified values available for new registrations:
注册表的初始内容如下，未指定的值可用于新注册：
+-------+----------------+-----------+
| Value | Algorithm Name | Reference |
+-------+----------------+-----------+
| 0 | null | [RFC6726] |
| 1 | ZLIB | [RFC1950] |
| 2 | DEFLATE | [RFC1951] |
| 3 | GZIP | [RFC1952] |
+-------+----------------+-----------+
+-------+----------------+-----------+
| Value | Algorithm Name | Reference |
+-------+----------------+-----------+
| 0 | null | [RFC6726] |
| 1 | ZLIB | [RFC1950] |
| 2 | DEFLATE | [RFC1951] |
| 3 | GZIP | [RFC1952] |
+-------+----------------+-----------+
IANA has registered two new entries in the "Layered Coding Transport (LCT) Header Extension Types" registry [RFC5651], as follows:
IANA在“分层编码传输（LCT）头扩展类型”注册表[RFC5651]中注册了两个新条目，如下所示：
+--------+----------+-------------------------+
| Number | Name | Reference |
+--------+----------+-------------------------+
| 192 | EXT_FDT | [RFC6726] Section 3.4.1 |
| 193 | EXT_CENC | [RFC6726] Section 3.4.3 |
+--------+----------+-------------------------+
+--------+----------+-------------------------+
| Number | Name | Reference |
+--------+----------+-------------------------+
| 192 | EXT_FDT | [RFC6726] Section 3.4.1 |
| 193 | EXT_CENC | [RFC6726] Section 3.4.3 |
+--------+----------+-------------------------+
The following persons have contributed to this specification: Brian Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma, Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington, Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica, Francis Dupont, Peter Saint-Andre, Don Gillies, and Barry Leiba. The authors would like to thank all the contributors for their valuable work in reviewing and providing feedback regarding this specification.
以下人员对本规范做出了贡献：布赖恩·亚当森、马克·汉德利、埃萨·贾洛宁、罗杰·克莫德、朱哈·佩卡·洛马、托皮·波霍莱宁、洛伦佐·维西萨诺、马克·沃森、大卫·哈林顿、本·坎贝尔、斯蒂芬·法雷尔、罗伯特·斯帕克斯、罗纳德·博尼卡、弗朗西斯·杜邦、彼得·圣安德烈、堂·吉利斯和巴里·莱巴。作者要感谢所有贡献者在审查和提供有关本规范的反馈方面所做的宝贵工作。
Jani Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: jani.peltotalo@tut.fi
詹尼帕尔图罗坦佩雷理工大学坦佩雷理工大学邮政信箱553（KOKKAKULKKATU 1）坦佩雷芬兰-3101芬兰电子邮件：贾尼。peltotalo@tut.fi
Sami Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: sami.peltotalo@tut.fi
SAMI PalToRo坦佩雷理工大学邮政信箱553（KOKKAKULKKATU 1）坦佩雷芬兰-3101芬兰电子邮件：安德烈·萨米。peltotalo@tut.fi
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm Sweden EMail: magnus.westerlund@ericsson.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80斯德哥尔摩瑞典电子邮件：Magnus。westerlund@ericsson.com
Thorsten Lohmar Ericsson Research (EDD) Ericsson Allee 1 52134 Herzogenrath Germany EMail: thorsten.lohmar@ericsson.com
Thorsten Lohmar Ericsson Research（EDD）Ericsson Allee 1 52134 Herzogenrath Germany电子邮件：Thorsten。lohmar@ericsson.com
Incremented the FLUTE protocol version from 1 to 2, due to concerns about backwards compatibility. For instance, the LCT header changed between RFC 3451 and [RFC5651]. In RFC 3451, the T and R fields of the LCT header indicate the presence of Sender Current Time and Expected Residual Time, respectively. In [RFC5651], these fields MUST be set to zero and MUST be ignored by receivers (instead, the EXT_TIME Header Extensions can convey this information if needed). Thus, [RFC5651] is not backwards compatible with RFC 3451, even though both use LCT version 1. FLUTE version 1 as specified in [RFC3926] MUST use RFC 3451. FLUTE version 2 as specified in this document MUST use [RFC5651]. Therefore, an implementation that relies on [RFC3926] and RFC 3451 will not be backwards compatible with FLUTE as specified in this document.
由于担心向后兼容性，将FLUTE协议版本从1增加到2。例如，LCT头在RFC 3451和[RFC5651]之间更改。在RFC 3451中，LCT报头的T和R字段分别指示发送方当前时间和预期剩余时间的存在。在[RFC5651]中，这些字段必须设置为零，并且必须被接收器忽略（相反，如果需要，EXT_TIME标头扩展可以传递此信息）。因此，[RFC5651]与RFC 3451不向后兼容，即使两者都使用LCT版本1。[RFC3926]中规定的凹槽版本1必须使用RFC 3451。本文件中规定的凹槽版本2必须使用[RFC5651]。因此，依赖于[RFC3926]和RFC 3451的实现将不与本文档中规定的FLUTE向后兼容。
Updated dependencies to other RFCs to revised versions; e.g., changed ALC reference from RFC 3450 to [RFC5775], changed LCT reference from RFC 3451 to [RFC5651], etc.
将对其他RFC的依赖关系更新为修订版本；e、 例如，将ALC参考从RFC 3450更改为[RFC5775]，将LCT参考从RFC 3451更改为[RFC5651]，等等。
Added clarification for the use of FLUTE for unicast communications in Section 1.1.4.
在第1.1.4节中增加了对单播通信中使用长笛的澄清。
Clarified how to reliably deliver the FDT in Section 3.3 and the possibility of using out-of-band delivery of FDT information.
阐明了如何在第3.3节中可靠交付FDT，以及使用FDT信息带外交付的可能性。
Clarified how to address FDT Instance expiration time wraparound with the notion of the NTPv4 "epoch" in Section 3.3.
阐明了如何使用第3.3节中NTPv4“历元”的概念来解决FDT实例到期时间问题。
Clarified what should be considered erroneous situations in Section 3.4.1 (definition of FDT Instance ID). In particular, a receiver MUST be ready to handle FDT Instance ID wraparounds and missing FDT Instances.
澄清了第3.4.1节（FDT实例ID的定义）中的错误情况。特别是，接收器必须准备好处理FDT实例ID包装和丢失的FDT实例。
Updated Section 7.5 to define IPsec/ESP as a mandatory-to-implement security solution.
更新了第7.5节，将IPsec/ESP定义为实施安全解决方案的必备工具。
Removed the 'Statement of Intent' from Section 1. The statement of intent was meant to clarify the "Experimental" status of [RFC3926]. It does not apply to this document.
从第1节中删除“意向声明”。意向声明旨在澄清[RFC3926]的“实验”状态。它不适用于本文件。
Added clarification of "XML-DSIG" near the end of Section 3.
在第3节末尾增加了对“XML-DSIG”的澄清。
In Section 3.2, replaced "complete FDT" with text that is more descriptive.
在第3.2节中，将“完整FDT”替换为更具描述性的文本。
Clarified Figure 1 with regard to "Encoding Symbol(s) for FDT Instance".
关于“FDT实例的编码符号”澄清了图1。
Clarified the text regarding FDT Instance ID wraparound at the end of Section 3.4.1.
澄清了第3.4.1节末尾关于FDT实例ID的文字。
Clarified "complete FDT" in Section 3.4.2.
澄清了第3.4.2节中的“完整FDT”。
Added semantics for the case where two TOIs refer to the same Content-Location. It is now in line with the way that 3GPP and Digital Video Broadcasting (DVB) standards interpret this case.
为两个TOI引用相同内容位置的情况添加了语义。它现在符合3GPP和数字视频广播（DVB）标准对该案例的解释方式。
In Section 3.4.2, the XML Schema of the FDT Instance was modified per advice from various sources. For example, extension by element was missing but is now supported. Also, the namespace definition was changed to URN format.
在第3.4.2节中，FDT实例的XML模式根据来自不同来源的建议进行了修改。例如，缺少元素扩展，但现在支持。此外，名称空间定义更改为URN格式。
Clarified FDT-schema extensibility at the end of Section 3.4.2.
在第3.4.2节末尾阐明了FDT模式的可扩展性。
The CENC value allocation has been added at the end of Section 3.4.3.
CENC价值分配已添加到第3.4.3节末尾。
Section 5 has been modified so that EXT_FTI and the FEC issues were replaced by a reference to the ALC specification [RFC5775].
对第5节进行了修改，以参考ALC规范[RFC5775]取代EXT_FTI和FEC问题。
Added a clarifying paragraph on the use of the Codepoint field at the end of Section 5.
在第5节末尾添加了一个关于使用代码点字段的澄清段落。
Reworked Section 8 -- IANA Considerations; it now contains six IANA registration requests:
修改后的第8节——IANA注意事项；它现在包含六个IANA注册请求：
* Registration of the FDT Instance XML Namespace.
* 注册FDT实例XML命名空间。
* Registration of the FDT Instance XML Schema.
* 注册FDT实例XML模式。
* Registration of the application/fdt+xml Media Type.
* 注册应用程序/fdt+xml媒体类型。
* Registration of the Content Encoding Algorithms.
* 内容编码算法的注册。
* Registration of two LCT Header Extension Types and corresponding values in the LCT Header Extension Types Registry (192 for EXT_FDT and 193 for EXT_CENC).
* 在LCT标头扩展类型注册表中注册两种LCT标头扩展类型和相应值（EXT_FDT为192，EXT_CENC为193）。
Added Section 10 -- Contributors.
增加了第10节——贡献者。
Revised lists of both Normative and Informative references.
修订的规范性和信息性参考文献清单。
Added a clarification that the receiver should ignore reserved bits of Header Extension type 193 upon reception.
增加了一个澄清，即接收机在接收时应忽略报头扩展类型193的保留位。
Elaborated on what kinds of networks cannot support FLUTE congestion control (Section 1.1.4).
详细说明了哪些类型的网络不能支持长笛拥塞控制（第1.1.4节）。
In Section 3.2, changed "several" (meaning 3-n vs. "couple" = 2) to "multiple" (meaning 2-n).
在第3.2节中，将“多个”（表示3-n对“耦合”=2）更改为“多个”（表示2-n）。
Moved the requirement in Section 3.3 (to send FDT more reliably than files) to a bulleted RECOMMENDED requirement, making check-off easier for testers.
将第3.3节中的要求（比文件更可靠地发送FDT）移至项目符号建议要求，使测试人员更容易进行检查。
In Section 3.3, sharpened the definition that future FDT file instances can "augment" (meaning enhance) rather than "complement" (sometimes meaning negate, which is not allowed) the file parameters.
在第3.3节中，明确了未来FDT文件实例可以“增强”（意思是增强）而不是“补充”（有时意味着否定，这是不允许的）文件参数的定义。
Elaborated in Sections 3.3 and 4 that FEC Encoding ID = 0 is Compact No-Code FEC, so that the reader doesn't have to search other RFCs to understand these protocol constants used by FLUTE.
在第3.3节和第4节中详细说明了FEC编码ID=0是紧凑的无代码FEC，因此读者不必搜索其他RFC来理解FLUTE使用的这些协议常数。
Required in Section 3.3 that FLUTE receivers SHALL NOT attempt to decode FDTs if they do not understand the FEC Encoding ID.
第3.3节要求，如果长笛接收器不理解FEC编码ID，则不得尝试解码FDT。
Removed the restriction of Section 3.3, in bullet #4, that TOI = 0 for the FDT, to be consistent with Appendix A step 6 and elsewhere. An FDT is signaled by an FDT Instance ID, NOT only by TOI = 0.
删除了项目符号4中第3.3节的限制，即FDT的TOI=0，以符合附录A第6步和其他地方的要求。FDT由FDT实例ID发出信号，而不仅仅是通过TOI=0。
Standardized on the term "expiration time", and avoided using the redundant and possibly confusing term "expiry time".
对术语“到期时间”进行标准化，避免使用冗余且可能混淆的术语“到期时间”。
To interwork with experimental FLUTE, stipulated in Section 3.1 that only 1 instantiation of all 3 protocols -- FLUTE, ALC, and LCT -- can be associated with a session (source IP Address, TSI), and mentioned in Section 6 that one may (optionally) derive the FLUTE version from the file delivery session description.
为了与实验性FLUTE互通，第3.1节中规定，所有3个协议（FLUTE、ALC和LCT）中只有1个实例化可以与会话（源IP地址，TSI）关联，第6节中提到，可以（可选）从文件交付会话描述中导出FLUTE版本。
Used a software writing tool to lower the reading grade level and simplify Section 3.1.
使用软件书写工具降低阅读等级并简化第3.1节。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775]Luby，M.，Watson，M.，和L.Vicisano，“异步分层编码（ALC）协议实例化”，RFC 5775，2010年4月。
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5651]Luby，M.，Watson，M.，和L.Vicisano，“分层编码传输（LCT）构建块”，RFC 5651，2009年10月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]Watson，M.，Luby，M.，和L.Vicisano，“前向纠错（FEC）构建块”，RFC 5052，2007年8月。
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes", RFC 5445, March 2009.
[RFC5445]Watson，M.，“基本前向纠错（FEC）方案”，RFC 54452009年3月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[XML-Schema-Part-1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[XML-Schema-Part-1]Thompson，H.，Beech，D.，Maloney，M.，和N.Mendelsohn，“XML模式第1部分：结构第二版”，W3C建议，2004年10月<http://www.w3.org/TR/xmlschema-1/>.
[XML-Schema-Part-2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-2/>.
[XML-Schema-Part-2]Biron，P.和A.Malhotra，“XML模式第2部分：数据类型第二版”，W3C建议，2004年10月<http://www.w3.org/TR/xmlschema-2/>.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，RFC 5226，2008年5月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738]Luby，M.和V.Goyal，“基于波动和方程的速率控制（WEBRC）构造块”，RFC 3738，2004年4月。
Note: The RFC 3738 reference is to a target document of a lower maturity level. Some caution should be used, since it may be less stable than the present document.
注：RFC 3738参考是指较低成熟度的目标文档。应谨慎使用，因为它可能不如本文件稳定。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004.
[RFC3926]Paila，T.，Luby，M.，Lehtonen，R.，Roca，V.，和R.Walsh，“长笛-单向传输上的文件交付”，RFC 3926，2004年10月。
[RFC2357] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]Mankin，A.，Romanow，A.，Bradner，S.，和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470]Hollenbeck，S.，Rose，M.，和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，2003年1月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]Deutsch，P.和J-L.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC1951]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[RFC1952]Deutsch，P.，“GZIP文件格式规范版本4.3”，RFC1952，1996年5月。
[IANAheaderfields] IANA, "Message Header Fields", <http://www.iana.org/protocols>.
[IANAheaderfields]IANA，“消息头字段”<http://www.iana.org/protocols>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[PAPER.SSM] Holbrook, H., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[PAPER.SSM]Holbrook，H.，“多播的信道模型”，博士。斯坦福大学计算机科学系博士论文，斯坦福，加利福尼亚，2001年8月。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.
[RFC3365]Schiller，J.“互联网工程任务组标准协议的强大安全要求”，BCP 61，RFC 3365，2002年8月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]Eastlake 3rd，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC 32752002年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 5776, April 2010.
[RFC5776]Roca，V.，Francillon，A.，和S.Faurite，“在异步分层编码（ALC）和面向NACK的可靠多播（NORM）协议中使用定时高效流丢失容忍认证（TESLA）”，RFC 5776，2010年4月。
[RFC6584] Roca, V., "Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6584, April 2012.
[RFC6584]Roca，V.“异步分层编码（ALC）和面向NACK的可靠多播（NORM）协议的简单认证方案”，RFC 6584，2012年4月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[MBMSsecurity] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS) (Release 10)", December 2010, <http://www.3gpp.org/ftp/Specs/archive/33_series/33.246/>.
[MBMSecurity]3GPP，“第三代合作伙伴项目；技术规范组服务和系统方面；3G安全；多媒体广播/多播服务（MBMS）安全（第10版）”，2010年12月<http://www.3gpp.org/ftp/Specs/archive/33_series/33.246/>.
Appendix A. Receiver Operation (Informative)
附录A.接收器操作（资料性）
This section gives an example of how the receiver of the file delivery session may operate. Instead of a detailed state-by-state specification, the following should be interpreted as a rough sequence of an envisioned file delivery receiver.
本节给出了文件传递会话的接收者如何操作的示例。以下内容不应是详细的逐州说明，而应解释为所设想的文件交付接收者的大致顺序。
1. The receiver obtains the description of the file delivery session identified by the (source IP address, Transport Session Identifier) pair. The receiver also obtains the destination IP addresses and respective ports associated with the file delivery session.
1. 接收方获得由（源IP地址、传输会话标识符）对标识的文件传递会话的描述。接收器还获得与文件传递会话相关联的目标IP地址和相应端口。
2. The receiver joins the channels in order to receive packets associated with the file delivery session. The receiver may schedule this join operation utilizing the timing information contained in a possible description of the file delivery session.
2. 接收器加入信道以便接收与文件传递会话相关联的分组。接收器可利用包含在文件递送会话的可能描述中的定时信息来调度该加入操作。
3. The receiver receives ALC/LCT packets associated with the file delivery session. The receiver checks that the packets match the declared Transport Session Identifier. If not, the packets are silently discarded.
3. 接收器接收与文件传递会话相关联的ALC/LCT数据包。接收方检查数据包是否与声明的传输会话标识符匹配。如果不是，则数据包将以静默方式丢弃。
4. While receiving, the receiver demultiplexes packets based on their TOI and stores the relevant packet information in an appropriate area for recovery of the corresponding file. Multiple files can be reconstructed concurrently.
4. 在接收时，接收器基于分组的TOI来解复用分组，并将相关分组信息存储在适当的区域中以恢复相应的文件。可以同时重建多个文件。
5. The receiver recovers an object. An object can be recovered when an appropriate set of packets containing Encoding Symbols for the transmission object has been received. An appropriate set of packets is dependent on the properties of the FEC Encoding ID and FEC Instance ID, and on other information contained in the FEC Object Transmission Information.
5. 接收器恢复一个对象。当接收到包含传输对象的编码符号的适当分组集时，可以恢复对象。适当的分组集合取决于FEC编码ID和FEC实例ID的属性，以及FEC对象传输信息中包含的其他信息。
6. Objects with TOI = 0 are reserved for FDT Instances. All FDT Instances are signaled by including an EXT_FDT Header Extension in the LCT header. The EXT_FDT header contains an FDT Instance ID (i.e., an FDT version number). If the object has an FDT Instance ID 'N', the receiver parses the payload of the instance 'N' of the FDT and updates its FDT database accordingly.
6. TOI=0的对象保留给FDT实例。所有FDT实例都通过在LCT报头中包含EXT_FDT报头扩展来发送信号。EXT_FDT标头包含FDT实例ID（即FDT版本号）。如果对象具有FDT实例ID“N”，则接收器解析FDT实例“N”的有效载荷，并相应地更新其FDT数据库。
7. If the object recovered is not an FDT Instance but a file, the receiver looks up its FDT database to get the properties described in the database, and assigns the file the given properties. The receiver also checks that the received content
7. 如果恢复的对象不是FDT实例而是文件，则接收器将查找其FDT数据库以获取数据库中描述的属性，并为文件指定给定属性。接收器还检查接收到的内容是否正确
length matches with the description in the database. Optionally, if an MD5 checksum has been used, the receiver checks that the calculated MD5 matches the description in the FDT database.
长度与数据库中的描述匹配。或者，如果使用了MD5校验和，则接收器检查计算出的MD5是否与FDT数据库中的描述匹配。
8. The actions the receiver takes with imperfectly received files (missing data, mismatching content integrity digest, etc.) are outside the scope of this specification. When a file is recovered before the associated file description entry is available, a possible behavior is to wait until an FDT Instance is received that includes the missing properties.
8. 接收方对未完全接收的文件（丢失数据、内容完整性摘要不匹配等）采取的措施不在本规范的范围内。在关联的文件描述条目可用之前恢复文件时，可能的行为是等待接收到包含丢失属性的FDT实例。
9. If the file delivery session end time has not been reached, go back to step 3. Otherwise, end.
9. 如果尚未达到文件传递会话结束时间，请返回步骤3。否则，结束。
Appendix B. Example of FDT Instance (Informative)
附录B.FDT实例示例（资料性）
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:fdt
ietf-flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:fdt
ietf-flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>
Authors' Addresses
作者地址
Toni Paila Nokia Itamerenkatu 11-13 Helsinki 00180 Finland
Toni Paila Nokia Itamerenkatu 11-13芬兰赫尔辛基00180
EMail: toni.paila@gmail.com
EMail: toni.paila@gmail.com
Rod Walsh Nokia/Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FI-33101 Finland
罗德沃尔什诺基亚/坦佩雷理工大学邮政信箱553（KOKKAKULKKATU 1）坦佩雷FI-33 101芬兰
EMail: roderick.walsh@tut.fi
EMail: roderick.walsh@tut.fi
Michael Luby Qualcomm Technologies, Inc. 2030 Addison Street, Suite 420 Berkeley, CA 94704 USA
美国加利福尼亚州伯克利市爱迪生街2030号420室Michael Luby高通技术有限公司，邮编94704
EMail: luby@qti.qualcomm.com
EMail: luby@qti.qualcomm.com
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
Vincent Roca INRIA 655，av。欧洲伊诺瓦利；蒙博诺圣伊斯梅尔塞德斯38334法国
EMail: vincent.roca@inria.fr
EMail: vincent.roca@inria.fr
Rami Lehtonen TeliaSonera Hatanpaankatu 1 Tampere FIN-33100 Finland
Rami Lehtonen TeliaSonera Hatanpaankatu 1坦佩雷FIN-33100芬兰
EMail: rami.lehtonen@teliasonera.com
EMail: rami.lehtonen@teliasonera.com