Distributed System Security Symposium, NDSS 2001, pp. 35-46.",
February 2001.
[15] Holbrook, H., "A Channel Model for Multicast, Ph.D.
Dissertation, Stanford University, Department of Computer
Science, Stanford, California", August 2001.
[16] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[17] Deutsch, P., "GZIP file format specification version 4.3", RFC
1952, May 1996.
[18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[19] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, March
2002.
[20] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", RFC
2048, November 1996.
[21] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 1521,
November 1996.
[22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
session initiation protocol", RFC 3261, June 2002.
Appendix A. Receiver operation (informative)
This section gives an example how the receiver of the file delivery
session may operate. Instead of a detailed state-by-state
specification the following should be interpreted as a rough sequence
of an envisioned file delivery receiver.
1. The receiver obtains the description of the file delivery session
identified by the pair: (source IP address, Transport Session
Identifier). The receiver also obtains the destination IP
addresses and respective ports associated with the file delivery
session.
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.
3. The receiver receives ALC/LCT packets associated with the file
delivery session. The receiver checks that the packets match the
declared Transport Session Identifier. If not, packets are
silently discarded.
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.
5. Receiver recovers an object. An object can be recovered when an
appropriate set of packets containing Encoding Symbols for the
transport object have been received. An appropriate set of
packets is dependent on the properties of the FEC Encoding ID and
FEC Instance ID, and on other information contained in the FEC
Object Transmission Information.
6. If the recovered object was an FDT Instance with FDT Instance ID
’N’, the receiver parses the payload of the instance ’N’ of FDT
and updates its FDT database accordingly. The receiver identifies
FDT Instances within a file delivery session by the EXT_FDT header
extension. Any object that is delivered using EXT_FDT header
extension is an FDT Instance, uniquely identified by the FDT
Instance ID. Note that TOI ’0’ is exclusively reserved for FDT
delivery.
7. If the object recovered is not an FDT Instance but a file, the
receiver looks up its FDT database to get the properties described
in the database, and assigns file with the given properties. The
receiver also checks that received content length matches with the
description in the database. Optionally, if MD5 checksum has been
used, the receiver checks that calculated MD5 matches with the
description in the FDT database.
8. The actions the receiver takes with imperfectly received files
(missing data, mismatching digestive, etc.) is outside the scope
of this specification. When a file is recovered before the
associated file description entry is available, a possible
behavior is to wait until an FDT Instance is received that
includes the missing properties.
9. If the file delivery session end time has not been reached go back
to 3. Otherwise end.
Appendix B. Example of FDT Instance (informative)
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:fl="http://www.example.com/flute"
xsi:schemaLocation="http://www.example.com/flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>
Authors’ Addresses
Toni Paila
Nokia
Itamerenkatu 11-13
Helsinki FIN-00180
Finland
EMail: toni.paila@nokia.com
Michael Luby
Digital Fountain
39141 Civic Center Dr.
Suite 300
Fremont, CA 94538
USA
EMail: luby@digitalfountain.com
Rami Lehtonen
TeliaSonera
Hatanpaan valtatie 18
Tampere FIN-33100
Finland
EMail: rami.lehtonen@teliasonera.com
Vincent Roca
INRIA Rhone-Alpes
655, av. de l’Europe
Montbonnot
St Ismier cedex 38334
France
EMail: vincent.roca@inrialpes.fr
Rod Walsh
Nokia
Visiokatu 1
Tampere FIN-33720
Finland
EMail: rod.walsh@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.