[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 6262

Audio/Video Transport Working Group                      Andrey Setsko
Internet Draft                                              SPIRIT DSP
Intended status: Informational                          April 02, 2008
Expires: September 03, 2008



    RTP Payload Format for SPIRIT IP-MR Speech Codec Software
                     draft-ietf-avt-rtp-ipmr-00.txt

Status of this Memo

  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
  becomes aware will be disclosed, in accordance with Section 6 of
  BCP 79.

  This document may not be modified, and derivative works of it may not
  be created, except to publish it as an RFC and to translate it into
  languages other than English.

  This document may only be posted in an Internet-Draft.

  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 September 03, 2008.

Copyright Notice

  Copyright (C) The IETF Trust (2007).

A.Setsko                  Expires September 03, 2008          [Page  1]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

Abstract

  This document specifies the payload format for packetization of
  SPIRIT IP-MR encoded speech signals into the Real-time Transport
  Protocol (RTP). The payload format supports transmission of multiple
  frames per payload, introduced redundancy for robustness against
  packet loss, and payload format extension for future versions
  compatibility.

Table of Contents

  1. Introduction                                                    2
  2. IP-MR RTP Payload Formats                                       3
     2.1. Standard Payload Format                                    3
        2.1.1. Payload Format Structure                              3
        2.1.2. Payload Header                                        3
        2.1.3. Speech Table of Contents                              5
        2.1.4. Speech Data                                           5
        2.1.5. Redundancy Header                                     5
        2.1.6. Redundancy Table of Contents                          6
        2.1.7. Redundancy Data                                       6
     2.2. Payload Examples                                           8
        2.2.1. Standard Payload Carrying a Single Frame              8
        2.2.2. Standard Payload Carrying Multiple Frames with
               Redundancy                                            8
        2.2.3. Extended Payload Carrying a Single Frame             10
  3. Media Type Registration                                        10
     3.1. Registration of MIME media type audio/ip-mr_v2.5          10
     3.2. Mapping Media Type Parameters into SDP                    11
  4. Security Consideration                                         12
  5. Acknowledgments                                                12
  6. Normative References                                           12
  Author's Addresses                                                12
  Intellectual Property Statement                                   13
  Disclaimer of Validity                                            13

A.Setsko                  Expires September 03, 2008           [Page  2]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

1. Introduction
  This document specifies the payload format for packetization of
  SPIRIT IP-MR encoded speech signals into the Real-time Transport
  Protocol (RTP). The payload format supports transmission of multiple
  frames per payload, introduced redundancy for robustness against
  packet loss, and payload format extension for future versions
  compatibility.

2. IP-MR RTP Payload Formats
  The payload has two formats: standard optimized for current use-cases
  and extended for future versions compatibility. The payload format is
  defined by first bit of header. Both of these formats will be
  described bellow.

2.1. Standard Payload Format

2.1.1. Payload Format Structure

  The standard payload consists of a payload header with general
  information about packet, a speech table of contents (TOC), and
  speech data. An optional redundancy section follows after speech
  data. The redundancy section consists of redundancy header,
  redundancy TOC and redundancy data payload.
  The following diagram shows the standard payload format layout:
  +---------+--------+--------+- - - - - - +- - - - - - +- - - - - - +
  | payload | speech | speech | redundancy | redundancy | redundancy |
  | header  | TOC    | data   | header     | TOC        | data       |
  +---------+--------+--------+- - - - - - +- - - - - - +- - - - - - +

2.1.2. Payload Header

  The payload header has the following format:
   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+
  |T| CR  | BR  |D|A|GR |R|
  +-+-+-+-+-+-+-+-+-+-+-+-+

  o  T (1 bit): Reserved compatibility with future extensions. Should be set
  to 0.

A.Setsko                  Expires September 03, 2008           [Page  3]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

  o  CR (3 bits): coding rate of frame(s) in this packet, as per the
     following table:
               +-------+--------------+
               |  CR   | avg. bitrate |
               +-------+--------------+
               |   0   |   7.7 kbps   |
               |   1   |   9.8 kbps   |
               |   2   |  14.3 kbps   |
               |   3   |  20.8 kbps   |
               |   4   |  27.9 kbps   |
               |   5   |  34.2 kbps   |
               |   6   |  (reserved)  |
               |   7   |   NO_DATA    |
               +-------+--------------+
  Table 1 Coding rates of IP-MR codec

  The CR value 7 (NO_DATA) indicates that there is no speech data (and
  speech TOC accordingly) in the payload. This MAY be used to transmit
  redundancy data only. The value 6 is reserved. If receiving this
  value the packet SHOULD be discarded.

  o  BR (3 bits): base rate for core layer of frame(s) in this packet.
     Values in the range 0-5 indicate bitrates for core layer, same as
     for CR. Values 6 and 7 are reserved. If one of these values is
     received the packet SHOULD be discarded. The base rate is the
     lowest rate for scalability, so speech payload can be scaled down
     not lower than BR value. If a received packet has BR > CR then
     during decoding it will be assumed that BR = CR.

  o  D (1 bit): indicates if the DTX mode is allowed or not.

  o  A (1 bit): byte-aligned payload. If A=1 then all speech frames
     MUST be byte-aligned. This mode speeds up speech data access. The
     A=0 value specifies bandwidth-efficient mode with no byte
     alignment (including end of header).

  o  GR (2 bits): number of frames in packet (grouping size). Actual
     grouping size is GR + 1, thus maximum grouping supported is 4. If
     greater grouping size is required the extended payload format
     (sec. 2.2) MAY be used.

A.Setsko                  Expires September 03, 2008           [Page  4]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

  o  R (1 bit): redundancy presence bit. If R=1 then the packet
     contains redundancy information for lost packets recovery. In this
     case after speech TOC redundancy flags and TOC sections are
     present. If R=0 then speech TOC is the last section of payload
     header.

2.1.3. Speech Table of Contents

  The speech TOC contains entries for each frame in packet (grouping
  size in total). Each entry contains a single field:

   0
  +-+
  |E|
  +-+

  o  E (1 bit): frame existence indicator. If set to 0, this indicates
     the corresponding frame is absent and the receiver should set the
     teRxFrType to LOST_FRAME. This can be followed by the lost frame
     itself or by empty frames generated by the encoder during silence
     intervals in DTX mode.

  Note that if CR field from coding flags is 7 (NO_DATA) then speech
  TOC is empty.

2.1.4. Speech Data

  Speech data of a payload contains one or more speech frames or
  comfort noise frames, as specified in the speech TOC of the payload.

  Each speech frame represents 20 ms of speech encoded with the rate
  indicated in the CR and base rate indicated in BR field of the
  payload header. The length of the speech frame is variable due to the
  nature of the codec and can be calculated after decoding or by using
  GetFrameInfo function detailed in [1].

2.1.5. Redundancy Header

  If a packet contains redundancy (R field of payload header is 1) the
  speech data is followed by redundancy header:

A.Setsko                  Expires September 03, 2008           [Page  5]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

   0 1 2 3 4 5
  +-+-+-+-+-+-+
  | CL1 | CL2 |
  +-+-+-+-+-+-+

  Redundancy header consists of two fields. Each field contains class
  specifier for redundancy partly taken from the preceding packet (CL1)
  and pre-preceding packet (CL2), e.g. distant from the current packet
  by 1 and 2 packets accordingly. The values are listed in the table
  below:
            +-------+-------------------+
            |  CL   | amount redundancy |
            +-------+-------------------+
            |   0   |       NONE        |
            |   1   |      CLASS A      |
            |   2   |      CLASS B      |
            |   3   |      CLASS C      |
            |   4   |      CLASS D      |
            |   5   |      CLASS E      |
            |   6   |      CLASS F      |
            |   7   |     (reserved)    |
            +-------+-------------------+

  Each specifier takes 3 bits, thus the total redundancy header size is
  6 bits. In case of redundancy usage followed by preceding (or pre-
  preceding) packet loss the receiver sets the special flag for decoder
  with CL class specifier.

2.1.6. Redundancy Table of Contents

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Pkt1 Entries| Pkt2 Entries|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The redundancy TOC contains entries for redundancy frames from
  preceding and pre-preceding packets. Each entry takes 1 bit like
  speech TOC entry (2.1.3):
   0
  +-+
  |E|
  +-+

  o  E (1 bit): frame existence indicator. If set to 0, this indicates
     the corresponding frame is absent.

A.Setsko                  Expires September 03, 2008           [Page  6]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

  o  For each preceding and pre-preceding packet the number of entries
     is equal to the grouping size of the current packet. E.g. maximum
     number of entries is 4*2 = 8.

  o  If class specifier in the redundancy header is CL=0 (NO_DATA) then
     there?s no entries for corresponding packet redundancy.

2.1.7. Redundancy Data

  Redundancy data of a payload contains redundancy information for one
  or more speech frames or comfort noise frames that may be lost during
  transition, as specified in the redundancy TOC of the payload.
  Actually redundancy is the most important part of preceding frames
  representing 20 ms of speech. The length of redundancy frame is
  variable and can be calculated after decoding or by using
  GetFrameInfo function detailed in [1].

A.Setsko                  Expires September 03, 2008           [Page  7]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007


2.2. Payload Examples

2.2.1. Standard Payload Carrying a Single Frame

  The following diagram shows a standard IP-MR payload carrying a
  single speech frame without redundancy:
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|CR=1 |BR=0 |0|0|0 0|0|1|sp(0)                                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      sp(193)|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  In the payload the speech frame is not damaged at the IP origin
  (E=1), the coding rate is 9.7 kbps (CR=1), the base rate is 7.8 kbps
  (BR=0), and the DTX mode is off. There is no byte alignment (A=0) and
  no redundancy (R=0). The encoded speech bits - s(0) to s(193) - are
  placed immediately after TOC. Finally, one zero bit is added at the
  end as padding to make the payload byte aligned.

2.2.2. Standard Payload Carrying Multiple Frames with Redundancy

  The following diagram shows a payload that contains three frames, one
  of them with no speech data.  The coding rate is 7.7 kbps (CR=0), the
  base rate is 7.7 kbps (BR=0), and the DTX mode is on. The speech
  frames are byte aligned (A=1), so 1 zero bit is added at the end of
  the header. Besides the speech frames the payload contains six
  redundancy frames (three per each delayed packet).

  The first speech frame consists of bits sp1(0) to sp1(92). After that
  3 bits are added for byte alignment. The second frame does not
  contain any speech information that is represented in the payload by
  its TOC entry. The third frame consists of bits sp3(0) to sp3(171).

A.Setsko                  Expires September 03, 2008           [Page  8]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

  The redundancy header follows after speech data. The one-packet-
  delayed redundancy contains class A+B bits (CL1=2), and two-packet-
  delayed redundancy contains class A bits (Cl2=1). The one-packet-
  delayed redundancy contains three frames with 20, 39 and 35 bits
  respectively. The first frame of two-packet-delayed redundancy is
  absent, it is represented in its TOC entry, and two other frames have
  sizes 15 and 19 bits.

  Note that all speech frames are padded with zero bits for byte
  alignment.

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|CR=2 |BR=1 |1|1|1 0|1|1 0 1|P|sp1(0)                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  sp1(92)|P|P|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |sp3(0)                                                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                               sp3(171)|P|P|P|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |CL1=2|CL2=1|1 1 1|0 1 1|red1_1(0)                    red1_1(19)|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |red1_2(0)
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   red1_2(38)|red1_3(0)                                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         red1_3(34)|red2_2(0)          red2_2(14)|red2_3(0)    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             red2_3(18)|P|P|P|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.Setsko                  Expires September 03, 2008           [Page 9]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007


2.2.3. Extended Payload Carrying a Single Frame

  The following diagram shows an extended IP-MR payload carrying a
  single speech frame without redundancy:

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1|CR=1 |BR=0 |0|0|0 0|0|1|P|P|P|0 1 1|0| header extension data |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               |sp(0)                                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            sp(193)| optional payload extenson ...
  +-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - -

  The standard header is the same as in example 2.3.1 except for the
  first bit that is set to 1 to reflect extended payload type. The
  standard header is padded with zeros to achieve byte alignment. After
  that the size of header extension follows (HESZ=3). Then the header
  extension data is placed. In 3 bytes (HESZ) from header extension
  beginning, the standard speech payload starts. After that, the
  optional payload extension MAY be added.

3. Media Type Registration

  This section describes the media types and names associated with this
  payload format.

3.1. Registration of MIME media type audio/ip-mr_v2.5

  Type name: audio

  Subtype name:          ip-mr_v2.5

A.Setsko                  Expires September 03, 2008           [Page 10]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

  Required parameters:  none

  Optional parameters:

  o  ptime: Gives the length of time in milliseconds represented by the
     media in a packet. Allowed values are: 20, 40, 60 and 80.

  Encoding considerations:
     This media type is framed binary data (see RFC 4288, Section 4.8).

  Security considerations: See RFC 3550

  Applications that use this media type:
      Audio and video streaming and conferencing tools.

  Additional information: none

  Person & email address to contact for further information:
     Andrey Setsko <Setsko@spiritdsp.com>

  Intended usage: COMMON

  Restrictions on usage:
     This media type depends on RTP framing, and hence is only
     defined for transfer via RTP (RFC 3550).

  Author:
     Andrey Setsko

3.2. Mapping Media Type Parameters into SDP

  The information carried in the media type specification has a
  specific mapping to fields in the Session Description Protocol (SDP)
  [RFC4566], which is commonly used to describe RTP sessions.  When SDP
  is used to specify sessions employing the IP-MR codec, the mapping is
  as follows:

  o  The media type ("audio") goes in SDP "m=" as the media name.

  o  The media subtype (payload format name) goes in SDP "a=rtpmap" as
     the encoding name. The RTP clock rate in "a=rtpmap" MUST 16000.

  o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
     "a=maxptime" attributes, respectively.

A.Setsko                  Expires September 03, 2008           [Page 11]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

  Any remaining parameters go in the SDP "a=fmtp" attribute by copying
  them directly from the media type parameter string as a semicolon-
  separated list of parameter=value pairs.

4. Security Considerations

  RTP packets using the payload format defined in this specification
  are subject to the security considerations discussed in the RTP
  specification [RFC3550], and any appropriate RTP profile.  This
  implies that confidentiality of the media streams is achieved by
  encryption.  Encryption may be performed after compression so there
  is no conflict between the two operations.

  This payload format does not exhibit any significant non-uniformity
  in the receiver side computational complexity for packet processing,
  and thus is unlikely to pose a denial-of-service threat due to the
  receipt of pathological data.

5. Acknowledgments

This document was prepared using 2-Word-v2.0.template.dot.

6. Normative References

  [1]  SPIRIT IP-MR v2.5 User Guide, website http://spiritdsp.com
  [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.
  [3]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
       "RTP: A Transport Protocol for Real-Time Applications", STD 64,
       RFC 3550, July 2003.
  [4]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
       Description Protocol", RFC 4566, July 2006.

Author's Addresses

  Andrey Setsko
  SPIRIT DSP
  Russia 109004 B.Kommunisticheskaya st. 27

  Email: Setsko@spiritdsp.com

A.Setsko                  Expires September 03, 2008           [Page 12]

Internet-Draft    RTP Payload Format for SPIRIT IP-MR    November 2007

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, THE IETF TRUST 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 IETF Trust (2007).

  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.


A.Setsko                  Expires September 03, 2008           [Page 13]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/