[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 draft-ietf-rmt-flute-sdp

RMT                                                             H. Mehta
Internet-Draft                                                  R. Walsh
Expires: April 22, 2005                                            Nokia
                                                            J. Peltotalo
                                                            S. Peltotalo
                                        Tampere University of Technology
                                                        October 22, 2004


                       SDP Descriptors for FLUTE
                     draft-mehta-rmt-flute-sdp-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 22, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document specifies the use of SDP to describe the parameters
   required to begin, join, receive data from, and end FLUTE sessions.





Mehta, et al.            Expires April 22, 2005                 [Page 1]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  FLUTE Descriptors  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   FLUTE Protocol Identifier  . . . . . . . . . . . . . . . .  5
     3.2   Source IP Address  . . . . . . . . . . . . . . . . . . . .  6
     3.3   Transport Session Identifier . . . . . . . . . . . . . . .  6
     3.4   Session Timing Parameters  . . . . . . . . . . . . . . . .  6
     3.5   Channelisation Descriptors . . . . . . . . . . . . . . . .  7
       3.5.1   Number of Channels . . . . . . . . . . . . . . . . . .  7
       3.5.2   Destination IP Address and Port Number for Channels  .  7
     3.6   FEC Object Transmission Information  . . . . . . . . . . .  9
     3.7   Content Description  . . . . . . . . . . . . . . . . . . . 11
       3.7.1   Content Description Pointer  . . . . . . . . . . . . . 11
       3.7.2   The Media Types of Files . . . . . . . . . . . . . . . 11
   4.  SDP Syntax Example . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     6.1   Transport Protocol . . . . . . . . . . . . . . . . . . . . 15
     6.2   Attribute Names  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 18
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
       Intellectual Property and Copyright Statements . . . . . . . . 21
























Mehta, et al.            Expires April 22, 2005                 [Page 2]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


1.  Introduction

   The Session Description Protocol (SDP) [6] provides a general-purpose
   format for describing multimedia sessions in announcements or
   invitations.  SDP uses an entirely textual data format (the US-ASCII
   subset of UTF-8 [9]) to maximize portability among transports.  SDP
   does not define a protocol, but only the syntax to describe a
   multimedia session with sufficient information to participate in that
   session.  Session descriptions may be sent using arbitrary existing
   application protocols for transport (e.g.  FLUTE [1], SAP [13], SIP
   [14], HTTP [15], email etc.).

   SDP defines two protocol identifiers that represent unreliable
   connectionless protocols.  These are RTP/AVP and UDP.  These are
   appropriate choices for multimedia streams.  [16] defines protocol
   identifiers for connection-oriented reliable transports: TCP and
   TCP/TLS.  RFC 3266 [7] describes SDP support for IPv6.

   This document defines a new protocol identifier for File Delivery
   over Unidirectional Transport (FLUTE) protocol [1] and other required
   SDP attributes for initiating a FLUTE session.  The formal ABNF
   syntax [5] is used for the attributes.





























Mehta, et al.            Expires April 22, 2005                 [Page 3]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


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 [2].














































Mehta, et al.            Expires April 22, 2005                 [Page 4]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


3.  FLUTE Descriptors

   The FLUTE specification [1] describes the optional and required
   parameters for a FLUTE session.  This document specifies the SDP
   parameters for FLUTE sessions that can be used for the discovery of
   FLUTE download and service announcement sessions.

   The required parameters are:

   o  The source IP address
   o  The number of channels in the session
   o  The destination IP address and port number for each channel in the
      session
   o  The Transport Session Identifier (TSI) of the session
   o  The start time and end time of the session

   Optionally, the following parameters may be associated with the
   session:

   o  FEC Object Transmission Information
   o  Some information that tells receiver in the first place, that the
      session contains files that are of interest

   The description of these parameters in SDP is presented in the
   following sections.  Note also that "v=", "o=" and "s=" lines are
   mandatory for SDP description.

3.1  FLUTE Protocol Identifier

   The following is the ABNF syntax for an "m=" line, as specified by
   RFC 2327 [6]:

      media-field = "m=" media space port ["/" integer] space
                    proto 1*(space fmt) CRLF

   We define a new value for the "proto" sub-field: FLUTE/UDP.  The
   FLUTE/UDP protocol identifier specifies that the session being
   described will use the File Delivery over Unidirectional Transport
   (FLUTE) protocol on top of a UDP connection.  All media with this
   protocol identifier belong to the same FLUTE session.

   An "m=" line that contains the FLUTE/UDP protocol identifier MUST set
   an "fmt" sub-field to zero.

   Each complete SDP session description will describe only one FLUTE
   session.  This arises from the limitation of SDP that no
   session-level details can be specified after the "m=" line.




Mehta, et al.            Expires April 22, 2005                 [Page 5]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


3.2  Source IP Address

   The Asynchronous Layered Coding (ALC) [3] and the Layered Coding
   Transport (LCT) [4] specifications requires that all the channels of
   a single ALC/LCT session are from the same source IP address.  Hence,
   there MUST be exactly one source IP address per FLUTE session, and
   therefore one source IP address per each complete SDP description of
   a FLUTE session.

   The source IP address shall be defined according to the source-filter
   attribute ("a=source-filter") [8], with the following exceptions:

   o  Exactly one source address may be specified by this attribute such
      that exclusive-mode shall not be used and inclusive-mode shall use
      exactly one source address in the "src-list".
   o  There shall be exactly one source-filter attribute per complete
      FLUTE session SDP description, and this shall be in the session
      part of the session description (i.e.  not per media).
   o  The * value shall be used for the "dest-address" sub-field, even
      when the FLUTE session employs only a single channel (e.g.
      multicast group).

   An example of the use of this attribute is:

      a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

   This example uses the source-filter attribute to describe an IPv6
   source address.

3.3  Transport Session Identifier

   The combination of the TSI and the source IP address identifies the
   session.  Each TSI MUST uniquely identify a FLUTE session for a given
   source IP address during the time that the session is active and also
   for a large time before and after the active session time.  This
   requirement is also specified by [4].  There MUST be exactly one
   occurrence of the "flute-tsi" attribute in a complete FLUTE session
   SDP description and it MUST appear at the session-level.

   The syntax for the attribute in ABNF is given below:

      sdp-flute-tsi-line = "a=flute-tsi:" value CRLF
      where value = %d


3.4  Session Timing Parameters

   The SDP timing field "t=" [6] must be used to indicate the FLUTE



Mehta, et al.            Expires April 22, 2005                 [Page 6]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


   session start and end times.

3.5  Channelisation Descriptors

   This section specifies the description of the channel(s) used within
   a FLUTE session.  The required parameters for channelisation
   description are:

   o  Number of channels
   o  Destination IP address and port number for channels

3.5.1  Number of Channels

   The FLUTE specification allows the use of multiple channels (e.g.
   multicast groups) to transport the files of a single FLUTE session.
   This is referred to as FLUTE session channelisation in this document.
   A FLUTE channel is equivalent to an ALC/LCT channel.  An ALC/LCT
   channel is defined by the combination of a sender and an address
   associated with the channel by the sender.  FLUTE session
   channelisation is defined according to a new SDP attribute at
   session-level as specified in this document.  Details of each channel
   are defined by SDP media-level information also described in this
   document.

   The "flute-ch" attribute describes the number of channels used by the
   source to transmit.  It may also be used to check that right amount
   of channel descriptions exists in the session description.  For
   example, if the value of this attribute is 2, then there should be 2
   channels specified by the "m=" line(s) and the "c=" line(s).  An
   example is given in section 4.

   The syntax for the attribute in ABNF is given below:

      sdp-flute-channel-line = "a=flute-ch:" value CRLF
      where value = %d,
      value is the number of channels used by the source to
      transmit data in a FLUTE session.

   In the absence of this attribute, a receiver shall understand that
   exactly one channel is used for the FLUTE session.

3.5.2  Destination IP Address and Port Number for Channels

   SDP media-level information describes one or more channels.  Channel
   parameters shall be per channel:

   o  Destination IP address




Mehta, et al.            Expires April 22, 2005                 [Page 7]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


   o  Destination port number

   The destination IP address shall be defined according to the
   connection data field ("c=") of SDP [6].  The destination port number
   shall be defined according to the "port" sub-field of the media
   description field ("m=") of SDP [6].

   A "c=" line can describe multiple addresses by using "number of
   addresses" sub-field, and also an "m=" line can describe multiple
   ports by using "number of ports" sub-field.  So multiple channels can
   be described by using one "c=" line and one "m=" line (slash
   notation).

   Exactly one destination port MUST be used per channel.  When more
   than one channel is used in a multicast session, it is recommended
   that the channels are differentiated based on destination IP address,
   and channel differentiation based on destination port with the same
   destination address is considered unnecessary, complex and
   potentially harmful.  When more than one channel is used in a unicast
   session, the channels have to be differentiated based on destination
   ports.

   In the case (always with a unicast session) where the same
   destination IP address is used for all the channels of the session
   and only the destination port number differentiates channels, the
   destination IP address may be given by the connection data field at
   session-level for all channels (if so, the connection data field
   shall not be used at media-level).

   In the case where each channel have different destination IP address,
   the destination IP addresses must be given at media-level, i.e.
   following an "m=" line.

   The sequence of multiple channels shall be determined by the order in
   which their media descriptions are defined in the session description
   (i.e.  the first media description gives the first channel in the
   sequence).  In the case of the slash notation usage for specifying
   multiple destination addresses or ports, the order of the channel
   sequence shall be lowest value first and highest last; and in the
   case of slash notation for both destination address and port of a
   media-level description the channel sequence will be from the lowest
   address value and incremented through the range.

   Also we need to indicate the presence of a FLUTE session on certain
   channel.  This is done by using the "m=" line in the SDP description
   as shown in the following example:

      m=application 12345 FLUTE/UDP 0



Mehta, et al.            Expires April 22, 2005                 [Page 8]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


      c=IN IP6 FF1E:03AD::7F2E:172A:1E24

   In the above SDP attributes, the "m=" line indicates the media used
   and the "c=" line together with "m=" line's "port" sub-field
   indicates the corresponding channel's address and port respectively.
   Thus, in the above example, the media is transported on a channel
   that uses FLUTE over UDP.  Further, the "c=" line indicates the
   channel's address, which, in this case, is an IPv6 address, and "m="
   line indicates the channel's port (12345).

3.6  FEC Object Transmission Information

   An SDP description for FLUTE session may include FEC Object
   Transmission Information (FEC-OTI) [12].  FEC parameters can be
   placed either in session-level or in media-level, recommendation is
   to place those in session-level.  FEC parameters include:

   o  FEC Encoding ID
   o  FEC Instance ID (for FEC Encoding IDs 128-255)

   <Note, these might be further extended with other FEC-OTI information
   depending on review of assumptions and consensus.>

   FEC parameters are described in "FEC-declaration" attribute.
   Multiple instances of this attribute may exists both at session-level
   and media-level.  If it exists at session-level a reference to it may
   be used in media-level, and an attribute "FEC" is defined for this
   purpose.

   The syntax for the attributes in ABNF is given below:

      sdp-fec-declaration-line = "a=FEC-declaration:" value SP
                                 fec-enc-id "; [SP fec-inst-id] CRLF
      where value = %d,
      value is the identifier for FEC-declaration.

      fec-enc-id = "encoding-id=" value
      where value = %d,
      value is the used FEC Encoding ID.

      fec-inst-id = "instance-id=" value
      where value = %d,
      value is the used FEC Instance ID.

      sdp-fec-line = "a=FEC:" value CRLF
      where value = %d,
      value is the FEC-declaration identifier.




Mehta, et al.            Expires April 22, 2005                 [Page 9]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


   The FEC parameters are for capabilities description for the session.
   (Note, any "FDT-like" fuller description of files in the session
   could give the FEC parameters per file).  FLUTE's FDT syntax (and
   codepoint header field usage) allows complete specification of these
   FEC parameters in-band with FLUTE (per file).  Thus machine
   configuration can be performed using FLUTE alone.

   There are five main reasons that the FEC Encoding and Instance IDs
   are optional capabilities descriptions:

   1.  It is not always necessary to explicitly describe the FEC
       capabilities in advance of the session - e.g.  for simple (and
       short) sessions it can be more elegant to discover this from the
       session (FDT) itself (even when some mechanism for
       machine-readable session parameters, such as IP addresses and
       ports, is wanted in advance).
   2.  There may be some other out-of-band discovery of FEC capability
       requirements (e.g.  well known-FEC/standardised capabilities for
       a certain application, verbal agreement between a group, etc.)
       that provides the FEC capability information.  We do not want to
       prevent this, and in this case repeating the information in SDP
       would be unnecessary and wasteful (and probably result in
       implementations not following the flute-sdp specification).
   3.  FLUTE defaults to Compact No-Code FEC [11] and support for this
       is mandatory for FLUTE anyway so it is a given (capability
       requirement) which does not need to be described by the SDP.  In
       cases where only Compact No-Code FEC is required, there is no use
       in specifying any FEC Encoding (+Instance) IDs in the SDP (though
       it is allowed).
   4.  In cases where a FLUTE session description (SDP file) is not
       defined once for all time, it is possible that the FEC usage is
       not known in advance and the FEC capabilities would only be added
       to the SDP in a later version of that SDP file when the FEC codes
       have been selected (e.g.  a larger audience may suggest stronger
       FEC to make FLUTE delivery more reliable, whereas additional
       bi-directional messages may be scalable for smaller groups).
   5.  Also, in cases where a FLUTE session description (SDP file) is
       very static (e.g.  once for all time for that session), it is
       possible that the FEC usage is not known in advance and it needs
       to be left to some other mechanism (e.g.  FDT) to discover any
       FEC capability requirements set closer to the session
       transmission - with the same examples as in (4).

   Also, in a complex case of very many FEC codes being used in the
   session we do not see that giving a full list in SDP is reasonable
   (but this is likely to be a rare case anyway).

   <The description of layered media and identification of any



