Network Working Group T. Paila
Request for Comments: 3926 Nokia
Category: Experimental M. Luby
Digital Fountain
R. Lehtonen
TeliaSonera
V. Roca
INRIA Rhone-Alpes
R. Walsh
Nokia
October 2004
FLUTE - File Delivery over Unidirectional Transport
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines FLUTE, a protocol for the unidirectional
delivery of files over the Internet, which is particularly suited to
multicast networks. The specification builds on Asynchronous Layered
Coding, the base protocol designed for massively scalable multicast
distribution.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Statement . . . . . . . . . . . . . . . . 3
1.1.1. The Target Application Space . . . . . . . . . . 3
1.1.2. The Target Scale . . . . . . . . . . . . . . . . 4
1.1.3. Intended Environments . . . . . . . . . . . . . 4
1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this Document. . . . . . . . . . . . . . . 5
3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. File delivery session . . . . . . . . . . . . . . . . . 6
3.2. File Delivery Table. . . . . . . . . . . . . . . . . . . 8
3.3. Dynamics of FDT Instances within file delivery session . 9
3.4. Structure of FDT Instance packets. . . . . . . . . . . . 11
Paila, et al. Experimental [Page 1]
RFC 3926 FLUTE October 2004
3.4.1. Format of FDT Instance Header . . . . . . . . . 12
3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . 13
3.4.3. Content Encoding of FDT Instance . . . . . . . . 16
3.5. Multiplexing of files within a file delivery session . . 17
4. Channels, congestion control and timing . . . . . . . . . . . 18
5. Delivering FEC Object Transmission Information . . . . . . . . 19
5.1. Use of EXT_FTI for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. General EXT_FTI format . . . . . . . . . . . . . 20
5.1.2. FEC Encoding ID specific formats for EXT_FTI . . 21
5.2. Use of FDT for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 25
6. Describing file delivery sessions. . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
Normative References . . . . . . . . . . . . . . . . . . . . . 29
Informative References . . . . . . . . . . . . . . . . . . . . 30
A. Receiver operation (informative) . . . . . . . . . . . . . . . 32
B. Example of FDT Instance (informative). . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 35
1. Introduction
This document defines FLUTE version 1, a protocol for unidirectional
delivery of files over the Internet. The specification builds on
Asynchronous Layered Coding (ALC), version 1 [2], the base protocol
designed for massively scalable multicast distribution. ALC defines
transport of arbitrary binary objects. For file delivery
applications mere transport of objects is not enough, however. The
end systems need to know what the objects actually represent. This
document specifies a technique called FLUTE - a mechanism for
signaling and mapping the properties of files to concepts of ALC in a
way that allows receivers to assign those parameters for received
objects. Consequently, throughout this document the term 'file'
relates to an 'object' as discussed in ALC. Although this
specification frequently makes use of multicast addressing as an
example, the techniques are similarly applicable for use with unicast
addressing.
This document defines a specific transport application of ALC, adding
the following specifications:
- Definition of a file delivery session built on top of ALC,
including transport details and timing constraints.
- In-band signalling of the transport parameters of the ALC session.
Paila, et al. Experimental [Page 2]
RFC 3926 FLUTE October 2004
- In-band signalling of the properties of delivered files.
- Details associated with the multiplexing of multiple files within
a session.
This specification is structured as follows. Section 3 begins by
defining the concept of the file delivery session. Following that it
introduces the File Delivery Table that forms the core part of this
specification. Further, it discusses multiplexing issues of
transport objects within a file delivery session. Section 4
describes the use of congestion control and channels with FLUTE.
Section 5 defines how the Forward Error Correction (FEC) Object
Transmission Information is to be delivered within a file delivery
session. Section 6 defines the required parameters for describing
file delivery sessions in a general case. Section 7 outlines
security considerations regarding file delivery with FLUTE. Last,
there are two informative appendices. The first appendix describes
an envisioned receiver operation for the receiver of the file
delivery session. The second appendix gives an example of File
Delivery Table.
Statement of Intent
This memo contains part of the definitions necessary to fully
specify a Reliable Multicast Transport protocol in accordance with
RFC2357. As per RFC2357, the use of any reliable multicast
protocol in the Internet requires an adequate congestion control
scheme.
While waiting for such a scheme to be available, or for an
existing scheme to be proven adequate, the Reliable Multicast
Transport working group (RMT) publishes this Request for Comments
in the "Experimental" category.
It is the intent of RMT to re-submit this specification as an IETF
Proposed Standard as soon as the above condition is met.
1.1. Applicability Statement
1.1.1. The Target Application Space
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
Paila, et al. Experimental [Page 3]
RFC 3926 FLUTE October 2004
of the network. It is also suitable for the basic transport of
metadata, for example SDP [12] files which enable user applications
to access multimedia sessions.
1.1.2. The Target Scale
Massive scalability is a primary design goal for FLUTE. IP multicast
is inherently massively scalable, but the best effort service that it
provides does not provide session management functionality,
congestion control or reliability. FLUTE provides all of this using
ALC and IP multicast without sacrificing any of the inherent
scalability of IP multicast.
1.1.3. Intended Environments
All of the environmental requirements and considerations that apply
to the ALC building block [2] and to any additional building blocks
that FLUTE uses also apply to FLUTE.
FLUTE can be used with both multicast and unicast delivery, but it's
primary application is for unidirectional multicast file delivery.
FLUTE requires connectivity between a sender and receivers but does
not require connectivity from receivers to a sender. FLUTE
inherently works with all types of networks, including LANs, WANs,
Intranets, the Internet, asymmetric networks, wireless networks, and
satellite networks.
FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
is IP version specific. FLUTE works with both multicast models:
Any-Source Multicast (ASM) [13] and the Source-Specific Multicast
(SSM) [15].
FLUTE is applicable for both Internet use, with a suitable congestion
control building block, and provisioned/controlled systems, such as
delivery over wireless broadcast radio systems.
1.1.4. Weaknesses
Some networks are not amenable to some congestion control protocols
that could be used with FLUTE. In particular, for a satellite or
wireless network, there may be no mechanism for receivers to
effectively reduce their reception rate since there may be a fixed
transmission rate allocated to the session.
Paila, et al. Experimental [Page 4]
RFC 3926 FLUTE October 2004
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.
2. Conventions used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
The terms "object" and "transport object" are consistent with the
definitions in ALC [2] and LCT [3]. The terms "file" and "source
object" are pseudonyms for "object".
3. File delivery
Asynchronous Layered Coding [2] is a protocol designed for delivery
of arbitrary binary objects. It is especially suitable for massively
scalable, unidirectional, multicast distribution. ALC provides the
basic transport for FLUTE, and thus FLUTE inherits the requirements
of ALC.
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.
* Identifier of the file, expressed as a URI. This identifier may
be globally unique. The identifier may also provide a location
for the file. In the above example: "http://www.example.com/docs/
file.txt".
* File name (usually, this can be concluded from the URI). In the
above example: "file.txt".
* File type, expressed as MIME media type (usually, this can also be
concluded from the extension of the file name). In the above
example: "text/plain". If an explicit value for the MIME type is
provided separately from the file extension and does not match the
MIME type of the file extension then the explicitly provided value
MUST be used as the MIME type.
Paila, et al. Experimental [Page 5]
RFC 3926 FLUTE October 2004
* File size, expressed in bytes. In the above example: "5200". If
the file is content encoded then this is the file size before
content encoding.
* Content encoding of the file, within transport. In the above
example, the file could be encoded using ZLIB [10]. In this case
the size of the transport object carrying the file would probably
differ from the file size. The transport object size is delivered
to receivers as part of the FLUTE protocol.
* Security properties of the file such as digital signatures,
message digests, etc. For example, one could use S/MIME [18] as
the content encoding type for files with this authentication
wrapper, and one could use XML-DSIG [19] to digitally sign an FDT
Instance.
3.1. File delivery session
ALC is a protocol instantiation of Layered Coding Transport building
block (LCT) [3]. Thus ALC inherits the session concept of LCT. In
this document we will use the concept ALC/LCT session to collectively
denote the interchangeable terms ALC session and LCT session.
An ALC/LCT session consists of a set of logically grouped ALC/LCT
channels associated with a single sender sending packets with ALC/LCT
headers for one or more objects. An ALC/LCT channel is defined by
the combination of a sender and an address associated with the
channel by the sender. A receiver joins a channel to start receiving
the data packets sent to the channel by the sender, and a receiver
leaves a channel to stop receiving data packets from the channel.
One of the fields carried in the ALC/LCT header is the Transport
Session Identifier (TSI). The TSI is scoped by the source IP
address, and the (source IP address, TSI) pair uniquely identifies a
session, i.e., the receiver uses this pair carried in each packet to
uniquely identify from which session the packet was received. In
case multiple objects are carried within a session, the Transport
Object Identifier (TOI) field within the ALC/LCT header identifies
from which object the data in the packet was generated. Note that
each object is associated with a unique TOI within the scope of a
session.
If the sender is not assigned a permanent IP address accessible to
receivers, but instead, packets that can be received by receivers
containing a temporary IP address for packets sent by the sender,
then the TSI is scoped by this temporary IP address of the sender for
the duration of the session. As an example, the sender may be behind
a Network Address Translation (NAT) device that temporarily assigns
Paila, et al. Experimental [Page 6]
RFC 3926 FLUTE October 2004
an IP address for the sender that is accessible to receivers, and in
this case the TSI is scoped by the temporary IP address assigned by
the NAT that will appear in packets received by the receiver. As
another example, the sender may send its original packets using IPv6,
but some portions of the network may not be IPv6 capable and thus
there may be an IPv6 to IPv4 translator that changes the IP address
of the packets to a different IPv4 address. In this case, receivers
in the IPv4 portion of the network will receive packets containing
the IPv4 address, and thus the TSI for them is scoped by the IPv4
address. How the IP address of the sender to be used to scope the
session by receivers is delivered to receivers, whether it is a
permanent IP address or a temporary IP address, is outside the scope
of this document.
When FLUTE is used for file delivery over ALC the following rules
apply:
* The ALC/LCT session is called file delivery session.
* The ALC/LCT concept of 'object' denotes either a 'file' or a 'File
Delivery Table Instance' (section 3.2)
* The TOI field MUST be included in ALC packets sent within a FLUTE
session, with the exception that ALC packets sent in a FLUTE
session with the Close Session (A) flag set to 1 (signaling the
end of the session) and that contain no payload (carrying no
information for any file or FDT) SHALL NOT carry the TOI. See
Section 5.1 of RFC 3451 [3] for the LCT definition of the Close
Session flag, and see Section 4.2 of RFC 3450 [2] for an example
of its use within an ALC packet.
* The TOI value '0' is reserved for delivery of File Delivery Table
Instances. Each File Delivery Table Instance is uniquely
identified by an FDT Instance ID.
* Each file in a file delivery session MUST be associated with a TOI
(>0) in the scope of that session.
* 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.
Paila, et al. Experimental [Page 7]
RFC 3926 FLUTE October 2004
3.2. File Delivery Table
The File Delivery Table (FDT) provides a means to describe various
attributes associated with files that are to be delivered within the
file delivery session. The following lists are examples of such
attributes, and are not intended to be mutually exclusive nor
exhaustive.
Attributes related to the delivery of file:
- TOI value that represents the file
- FEC Object Transmission Information (including the FEC Encoding ID
and, if relevant, the FEC Instance ID)
- Size of the transport object carrying the file
- Aggregate rate of sending packets to all channels
Attributes related to the file itself:
- Name, Identification and Location of file (specified by the URI)
- MIME 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.
Logically, the FDT is a set of file description entries for files to
be delivered in the session. Each file description entry MUST
include the TOI for the file that it describes and the URI
identifying the file. The TOI is included in each ALC/LCT data
packet during the delivery of the file, and thus the TOI carried in
the file description entry is how the receiver determines which
ALC/LCT data packets contain information about which file. Each file
description entry may also contain one or more descriptors that map
the above-mentioned attributes to the file.
Each file delivery session MUST have an FDT that is local to the
given session. The FDT MUST provide a file description entry mapped
to a TOI for each file appearing within the session. An object that
is delivered within the ALC session, but not described in the FDT, is
Paila, et al. Experimental [Page 8]
RFC 3926 FLUTE October 2004
not considered a 'file' belonging to the file delivery session.
Handling of these unmapped TOIs (TOIs that are not resolved by the
FDT) is out of scope of this specification.
Within the file delivery session the FDT is delivered as FDT
Instances. An FDT Instance contains one or more file description
entries of the FDT. Any FDT Instance can be equal to, a subset of, a
superset of, or complement any other FDT Instance. A certain FDT
Instance may be repeated several times during a session, even after
subsequent FDT Instances (with higher FDT Instance ID numbers) have
been transmitted. Each FDT Instance contains at least a single file
description entry and at most the complete FDT of the file delivery
session.
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.
Since FDT database is an abstract concept, the structure and the
maintaining of the FDT database are left to individual
implementations and are thus out of scope of this specification.
3.3. Dynamics of FDT Instances within file delivery session
The following rules define the dynamics of the FDT Instances within a
file delivery session:
* 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.
* 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.
* The TOI value of '0' MUST be reserved for delivery of FDT
Instances. The use of other TOI values for FDT Instances is
outside the scope of this specification.
Paila, et al. Experimental [Page 9]
RFC 3926 FLUTE October 2004
* FDT Instance is identified by the use of a new fixed length LCT
Header Extension EXT_FDT (defined later in this section). Each
FDT Instance is uniquely identified within the file delivery
session by its FDT Instance ID. Any ALC/LCT packet carrying FDT
Instance (indicated by TOI = 0) MUST include EXT_FDT.
* It is RECOMMENDED that FDT Instance that contains the file
description entry for a file is sent prior to the sending of the
described file within a file delivery session.
* Within a file delivery session, any TOI > 0 MAY be described more
than once. An example: previous FDT Instance 0 describes TOI of
value '3'. Now, subsequent FDT Instances can either keep TOI '3'
unmodified on the table, not include it, or complement the
description. However, subsequent FDT Instances MUST NOT change
the parameters already described for a specific TOI.
* An FDT Instance is valid until its expiration time. The
expiration time is expressed within the FDT Instance payload as a
32 bit data field. The value of the data field represents the 32
most significant bits of a 64 bit Network Time Protocol (NTP) [5]
time value. These 32 bits provide an unsigned integer
representing the time in seconds relative to 0 hours 1 January
1900. Handling of wraparound of the 32 bit time is outside the
scope of NTP and FLUTE.
* The receiver SHOULD NOT use a received FDT Instance to interpret
packets received beyond the expiration time of the FDT Instance.
* A sender MUST use an expiry time in the future upon creation of an
FDT Instance relative to its Sender Current Time (SCT).
* Any FEC Encoding ID MAY be used for the sending of FDT Instances.
The default is to use FEC Encoding ID 0 for the sending of FDT
Instances. (Note that since FEC Encoding ID 0 is the default for
FLUTE, this implies that Source Block Number and Encoding Symbol
ID lengths both default to 16 bits each.)
Generally, a receiver needs to receive an FDT Instance describing a
file before it is able to recover the file itself. In this sense FDT
Instances are of higher priority than files. Thus, it is RECOMMENDED
that FDT Instances describing a file be sent with at least as much
reliability within a session (more often or with more FEC protection)
as the files they describe. In particular, if FDT Instances are
longer than one packet payload in length it is RECOMMENDED that an
FEC code that provides protection against loss be used for delivering
FDT Instances. How often the description of a file is sent in an FDT
Paila, et al. Experimental [Page 10]
RFC 3926 FLUTE October 2004
Instance or how much FEC protection is provided for each FDT Instance
(if the FDT Instance is longer than one packet payload) is dependent
on the particular application and outside the scope of this document.
3.4. Structure of FDT Instance packets
FDT Instances are carried in ALC packets with TOI = 0 and with an
additional REQUIRED LCT Header extension called the FDT Instance
Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance
ID that uniquely identifies FDT Instances within a file delivery
session. The FDT Instance Header is placed in the same way as any
other LCT extension header. There MAY be other LCT extension headers
in use.
The LCT extension headers are followed by the FEC Payload ID, and
finally the Encoding Symbols for the FDT Instance which contains one
or more file description entries. A FDT Instance MAY span several
ALC packets - the number of ALC packets is a function of the file
attributes associated with the FDT Instance. The FDT Instance Header
is carried in each ALC packet carrying the FDT Instance. The FDT
Instance Header is identical for all ALC/LCT packets for a particular
FDT Instance.
The overall format of ALC/LCT packets carrying an FDT Instance is
depicted in the Figure 1 below. All integer fields are carried in
"big-endian" or "network order" format, that is, most significant
byte (octet) first. As defined in [2], all ALC/LCT packets are sent
using UDP.
Paila, et al. Experimental [Page 11]
RFC 3926 FLUTE October 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) for FDT Instance |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall FDT Packet
3.4.1. Format of FDT Instance Header
FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific
LCT header extension [3]. The Header Extension Type (HET) for the
extension is 192. Its format is defined below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version of FLUTE (V), 4 bits:
This document specifies FLUTE version 1. Hence in any ALC packet
that carries FDT Instance and that belongs to the file delivery
session as specified in this specification MUST set this field to
'1'.
FDT Instance ID, 20 bits:
For each file delivery session the numbering of FDT Instances starts
from '0' and is incremented by one for each subsequent FDT Instance.
After reaching the maximum value (2^20-1), the numbering starts again
from '0'. When wraparound from 2^20-1 to 0 occurs, 0 is considered
higher than 2^20-1. A new FDT Instance reusing a previous FDT
Instance ID number, due to wraparound, may not implicitly expire the
previous FDT Instance with the same ID. It would be reasonable for
Paila, et al. Experimental [Page 12]
RFC 3926 FLUTE October 2004
FLUTE Senders to only construct and deliver FDT Instances with
wraparound IDs after the previous FDT Instance using the same ID has
expired. However, mandatory receiver behavior for handling FDT
Instance ID wraparound and other special situations (for example,
missing FDT Instance IDs resulting in larger increments than one) is
outside the scope of this specification and left to individual
implementations of FLUTE.
3.4.2. Syntax of FDT Instance
The FDT Instance contains file description entries that provide the
mapping functionality described in 3.2 above.
The FDT Instance is an XML structure that has a single root element
"FDT-Instance". The "FDT-Instance" element MUST contain "Expires"
attribute, which tells the expiry time of the FDT Instance. In
addition, the "FDT-Instance" element MAY contain the "Complete"
attribute (boolean), which, when TRUE, signals that no new data will
be provided in future FDT Instances within this session (i.e., that
either FDT Instances with higher ID numbers will not be used or if
they are used, will only provide identical file parameters to those
already given in this and previous FDT Instances). For example, this
may be used to provide a complete list of files in an entire FLUTE
session (a "complete FDT").
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.
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.
The attributes of "File" element in the XML structure represent the
attributes given to the file that is delivered in the file delivery
session. The value of the XML attribute name corresponds to MIME
field name and the XML attribute value corresponds to the value of
the MIME field body. Each "File" element MUST contain at least two
attributes "TOI" and "Content-Location". "TOI" MUST be assigned a
valid TOI value as described in section 3.3 above. "Content-
Location" MUST be assigned a valid URI as defined in [6].
Paila, et al. Experimental [Page 13]
RFC 3926 FLUTE October 2004
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.
* Where the MIME type is described, the attribute "Content-Type"
MUST be used for the purpose as defined in [6].
* Where the length is described, the attribute "Content-Length" MUST
be used for the purpose as defined in [6]. The transfer length is
defined to be the length of the object transported in bytes. It
is often important to convey the transfer length to receivers,
because the source block structure needs to be known for the FEC
decoder to be applied to recover source blocks of the file, and
the transfer length is often needed to properly determine the
source block structure of the file. There generally will be a
difference between the length of the original file and the
transfer length if content encoding is applied to the file before
transport, and thus the "Content-Encoding" attribute is used. If
the file is not content encoded before transport (and thus the
"Content-Encoding" attribute is not used) then the transfer length
is the length of the original file, and in this case the
"Content-Length" is also the transfer length. However, if the
file is content encoded before transport (and thus the "Content-
Encoding" attribute is used), e.g., if compression is applied
before transport to reduce the number of bytes that need to be
transferred, then the transfer length is generally different than
the length of the original file, and in this case the attribute
"Transfer-Length" MAY be used to carry the transfer length.
* Where the content encoding scheme is described, the attribute
"Content-Encoding" MUST be used for the purpose as defined in [6].
* Where the MD5 message digest is described, the attribute
"Content-MD5" MUST be used for the purpose as defined in [6].
* The FEC Object Transmission Information attributes as described in
section 5.2.
The following specifies the XML Schema [8][9] for FDT Instance:
-- Leo's gemini proxy
-- Connecting to gemini.bortzmeyer.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/plain
-- Response ended
-- Page fetched on Mon May 6 11:02:33 2024