4 AVT Working Group L. Barbato
5 Internet-Draft Xiph.Org
6 Expires: January 22, 2007 July 21, 2006
9 draft-ietf-avt-rtp-theora-00
10 RTP Payload Format for Theora Encoded Video
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on January 22, 2007.
39 Copyright (C) The Internet Society (2006).
43 This document describes a RTP payload format for transporting Theora
44 encoded video. It details the RTP encapsulation mechanism for raw
45 Theora data and configuration headers necessary to configure the
48 Also included within the document are the necessary details for the
49 use of Theora with MIME and Session Description Protocol (SDP).
55 Barbato Expires January 22, 2007 [Page 1]
57 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
60 All references to RFC XXXX are to be replaced by references to the
61 RFC number of this memo, when published.
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
68 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4
69 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4
70 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
71 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
72 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7
73 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
74 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
75 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
76 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 10
77 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 11
78 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13
79 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
80 5. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 14
81 5.1. Example Fragmented Theora Packet . . . . . . . . . . . . . 15
82 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
84 6.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 19
85 6.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 20
86 6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 20
87 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
88 7.1. Stream Video . . . . . . . . . . . . . . . . . . . . . . . 21
89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
90 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
93 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
95 Intellectual Property and Copyright Statements . . . . . . . . . . 25
111 Barbato Expires January 22, 2007 [Page 2]
113 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
118 Theora is a general purpose, lossy video codec. It is based on the
119 VP3 video codec produced by On2 Technologies and has been donated to
120 the Xiph.org Foundation.
122 Theora I is a block-based lossy transform codec that utilizes an 8 x
123 8 Type-II Discrete Cosine Transform and block-based motion
124 compensation. This places it in the same class of codecs as MPEG-1,
125 MPEG-2, MPEG-4, and H.263. The details of how individual blocks are
126 organized and how DCT coefficients are stored in the bitstream differ
127 substantially from these codecs, however. Theora supports only intra
128 frames (I frames in MPEG) and inter frames (P frames in MPEG).
130 Theora provides none of its own framing, synchronization, or
131 protection against transmission errors. Instead, the codec expects
132 to receive a discrete sequence of data packets. Theora is a free-
133 form variable bit rate (VBR) codec, and these packets have no minimum
134 size, maximum size, or fixed/expected size. Theora packets are thus
135 intended to be used with a transport mechanism that provides free-
136 form framing, synchronization, positioning, and error correction in
137 accordance with these design assumptions, such as Ogg [1] or RTP/AVP
140 Theora I currently supports progressive video data of arbitrary
141 dimensions at a constant frame rate in one of several Y'CbCr color
142 spaces. Three different chroma subsampling formats are supported:
143 4:2:0, 4:2:2, and 4:4:4. The Theora I format does not support
144 interlaced material, variable frame rates, bit-depths larger than 8
145 bits per component, nor alternate color spaces such as RGB or
146 arbitrary multi-channel spaces. Black and white content can be
147 efficiently encoded, however, because the uniform chroma planes
148 compress well. For performance reason, arbitrary frame sizes will be
149 encoded rounding both dimensions to the upper multiple of 16. The
150 original width and height will be encoded in the header and the
151 decoder will use this information to clip the decoded frame to the
154 Theora is similar to the Vorbis audio [10] in that the decoder reads
155 the probability model for the entropy coder and all quantization
156 parameters from special "header" packets at the start of the
157 compressed data. It is therefore impossible to decode any video data
158 without having previously fetched the codec info and codec setup
159 headers, although Theora can begin to decode at an arbitrary intra-
160 frame packet so long as the codec has been initialized with the
167 Barbato Expires January 22, 2007 [Page 3]
169 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
176 document are to be interpreted as described in RFC 2119 [2].
181 For RTP based transportation of Theora encoded video the standard RTP
182 header is followed by a 4 octets payload header, then the payload
183 data. The payload headers are used to associate the Theora data with
184 its associated decoding codebooks as well as indicating if the
185 following packet contains fragmented Theora data and/or the number of
186 whole Theora data frames. The payload data contains the raw Theora
187 bitstream information.
189 For RTP based transport of Theora encoded video the standard RTP
190 header is followed by a 4 octets payload header, then the payload
195 The format of the RTP header is specified in [3] and shown in Figure
196 1. This payload format uses the fields of the header in a manner
197 consistent with that specification.
200 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
201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
202 |V=2|P|X| CC |M| PT | sequence number |
203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
206 | synchronization source (SSRC) identifier |
207 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
208 | contributing source (CSRC) identifiers |
210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
214 The RTP header begins with an octet of fields (V, P, X, and CC) to
215 support specialized RTP uses (see [3] and [4] for details). For
216 Theora RTP, the following values are used.
223 Barbato Expires January 22, 2007 [Page 4]
225 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
228 This field identifies the version of RTP. The version used by this
229 specification is two (2).
233 Padding MAY be used with this payload format according to section 5.1
238 The Extension bit is used in accordance with [3].
240 CSRC count (CC): 4 bits
242 The CSRC count is used in accordance with [3].
246 The Marker bit is used in accordance with [3].
248 Payload Type (PT): 7 bits
250 An RTP profile for a class of applications is expected to assign a
251 payload type for this format, or a dynamically allocated payload type
252 SHOULD be chosen which designates the payload as Theora.
254 Sequence number: 16 bits
256 The sequence number increments by one for each RTP data packet sent,
257 and may be used by the receiver to detect packet loss and to restore
258 packet sequence. This field is detailed further in [3].
262 A timestamp representing the presentation time of the first sample of
263 the first Theora packet in the RTP packet. The clock frequency MUST
266 SSRC/CSRC identifiers:
268 These two fields, 32 bits each with one SSRC field and a maximum of
269 16 CSRC fields, are as defined in [3].
273 The 4 octets following the RTP Header section represent the Payload
274 Header. This header is split into a number of bitfields detailing
275 the format of the following Payload Datagrams.
279 Barbato Expires January 22, 2007 [Page 5]
281 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
285 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
286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
287 | Configuration Ident | F |TDT|# pkts.|
288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
292 Figure 2: Payload Header
294 Configuration Ident: 24 bits
296 This 24 bit field is used to associate the Theora data to a decoding
297 Packed Configuration.
299 Fragment type (F): 2 bit
301 This field is set according to the following list
305 2 = Continuation Fragment
308 This field must be zero if the number of packets field is non-zero.
310 Theora Data Type (TDT): 2 bits
312 This field sets the packet payload type for the Theora data. There
313 are currently three Theora payload types currently used and one
314 reserved for future use.
316 0 = Raw Theora payload
317 1 = Theora Packed Configuration payload
318 2 = Legacy Theora Comment payload
321 The packets with a TDT of value 3 MUST be ignored
323 The last 4 bits represent the number of complete packets in this
324 payload. This provides a maximum number of 15 Theora packets in the
325 payload. If the packet contains fragmented data the number of
326 packets MUST be set to 0.
330 Each Theora payload section starts with a two octets length header
331 that is used to represent the size of the following data payload,
335 Barbato Expires January 22, 2007 [Page 6]
337 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
340 followed by the raw Theora packet data.
343 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
344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
345 | Payload Length | Theora Data ..
346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
348 Figure 3: Payload Data
350 The Theora codec uses relatively unstructured raw packets containing
351 binary integer fields of arbitrary width that often do not fall on an
352 octet boundary. When a Theora encoder produces packets, unused space
353 in the last byte of a packet is always zeroed during the encoding
354 process. Thus, should this unused space be read, it will return
357 For payloads which consist of multiple Theora packets the payload
358 data consists of the payload length field followed by the first
359 Theora packet's data, then the payload length followed by the second
360 Theora packet, and so on for each of the Theora packets in the
363 2.4. Example RTP Packet
365 Here is an example RTP packet containing two Theora packets.
370 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
371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
372 | 2 |0|0| 0 |0| PT | sequence number |
373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
376 | synchronisation source (SSRC) identifier |
377 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
378 | contributing source (CSRC) identifiers |
380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
382 Figure 4: Example RTP Packet
391 Barbato Expires January 22, 2007 [Page 7]
393 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
397 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
398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
399 | Configuration Ident | 0 | 0 | 2 pks |
400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
401 | Payload Length | ..
402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
405 .. data | Payload Length |
406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
410 Figure 5: Example Theora Payload Packet
412 The payload portion of the packet begins with the 24 bit
413 Configuration ident field followed by 8 bits describing the payload.
414 The Fragment type field is set to 0, indicating that this packet
415 contains whole Theora frame data. The Data type field is set to 0
416 (theora raw data). The number of whole Theora data packets is set to
419 Each of the payload blocks starts with the two octets length field
420 followed by the variable length Theora packet data.
423 3. Configuration Headers
425 To decode a Theora stream three configuration header packets are
426 needed. The first (Identification Header) indicates frame
427 dimensions, quality, blocks used and Theora encoder version. The
428 second (Comment Header) contains stream metadata and the third (Setup
429 Header) contains details of the dequantization and Huffman tables.
431 Since this information must be transmitted reliably, and as the RTP
432 stream may change certain configuration data mid-session, there are
433 different methods for delivering this configuration data to a client,
434 both in-band and out-of-band, which are detailed below. SDP delivery
435 is used to set up an initial state for the client application. The
436 changes may be due to different dequantization and Huffman tables as
437 well as different bitrates of the stream.
439 The delivery vectors in use are specified by an SDP attribute that
440 indicates the method and the optional URI where the Theora Packed
441 Configuration (Section 3.1.1) Packets could be fetched. Different
442 delivery methods MAY be advertised for the same session. The in-band
443 codebook delivery SHOULD be considered as baseline, out-of-band
447 Barbato Expires January 22, 2007 [Page 8]
449 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
452 delivery methods that don't use RTP will not be described in this
453 document. For non chained streams, the RECOMMENDED Configuration
454 delivery method is inline the Packed Configuration (Section 3.1.1) in
455 the SDP as explained in the IANA considerations (Section 6.1)
457 The 24 bit Ident field is used to map which Configuration will be
458 used to decode a packet. When the Ident field changes, it indicates
459 that a change in the stream has taken place. The client application
460 MUST have in advance the correct configuration and if the client
461 detects a change in the Ident value and does not have this
462 information it MUST NOT decode the raw data associated until it has
463 fetched the correct Configuration.
465 3.1. In-band Header Transmission
467 The Packed Configuration (Section 3.1.1) Payload is sent in-band with
468 the packet type bits set to match the payload type. Clients MUST be
469 capable of dealing with periodic re-transmission of the configuration
472 3.1.1. Packed Configuration
474 A Theora Packed Configuration is identified by a payload type field
475 of 1. Of the three headers, defined in the Theora I specification
476 [16], the identification and the setup will be packed together, while
477 the comment header will be completely suppressed. It is up to the
478 client to provide a minimal size comment header to the decoder if
479 required by the implementation.
503 Barbato Expires January 22, 2007 [Page 9]
505 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
509 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
510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
511 |V=2|P|X| CC |M| PT | xxxx |
512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
515 | synchronization source (SSRC) identifier |
516 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
517 | contributing source (CSRC) identifiers |
519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
521 | Configuration Ident | 0 | 1 | 1|
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523 | length | Identification ..
524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538 Figure 6: Packed Configuration Figure
540 The Ident field is set with the value that will be used by the Raw
541 Payload Packets to address this Configuration. The Fragment type is
542 set to 0 since the packet bears full Packed configuration, the number
543 of packet is set to 1. In practice, Packed Headers usually need to
544 be fragmented to fit the path MTU.
546 3.2. Out of Band Transmission
548 This section, as stated above, does not cover all the possible out-
549 of-band delivery methods since they rely on different protocols and
550 are linked to specific applications. The following packet definition
551 SHOULD be used in out-of-band delivery and MUST be used when
552 Configuration is inlined in the SDP.
559 Barbato Expires January 22, 2007 [Page 10]
561 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
564 3.2.1. Packed Headers
566 As mentioned above, the recommended delivery vector for Theora
567 configuration data is via a retrieval method that can be performed
568 using a reliable transport protocol. As the RTP headers are not
569 required for this method of delivery the structure of the
570 configuration data is slightly different. The packed header starts
571 with a 32 bit count field which details the number of packed headers
572 that are contained in the bundle. Next is the Packed header payload
575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
576 | Number of packed headers |
577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
585 Figure 7: Packed Headers Overview
587 Since the Configuration Ident and the Identification Header are fixed
588 length there is only a 16bit Length tag to define the length of the
592 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
593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
594 | Configuration Ident | ..
595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
596 .. Length | Identification Header ..
597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
598 .. Identification Header |
599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
605 Figure 8: Packed Headers Detail
607 The key difference from the in-band format is that there is no need
608 for the payload header octet.
615 Barbato Expires January 22, 2007 [Page 11]
617 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
620 3.2.1.1. Packed Headers IANA Considerations
622 The following IANA considerations MUST only be applied to the packed
625 MIME media type name: audio
627 MIME subtype: theora-config
637 Encoding considerations:
639 This media type contains binary data.
641 Security Considerations:
643 See Section 6 of RFC XXXX.
645 Interoperability considerations:
649 Published specification:
651 RFC XXXX [RFC Editor: please replace by the RFC number of this
652 memo, when published]
654 Applications which use this media type:
656 Theora encoded video, configuration data.
658 Additional information:
662 Person & email address to contact for further information:
664 Luca Barbato: <lu_zero@gentoo.org>
665 IETF Audio/Video Transport Working Group
671 Barbato Expires January 22, 2007 [Page 12]
673 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
676 Intended usage: COMMON
678 Restriction on usage:
680 This media type does not depend on the transport.
688 IETF AVT Working Group
690 3.3. Loss of Configuration Headers
692 Unlike the loss of raw Theora payload data, the loss of a
693 configuration header can lead to a situation where it will not be
694 possible to successfully decode the stream.
696 A loss of a Configuration Packet causes the stream decoder to halt
697 and SHOULD be reported to the client as well as a loss report sent
703 When the payload type is set to 2, the packet contains comment
704 metadata such as artist name, track title and so on. These metadata
705 messages are not intended to be fully descriptive but to offer basic
706 title information. Clients MAY choose to completely ignore them.
707 The details on the comments format can be found in the Theora
727 Barbato Expires January 22, 2007 [Page 13]
729 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
733 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
734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
735 |V=2|P|X| CC |M| PT | xxxx |
736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
739 | synchronization source (SSRC) identifier |
740 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
741 | contributing source (CSRC) identifiers |
743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
745 | Configuration Ident | 0 | 2 | 1|
746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
747 | length | Comment ..
748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
754 Figure 9: Comment Packet
756 The 2 byte length field is necessary since this Theora packet could
762 Each RTP packet contains either one complete Theora packet, one
763 Theora packet fragment, or an integer number of complete Theora
764 packets (up to a maximum of 15 packets, since the number of packets
765 is defined by a 4 bit value).
767 Any Theora data packet that is less than path MTU SHOULD be bundled
768 in the RTP packet with as many Theora packets as will fit, up to a
769 maximum of 15. Path MTU is detailed in [7] and [8].
771 A fragmented packet has a zero in the last four bits of the payload
772 header. The RTP packet containing the first fragment will set the
773 Fragment type to 1. Each RTP packet after the first will set the
774 Fragment type to 2 in the payload header. The RTP packet containing
775 the last fragment of the Theora packet will have the Fragment type
776 set to 3. If the fragmented Theora packet spans only two RTP
777 packets, the first will set the Fragment type field to 1 and the
778 second will set it to 2. To maintain the correct sequence for
779 fragmented packet reception the timestamp field of fragmented packets
783 Barbato Expires January 22, 2007 [Page 14]
785 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
788 MUST be the same as the first packet sent, with the sequence number
789 incremented as normal for the subsequent RTP packets.
791 5.1. Example Fragmented Theora Packet
793 Here is an example fragmented Theora packet split over three RTP
794 packets. Each packet contains the standard RTP headers as well as
795 the 4 octets Theora headers.
800 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
801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802 |V=2|P|X| CC |M| PT | 1000 |
803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
806 | synchronization source (SSRC) identifier |
807 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
808 | contributing source (CSRC) identifiers |
810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
812 | Configuration Ident | 1 | 0 | 0|
813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
814 | Payload Length | Theora data ..
815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
819 Figure 10: Example Fragmented Packet (Packet 1)
821 In this packet the initial sequence number is 1000 and the timestamp
822 is xxxxx. The Fragment type field is set to one, indicating it is
823 the start packet of a serie of fragments. The number of packets
824 field is set to 0, and as the payload is raw Theora data the Theora
825 payload type field is set to 0.
839 Barbato Expires January 22, 2007 [Page 15]
841 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
847 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
848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
849 |V=2|P|X| CC |M| PT | 1001 |
850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
853 | synchronization source (SSRC) identifier |
854 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
855 | contributing source (CSRC) identifiers |
857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
859 | Configuration Ident | 2 | 0 | 0|
860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
861 | Payload Length | ..
862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
866 Figure 11: Example Fragmented Packet (Packet 2)
868 The Fragment type field is set to 2 and the number of packets field
869 is set to 0. For large Theora fragments there can be several of
870 these type of payload packets. The maximum RTP packet size SHOULD be
871 no greater than the path MTU, including all RTP and payload headers.
872 The sequence number has been incremented by one but the timestamp
873 field remains the same as the initial packet.
895 Barbato Expires January 22, 2007 [Page 16]
897 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
903 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
904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
905 |V=2|P|X| CC |M| PT | 1002 |
906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
909 | synchronization source (SSRC) identifier |
910 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
911 | contributing source (CSRC) identifiers |
913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
915 | Configuration Ident | 3 | 0 | 0|
916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
917 | Payload Length | ..
918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
922 Figure 12: Example Fragmented Packet (Packet 3)
924 This is the last Theora fragment packet. The Fragment type filed is
925 set to 3 and the packet count remains set to 0. As in the previous
926 packets the timestamp remains set to the first packet in the sequence
927 and the sequence number has been incremented.
931 As there is no error correction within the Theora stream, packet loss
932 will result in a loss of signal. Packet loss is more of an issue for
933 fragmented Theora packets as the client will have to cope with the
934 handling of the Fragment type field. If we use the fragmented Theora
935 packet example above and the first packet is lost the client MUST
936 detect that the next packet has the packet count field set to 0 and
937 the Fragment type is set to 2 and MUST drop it. The next packet,
938 which is the final fragmented packet, MUST be dropped in the same
939 manner. Feedback reports on lost and dropped packets MUST be sent
940 back via RTCP.[note: reordering]
942 If a particular multicast session has a large number of participants
943 care must be taken to prevent an RTCP feedback implosion, [9], in the
944 event of packet loss from a large number of participants.
946 Loss of any of the Configuration fragment will result in the loss of
947 the full Configuration packet as detailed in the Loss of
951 Barbato Expires January 22, 2007 [Page 17]
953 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
956 Configuration Headers (Section 3.3) section.
959 6. IANA Considerations
961 MIME media type name: video
967 sampling: Determines the chroma subsampling format.
969 width: Determines the number of pixels per line. This is an
970 integer between 1 and 1048561 and MUST be in multiples of 16.
972 height: Determines the number of lines per frame encoded. This is
973 an integer between 1 and 1048561 and MUST be in multiples of
976 delivery-method: indicates the delivery methods in use, the
977 possible values are: inline, in_band, out_band/specific_name
978 Where "specific_name" is the name of the out of band delivery
981 configuration: the base16 [11] (hexadecimal) representation of the
982 Packed Headers (Section 3.2.1).
986 configuration-uri: the URI of the configuration headers in case of
987 out of band transmission. In the form of
988 "protocol://path/to/resource/". Depending on the specific
989 method the single ident packets could be retrived by their
990 number or aggregated in a single stream, aggregates MAY be
991 compressed using gzip [12] or bzip2 [14] and an sha1 [13]
992 checksum MAY be provided in the form of
993 "protocol://path/to/resource/aggregated.bz2!sha1hash"
995 Encoding considerations:
997 This media type is framed and contains binary data.
999 Security Considerations:
1001 See Section 6 of RFC XXXX.
1007 Barbato Expires January 22, 2007 [Page 18]
1009 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
1012 Interoperability considerations:
1016 Published specification:
1018 RFC XXXX [RFC Editor: please replace by the RFC number of this
1019 memo, when published]
1021 Ogg Theora I specification: Codec setup and packet decode.
1022 Available from the Xiph website, http://www.xiph.org
1024 Applications which use this media type:
1026 Audio streaming and conferencing tools
1028 Additional information:
1032 Person & email address to contact for further information:
1034 Luca Barbato: <lu_zero@gentoo.org>
1035 IETF Audio/Video Transport Working Group
1041 Restriction on usage:
1043 This media type depends on RTP framing, and hence is only defined
1044 for transfer via RTP [3]
1052 IETF AVT Working Group
1055 6.1. Mapping MIME Parameters into SDP
1057 The information carried in the MIME media type specification has a
1058 specific mapping to fields in the Session Description Protocol (SDP)
1059 [6], which is commonly used to describe RTP sessions. When SDP is
1063 Barbato Expires January 22, 2007 [Page 19]
1065 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
1068 used to specify sessions the mapping are as follows:
1070 o The MIME type ("video") goes in SDP "m=" as the media name.
1072 o The MIME subtype ("theora") goes in SDP "a=rtpmap" as the encoding
1075 o The clock rate in the "a=rtpmap" line MUST be 90000
1077 o The mandated parameters "delivery-method" and "configuration" MUST
1078 be included in the SDP "a=fmpt" attribute.
1080 o The optional parameter "configuration-uri", when present, MUST be
1081 included in the SDP "a=fmpt" attribute and MUST follow the
1082 delivery-method that applies.
1084 If the stream uses multiple decoder setup configurations and all of
1085 them are known in advance, the Configuration Packet for each file
1086 SHOULD be packaged together and passed to the client using the
1087 configuration attribute.
1089 The URI specified in the configuration-uri attribute MUST point to a
1090 location where all of the Configuration Packets needed for the life
1091 of the session reside.
1095 The following example shows a basic SDP for a single stream. The
1096 first configuration packet is inlined in the sdp, other
1097 configurations could be fetched at any time from the first provided
1098 uri using or all the known configuration could be downloaded using
1099 the second uri. The inline base16 [11] configuration string is
1100 omitted because of the lenght.
1103 a=rtpmap:98 theora/90000
1104 a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-
1105 method=inline; configuration=base16string1; delivery-
1106 method=out_band/rtsp; delivery-method=out_band/rtsp;
1107 configuration-uri=rtsp://path/to/resource/; delivery-
1108 method=out_band/http; configuration-uri=http://another/path/to/
1109 resource/aggregate.bz2!sha1hash;
1111 6.2. Usage with the SDP Offer/Answer Model
1113 The offer, as described in An Offer/Answer Model Session Description
1114 Protocol [5], may contain a large number of delivery methods per
1115 single fmtp attribute, the answerer MUST remove every delivery-method
1119 Barbato Expires January 22, 2007 [Page 20]
1121 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
1124 and configuration-uri not supported. All the parameters MUST not be
1125 altered on answer otherwise.
1130 The following examples are common usage patterns that MAY be applied
1131 in such situations, the main scope of this section is to explain
1132 better usage of the transmission vectors.
1136 This is one of the most common situation: one single server streaming
1137 content in multicast, the clients may start a session at random time.
1138 The content itself could be a mix of live stream, as the wj's voice
1139 or studio scenes, and stored streams, as the music she plays.
1141 In this situation we don't know in advance how many codebooks we will
1142 use. The clients can join anytime and users expect to start the
1143 fruition of the content in a short time.
1145 On join the client will receive the current Configuration necessary
1146 to decode the current streams inlined in the SDP so that the decoding
1147 will start immediately after.
1149 When the streamed content changes the new Configuration is sent in-
1150 band before the actual stream, and the Configuration that has to be
1151 sent inline in the SDP updated. Since the inline method is
1152 unreliable, an out of band fallback is provided.
1154 The client could choose to fetch the Configuration from the alternate
1155 source as soon it discovers a Configuration packet got lost inline or
1156 use selective retransmission [17], if the server supports the
1159 A serverside optimization would be to keep an hash list of the
1160 Configurations per session to avoid packing all of them and send the
1161 same Configuration with different Ident tags
1163 A clientside optimization would be to keep a tag list of the
1164 Configurations per session and don't process configuration packets
1168 8. Security Considerations
1170 RTP packets using this payload format are subject to the security
1171 considerations discussed in the RTP specification [3]. This implies
1175 Barbato Expires January 22, 2007 [Page 21]
1177 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
1180 that the confidentiality of the media stream is achieved by using
1181 encryption. Because the data compression used with this payload
1182 format is applied end-to-end, encryption may be performed on the
1183 compressed data. Where the size of a data block is set care MUST be
1184 taken to prevent buffer overflows in the client applications.
1189 This document is a continuation of draft-kerr-avt-theora-rtp-00.txt
1191 Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph
1192 Giles, Mike Smith, Phil Kerr, Timothy Terriberry, Stefan Ehmann,
1193 Alessandro Salvatori, Politecnico di Torino (LS)^3/IMG Group in
1194 particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini,
1195 Juan Carlos De Martin.
1200 10.1. Normative References
1202 [1] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
1205 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1208 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
1209 "RTP: A Transport Protocol for real-time applications",
1212 [4] Schulzrinne, H. and S. Casner, "RTP Profile for video and Video
1213 Conferences with Minimal Control.", RFC 3551.
1215 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
1216 Session Description Protocol (SDP)", RFC 3264.
1218 [6] Handley, M. and V. Jacobson, "SDP: Session Description
1219 Protocol", RFC 2327.
1221 [7] Mogul et al., J., "Path MTU Discovery", RFC 1063.
1223 [8] McCann et al., J., "Path MTU Discovery for IP version 6",
1226 [9] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
1227 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
1231 Barbato Expires January 22, 2007 [Page 22]
1233 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
1236 Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
1239 [10] Barbato, L., "RTP Payload Format for Vorbis Encoded Audio -
1240 draft-ietf-avt-vorbis-rtp-00", Internet Draft (Work in
1243 [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
1246 [12] Deutsch, P., "GZIP file format specification version 4.3",
1249 [13] National Institute of Standards and Technology, "Secure Hash
1250 Standard", May 1993.
1252 [14] Seward, J., "libbz2 and bzip2".
1254 10.2. Informative References
1256 [15] "libTheora: Available from the Xiph website,
1257 http://www.xiph.org".
1259 [16] "Theora I specification: Codec setup and packet decode.
1260 http://www.xiph.org/theora/doc/Theora_I_spec.pdf".
1262 [17] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
1263 Extended Reports (RTCP XR)", RFC 3611, November 2003.
1265 [18] "ITU-T Recommendation V.42, 1994, Rev. 1. Error-correcting
1266 Procedures for DCEs Using Asynchronous-to-Synchronous
1267 Conversion. International Telecommunications Union. Available
1268 from the ITU website, http://www.itu.int".
1270 [19] "ISO 3309, October 1984, 3rd Edition. Information Processing
1271 Systems--Data Communication High-Level Data Link Control
1272 Procedure--Frame Structure. International Organization for
1287 Barbato Expires January 22, 2007 [Page 23]
1289 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
1297 Email: lu_zero@gentoo.org
1298 URI: http://www.xiph.org/
1343 Barbato Expires January 22, 2007 [Page 24]
1345 Internet-Draft draft-ietf-avt-rtp-theora-00 July 2006
1348 Intellectual Property Statement
1350 The IETF takes no position regarding the validity or scope of any
1351 Intellectual Property Rights or other rights that might be claimed to
1352 pertain to the implementation or use of the technology described in
1353 this document or the extent to which any license under such rights
1354 might or might not be available; nor does it represent that it has
1355 made any independent effort to identify any such rights. Information
1356 on the procedures with respect to rights in RFC documents can be
1357 found in BCP 78 and BCP 79.
1359 Copies of IPR disclosures made to the IETF Secretariat and any
1360 assurances of licenses to be made available, or the result of an
1361 attempt made to obtain a general license or permission for the use of
1362 such proprietary rights by implementers or users of this
1363 specification can be obtained from the IETF on-line IPR repository at
1364 http://www.ietf.org/ipr.
1366 The IETF invites any interested party to bring to its attention any
1367 copyrights, patents or patent applications, or other proprietary
1368 rights that may cover technology that may be required to implement
1369 this standard. Please address the information to the IETF at
1373 Disclaimer of Validity
1375 This document and the information contained herein are provided on an
1376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1378 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1379 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1380 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1386 Copyright (C) The Internet Society (2006). This document is subject
1387 to the rights, licenses and restrictions contained in BCP 78, and
1388 except as set forth therein, the authors retain all their rights.
1393 Funding for the RFC Editor function is currently provided by the
1399 Barbato Expires January 22, 2007 [Page 25]