Mehta, et al.            Expires April 22, 2005                [Page 10]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


   congestion control (CC) instance related to them is orthogonal to the
   FEC declarations and other aspect of this document.  Hence, the
   authors assume layering and CC descriptions are not in scope of this
   document.  This assumption is subject to further study.>

3.7  Content Description

   In the context of a FLUTE session, two forms of content description
   are important:

   o  The out-of-band URI (content description pointer) that may signal
      to the receiver that the FLUTE session is transmitting something
      of interest, and,
   o  The media type(s) of the files being transmitted during the FLUTE
      session.

3.7.1  Content Description Pointer

   The syntax of the information that tells receiver, in the first
   place, that the session contains files that are of interest is out of
   scope of this document.  However, the SDP may include a content
   description pointer at the session-level to enable efficient linkage
   to such information.

   The content description pointer attribute describes to the
   receiver(s) the URI where the content description is stored.  The
   content description pointer shall be defined according to the
   "content-desc" attribute.

   The syntax for the attribute in ABNF is given below:

      sdp-content-desc-line = "a=content-desc:" URI-reference CRLF
      where URI-reference = as defined in RFC 2396

   URI for the content description must conform to the RFC2396 [10].

3.7.2  The Media Types of Files

   <TBD>












Mehta, et al.            Expires April 22, 2005                [Page 11]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


4.  SDP Syntax Example

   This section gives an example of the use of SDP attributes to
   describe a FLUTE session.

         v=0
         o=user123 2890844526 2890842807 IN IP6
          2201:056D::112E:144A:1E24
         s=File delivery session example
         i=More information
         t=2873397496 2873404696
         a=source-filter: incl IN IP6 *
          2001:210:1:2:240:96FF:FE25:8EC9
         a=flute-tsi:3
         a=flute-ch:2
         a=FEC-declaration:0 encoding-id=0
         a=FEC-declaration:1 encoding-id=128; instance-id=0
         m=application 12345 FLUTE/UDP 0
         c=IN IP6 FF1E:03AD::7F2E:172A:1E24
         a=FEC:0
         m=application 12346 FLUTE/UDP 0
         c=IN IP6 FF1E:03AD::7F2E:172A:1E25
         a=FEC:1

   The attribute defined in the line "a=source-filter: incl IN IP6 *
   2001:210:1:2:240:96FF:FE25:8EC9" describes a source filter.  In this
   example the source indicates that the receiver(s) should include the
   given IP address (2001:210:1:2:240:96FF:FE25:8EC9) into the session.
   It should be noted that although other possibilities may be used, in
   this case only the incl and * attributes may be used in the above
   attribute.

   The attribute TSI defined in the line "a=flute-tsi:3" describes the
   Transmission Session Identifier for the session.  Pair of the source
   IP address and the TSI together uniquely identifies a session.

   The source indicates in the above example that it will transmit data
   in the FLUTE session on two channels (a=flute-ch:2).  The source then
   specifies the channels.

   The "a=FEC-declaration" lines describes two different FEC schemes
   used in the FLUTE session.

   The line "m=data 12345 FLUTE/UDP" indicates the media used for the
   channel.  In this example, there are two "m=" lines for the two
   channels described.

   The destination addresses for the channels are given in the "c="



Mehta, et al.            Expires April 22, 2005                [Page 12]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


   lines.  These also shows to the receiver(s) that the channels are two
   (maybe more in other cases) consecutive channels.

   The "a=FEC" lines at media-level references to FEC declarations at
   session-level ("a=FEC-declaration").














































Mehta, et al.            Expires April 22, 2005                [Page 13]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


5.  Security Considerations

   <TBD>
















































Mehta, et al.            Expires April 22, 2005                [Page 14]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


6.  IANA Considerations

6.1  Transport Protocol

   The "proto" sub-field off the media description field ("m=")
   describes the transport protocol used.  This document registers one
   value: "FLUTE/UDP" is a reference to FLUTE [1] running over UDP/IP.

6.2  Attribute Names

   As recommended by RFC2327 [6], the new attribute names "flute-tsi",
   "flute-ch", "FEC-declaration", "FEC" and "content-desc" should be
   registered with IANA, as follows:

   The following contact information shall be used for all registrations
   included here:

      Contact:      Rod Walsh
                    EMail: rod.walsh (at) nokia.com

   SDP Attribute ("att-field"):
     Attribute name:     flute-tsi
     Long form:          FLUTE Transport Session Identifier
     Type of name:       att-field
     Type of attribute:  Session level
     Subject to charset: No
     Purpose:            See this document
     Reference:          This document
     Values:             See this document

   SDP Attribute ("att-field"):
     Attribute name:     flute-ch
     Long form:          Number of Channels in a FLUTE Session
     Type of name:       att-field
     Type of attribute:  Session level
     Subject to charset: No
     Purpose:            See this document
     Reference:          This document
     Values:             See this document

   SDP Attribute ("att-field"):
     Attribute name:     FEC-declaration
     Long form:          Forward Error Correction Declaration
     Type of name:       att-field
     Type of attribute:  Session level or media level
     Subject to charset: No
     Purpose:            See this document
     Reference:          This document



Mehta, et al.            Expires April 22, 2005                [Page 15]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


     Values:             See this document

   SDP Attribute ("att-field"):
     Attribute name:     FEC
     Long form:          A Reference to FEC Declaration
     Type of name:       att-field
     Type of attribute:  Media level
     Subject to charset: No
     Purpose:            See this document
     Reference:          This document
     Values:             See this document

   SDP Attribute ("att-field"):
      Attribute name:     content-desc
      Long form:          Content Description Pointer
      Type of name:       att-field
      Type of attribute:  Session level
      Subject to charset: No
      Purpose:            See this document
      Reference:          This document
      Values:             See this document






























Mehta, et al.            Expires April 22, 2005                [Page 16]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


7.  Acknowledgements

   The authors would like to thank all the people who gave feedback on
   this document.















































Mehta, et al.            Expires April 22, 2005                [Page 17]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


8.  References

8.1  Normative References

   [1]   Paila, T., Luby, M., Lehtonen, R., Roca, V. and R. Walsh,
         "FLUTE - File Delivery over Unidirectional Transport", RFC
         3926, October 2004.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCD 14, March 1997.

   [3]   Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J.
         Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
         Instantiation", RFC 3450, December 2002.

   [4]   Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
         J. Crowcroft, "Layered Coding Transport (LCT) Building Block",
         RFC 3451, December 2002.

   [5]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [6]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [7]   Olson, S., Camarillo, G. and A. Roach, "Support for IPv6 in
         Session Description Protocol (SDP)", RFC 3266, June 2002.

   [8]   Quinn, B. and R. Finlayson, "Session Description Protocol (SDP)
         Source Filters", draft-ietf-mmusic-sdp-srcfilter-06 (work in
         progress), July 2004.

   [9]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         3629, November 2003.

   [10]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [11]  Luby, M. and L. Vicisano, "Compact Forward Error Correction
         (FEC) Schemes", RFC 3695, February 2004.

   [12]  Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
         J. Crowcroft, "Forward Error Correction (FEC) Building Block",
         RFC 3452, December 2002.






Mehta, et al.            Expires April 22, 2005                [Page 18]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


8.2  Informative References

   [13]  Handley, M., Perkins, C. and E. Whelan, "Session Announcement
         Protocol", RFC 2974, October 2000.

   [14]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "Session
         Initiation Protocol", RFC 3261, June 2002.

   [15]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., Berners-Lee, T. and E. Schooler, "Hypertext Tansfer
         Protocol -- HTTP/1.1", RFC 3261, June 2002.

   [16]  Yon, D. and G. Camarillo, "Connection-Oriented Media Transport
         in the Session Descript Protocol (SDP)",
         draft-ietf-mmusic-sdp-comedia-09 (work in progress), September
         2004.


Authors' Addresses

   Harsh Mehta
   Nokia
   P.O. Box 100 (Visiokatu 1)
   Tampere  FIN-33721
   Finland

   EMail: harsh.mehta (at) nokia.com


   Rod Walsh
   Nokia
   P.O. Box 100 (Visiokatu 1)
   Tampere  FIN-33721
   Finland

   EMail: rod.walsh (at) nokia.com


   Jani Peltotalo
   Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere  FIN-33101
   Finland

   EMail: jani.peltotalo (at) tut.fi





Mehta, et al.            Expires April 22, 2005                [Page 19]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


   Sami Peltotalo
   Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere  FIN-33101
   Finland

   EMail: sami.peltotalo (at) tut.fi












































Mehta, et al.            Expires April 22, 2005                [Page 20]

Internet-Draft         SDP Descriptors for FLUTE            October 2004


Intellectual Property Statement

   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 procedures with respect to rights in RFC 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.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 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.


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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Mehta, et al.            Expires April 22, 2005                [Page 21]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/