1
2
3
4
5
6
7Network Working Group                                       I. Goncalves
8Request for Comments: 5334                                   S. Pfeiffer
9Obsoletes: 3534                                            C. Montgomery
10Category: Standards Track                                           Xiph
11                                                          September 2008
12
13
14                            Ogg Media Types
15
16Status of This Memo
17
18   This document specifies an Internet standards track protocol for the
19   Internet community, and requests discussion and suggestions for
20   improvements.  Please refer to the current edition of the "Internet
21   Official Protocol Standards" (STD 1) for the standardization state
22   and status of this protocol.  Distribution of this memo is unlimited.
23
24Abstract
25
26   This document describes the registration of media types for the Ogg
27   container format and conformance requirements for implementations of
28   these types.  This document obsoletes RFC 3534.
29
30Table of Contents
31
32   1.     Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
33   2.     Changes Since RFC 3534  . . . . . . . . . . . . . . . . . .  2
34   3.     Conformance and Document Conventions  . . . . . . . . . . .  3
35   4.     Deployed Media Types and Compatibility  . . . . . . . . . .  3
36   5.     Relation between the Media Types  . . . . . . . . . . . . .  5
37   6.     Encoding Considerations . . . . . . . . . . . . . . . . . .  5
38   7.     Security Considerations . . . . . . . . . . . . . . . . . .  6
39   8.     Interoperability Considerations . . . . . . . . . . . . . .  7
40   9.     IANA Considerations . . . . . . . . . . . . . . . . . . . .  7
41   10.    Ogg Media Types . . . . . . . . . . . . . . . . . . . . . .  7
42   10.1.  application/ogg . . . . . . . . . . . . . . . . . . . . . .  7
43   10.2.  video/ogg . . . . . . . . . . . . . . . . . . . . . . . . .  8
44   10.3.  audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . .  9
45   11.    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 10
46   12.    Copying Conditions  . . . . . . . . . . . . . . . . . . . . 10
47   13.    References  . . . . . . . . . . . . . . . . . . . . . . . . 11
48   13.1.  Normative References  . . . . . . . . . . . . . . . . . . . 11
49   13.2.  Informative References  . . . . . . . . . . . . . . . . . . 11
50
51
52
53
54
55
56
57
58Goncalves, et al.           Standards Track                     [Page 1]
59
60RFC 5334                    Ogg Media Types               September 2008
61
62
631.  Introduction
64
65   This document describes media types for Ogg, a data encapsulation
66   format defined by the Xiph.Org Foundation for public use.  Refer to
67   "Introduction" in [RFC3533] and "Overview" in [Ogg] for background
68   information on this container format.
69
70   Binary data contained in Ogg, such as Vorbis and Theora, has
71   historically been interchanged using the application/ogg media type
72   as defined by [RFC3534].  This document obsoletes [RFC3534] and
73   defines three media types for different types of content in Ogg to
74   reflect this usage in the IANA media type registry, to foster
75   interoperability by defining underspecified aspects, and to provide
76   general security considerations.
77
78   The Ogg container format is known to contain [Theora] or [Dirac]
79   video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC]
80   audio, and [CMML] timed text/metadata.  As Ogg encapsulates binary
81   data, it is possible to include any other type of video, audio,
82   image, text, or, generally speaking, any time-continuously sampled
83   data.
84
85   While raw packets from these data sources may be used directly by
86   transport mechanisms that provide their own framing and packet-
87   separation mechanisms (such as UDP datagrams or RTP), Ogg is a
88   solution for stream based storage (such as files) and transport (such
89   as TCP streams or pipes).  The media types defined in this document
90   are needed to correctly identify such content when it is served over
91   HTTP, included in multi-part documents, or used in other places where
92   media types [RFC2045] are used.
93
942.  Changes Since RFC 3534
95
96   o  The type "application/ogg" is redefined.
97
98   o  The types "video/ogg" and "audio/ogg" are defined.
99
100   o  New file extensions are defined.
101
102   o  New Macintosh file type codes are defined.
103
104   o  The codecs parameter is defined for optional use.
105
106   o  The Ogg Skeleton extension becomes a recommended addition for
107      content served under the new types.
108
109
110
111
112
113
114Goncalves, et al.           Standards Track                     [Page 2]
115
116RFC 5334                    Ogg Media Types               September 2008
117
118
1193.  Conformance and Document Conventions
120
121   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
123   document are to be interpreted as described in BCP 14, [RFC2119] and
124   indicate requirement levels for compliant implementations.
125   Requirements apply to all implementations unless otherwise stated.
126
127   An implementation is a software module that supports one of the media
128   types defined in this document.  Software modules may support
129   multiple media types, but conformance is considered individually for
130   each type.
131
132   Implementations that fail to satisfy one or more "MUST" requirements
133   are considered non-compliant.  Implementations that satisfy all
134   "MUST" requirements, but fail to satisfy one or more "SHOULD"
135   requirements, are said to be "conditionally compliant".  All other
136   implementations are "unconditionally compliant".
137
1384.  Deployed Media Types and Compatibility
139
140   The application/ogg media type has been used in an ad hoc fashion to
141   label and exchange multimedia content in Ogg containers.
142
143   Use of the "application" top-level type for this kind of content is
144   known to be problematic, in particular since it obfuscates video and
145   audio content.  This document thus defines the media types,
146
147   o  video/ogg
148
149   o  audio/ogg
150
151   which are intended for common use and SHOULD be used when dealing
152   with video or audio content, respectively.  This document also
153   obsoletes the [RFC3534] definition of application/ogg and marks it
154   for complex data (e.g., multitrack visual, audio, textual, and other
155   time-continuously sampled data), which is not clearly video or audio
156   data and thus not suited for either the video/ogg or audio/ogg types.
157   Refer to the following section for more details.
158
159   An Ogg bitstream generally consists of one or more logical bitstreams
160   that each consist of a series of header and data pages packetising
161   time-continuous binary data [RFC3533].  The content types of the
162   logical bitstreams may be identified without decoding the header
163   pages of the logical bitstreams through use of a [Skeleton]
164   bitstream.  Using Ogg Skeleton is REQUIRED for content served under
165
166
167
168
169
170Goncalves, et al.           Standards Track                     [Page 3]
171
172RFC 5334                    Ogg Media Types               September 2008
173
174
175   the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
176   as Skeleton contains identifiers to describe the different
177   encapsulated data.
178
179   Furthermore, it is RECOMMENDED that implementations that identify a
180   logical bitstream that they cannot decode SHOULD ignore it, while
181   continuing to decode the ones they can.  Such precaution ensures
182   backward and forward compatibility with existing and future data.
183
184   These media types can optionally use the "codecs" parameter described
185   in [RFC4281].  Codecs encapsulated in Ogg require a text identifier
186   at the beginning of the first header page, hence a machine-readable
187   method to identify the encapsulated codecs would be through this
188   header.  The following table illustrates how those header values map
189   into strings that are used in the "codecs" parameter when dealing
190   with Ogg media types.
191
192        Codec Identifier             | Codecs Parameter
193       -----------------------------------------------------------
194        char[5]: 'BBCD\0'            | dirac
195        char[5]: '\177FLAC'          | flac
196        char[7]: '\x80theora'        | theora
197        char[7]: '\x01vorbis'        | vorbis
198        char[8]: 'CELT    '          | celt
199        char[8]: 'CMML\0\0\0\0'      | cmml
200        char[8]: '\213JNG\r\n\032\n' | jng
201        char[8]: '\x80kate\0\0\0'    | kate
202        char[8]: 'OggMIDI\0'         | midi
203        char[8]: '\212MNG\r\n\032\n' | mng
204        char[8]: 'PCM     '          | pcm
205        char[8]: '\211PNG\r\n\032\n' | png
206        char[8]: 'Speex   '          | speex
207        char[8]: 'YUV4MPEG'          | yuv4mpeg
208
209   An up-to-date version of this table is kept at Xiph.org (see
210   [Codecs]).
211
212   Possible examples include:
213
214   o  application/ogg; codecs="theora, cmml, ecmascript"
215
216   o  video/ogg; codecs="theora, vorbis"
217
218   o  audio/ogg; codecs=speex
219
220
221
222
223
224
225
226Goncalves, et al.           Standards Track                     [Page 4]
227
228RFC 5334                    Ogg Media Types               September 2008
229
230
2315.  Relation between the Media Types
232
233   As stated in the previous section, this document describes three
234   media types that are targeted at different data encapsulated in Ogg.
235   Since Ogg is capable of encapsulating any kind of data, the multiple
236   usage scenarios have revealed interoperability issues between
237   implementations when dealing with content served solely under the
238   application/ogg type.
239
240   While this document does redefine the earlier definition of
241   application/ogg, this media type will continue to embrace the widest
242   net possible of content with the video/ogg and audio/ogg types being
243   smaller subsets of it.  However, the video/ogg and audio/ogg types
244   take precedence in a subset of the usages, specifically when serving
245   multimedia content that is not complex enough to warrant the use of
246   application/ogg.  Following this line of thought, the audio/ogg type
247   is an even smaller subset within video/ogg, as it is not intended to
248   refer to visual content.
249
250   As such, the application/ogg type is the recommended choice to serve
251   content aimed at scientific and other applications that require
252   various multiplexed signals or streams of continuous data, with or
253   without scriptable control of content.  For bitstreams containing
254   visual, timed text, and any other type of material that requires a
255   visual interface, but that is not complex enough to warrant serving
256   under application/ogg, the video/ogg type is recommended.  In
257   situations where the Ogg bitstream predominantly contains audio data
258   (lyrics, metadata, or cover art notwithstanding), it is recommended
259   to use the audio/ogg type.
260
2616.  Encoding Considerations
262
263   Binary: The content consists of an unrestricted sequence of octets.
264
265   Note:
266
267   o  Ogg encapsulated content is binary data and should be transmitted
268      in a suitable encoding without CR/LF conversion, 7-bit stripping,
269      etc.; base64 [RFC4648] is generally preferred for binary-to-text
270      encoding.
271
272   o  Media types described in this document are used for stream based
273      storage (such as files) and transport (such as TCP streams or
274      pipes); separate types are used to identify codecs such as in
275      real-time applications for the RTP payload formats of Theora
276      [ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well
277      as for identification of encapsulated data within Ogg through
278      Skeleton.
279
280
281
282Goncalves, et al.           Standards Track                     [Page 5]
283
284RFC 5334                    Ogg Media Types               September 2008
285
286
2877.  Security Considerations
288
289   Refer to [RFC3552] for a discussion of terminology used in this
290   section.
291
292   The Ogg encapsulation format is a container and only a carrier of
293   content (such as audio, video, and displayable text data) with a very
294   rigid definition.  This format in itself is not more vulnerable than
295   any other content framing mechanism.
296
297   Ogg does not provide for any generic encryption or signing of itself
298   or its contained bitstreams.  However, it encapsulates any kind of
299   binary content and is thus able to contain encrypted and signed
300   content data.  It is also possible to add an external security
301   mechanism that encrypts or signs an Ogg bitstream and thus provides
302   content confidentiality and authenticity.
303
304   As Ogg encapsulates binary data, it is possible to include executable
305   content in an Ogg bitstream.  Implementations SHOULD NOT execute such
306   content without prior validation of its origin by the end-user.
307
308   Issues may arise on applications that use Ogg for streaming or file
309   transfer in a networking scenario.  In such cases, implementations
310   decoding Ogg and its encapsulated bitstreams have to ensure correct
311   handling of manipulated bitstreams, of buffer overflows, and similar
312   issues.
313
314   It is also possible to author malicious Ogg bitstreams, which attempt
315   to call for an excessively large picture size, high sampling-rate
316   audio, etc.  Implementations SHOULD protect themselves against this
317   kind of attack.
318
319   Ogg has an extensible structure, so that it is theoretically possible
320   that metadata fields or media formats might be defined in the future
321   which might be used to induce particular actions on the part of the
322   recipient, thus presenting additional security risks.  However, this
323   type of capability is currently not supported in the referenced
324   specification.
325
326   Implementations may fail to implement a specific security model or
327   other means to prevent possibly dangerous operations.  Such failure
328   might possibly be exploited to gain unauthorized access to a system
329   or sensitive information; such failure constitutes an unknown factor
330   and is thus considered out of the scope of this document.
331
332
333
334
335
336
337
338Goncalves, et al.           Standards Track                     [Page 6]
339
340RFC 5334                    Ogg Media Types               September 2008
341
342
3438.  Interoperability Considerations
344
345   The Ogg container format is device-, platform-, and vendor-neutral
346   and has proved to be widely implementable across different computing
347   platforms through a wide range of encoders and decoders.  A broadly
348   portable reference implementation [libogg] is available under the
349   revised (3-clause) BSD license, which is a Free Software license.
350
351   The Xiph.Org Foundation has defined the specification,
352   interoperability, and conformance and conducts regular
353   interoperability testing.
354
355   The use of the Ogg Skeleton extension has been confirmed to not cause
356   interoperability issues with existing implementations.  Third parties
357   are, however, welcome to conduct their own testing.
358
3599.  IANA Considerations
360
361   In accordance with the procedures set forth in [RFC4288], this
362   document registers two new media types and redefines the existing
363   application/ogg as defined in the following section.
364
36510.  Ogg Media Types
366
36710.1.  application/ogg
368
369   Type name: application
370
371   Subtype name: ogg
372
373   Required parameters: none
374
375   Optional parameters: codecs, whose syntax is defined in RFC 4281.
376   See section 4 of RFC 5334 for a list of allowed values.
377
378   Encoding considerations: See section 6 of RFC 5334.
379
380   Security considerations: See section 7 of RFC 5334.
381
382   Interoperability considerations: None, as noted in section 8 of RFC
383   5334.
384
385   Published specification: RFC 3533
386
387   Applications which use this media type: Scientific and otherwise that
388   require various multiplexed signals or streams of data, with or
389   without scriptable control of content.
390
391
392
393
394Goncalves, et al.           Standards Track                     [Page 7]
395
396RFC 5334                    Ogg Media Types               September 2008
397
398
399   Additional information:
400
401   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
402   correspond to the string "OggS".
403
404   File extension(s): .ogx
405
406      RFC 3534 defined the file extension .ogg for application/ogg,
407      which RFC 5334 obsoletes in favor of .ogx due to concerns where,
408      historically, some implementations expect .ogg files to be solely
409      Vorbis-encoded audio.
410
411   Macintosh File Type Code(s): OggX
412
413   Person & Email address to contact for further information: See
414   "Authors' Addresses" section.
415
416   Intended usage: COMMON
417
418   Restrictions on usage: The type application/ogg SHOULD only be used
419   in situations where it is not appropriate to serve data under the
420   video/ogg or audio/ogg types.  Data served under the application/ogg
421   type SHOULD use the .ogx file extension and MUST contain an Ogg
422   Skeleton logical bitstream to identify all other contained logical
423   bitstreams.
424
425   Author: See "Authors' Addresses" section.
426
427   Change controller: The Xiph.Org Foundation.
428
42910.2.  video/ogg
430
431   Type name: video
432
433   Subtype name: ogg
434
435   Required parameters: none
436
437   Optional parameters: codecs, whose syntax is defined in RFC 4281.
438   See section 4 of RFC 5334 for a list of allowed values.
439
440   Encoding considerations: See section 6 of RFC 5334.
441
442   Security considerations: See section 7 of RFC 5334.
443
444   Interoperability considerations: None, as noted in section 8 of RFC
445   5334.
446
447
448
449
450Goncalves, et al.           Standards Track                     [Page 8]
451
452RFC 5334                    Ogg Media Types               September 2008
453
454
455   Published specification: RFC 3533
456
457   Applications which use this media type: Multimedia applications,
458   including embedded, streaming, and conferencing tools.
459
460   Additional information:
461
462   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
463   correspond to the string "OggS".
464
465   File extension(s): .ogv
466
467   Macintosh File Type Code(s): OggV
468
469   Person & Email address to contact for further information: See
470   "Authors' Addresses" section.
471
472   Intended usage: COMMON
473
474   Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg
475   bitstreams containing visual, audio, timed text, or any other type of
476   material that requires a visual interface.  It is intended for
477   content not complex enough to warrant serving under "application/
478   ogg"; for example, a combination of Theora video, Vorbis audio,
479   Skeleton metadata, and CMML captioning.  Data served under the type
480   "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream.
481   Implementations interacting with the type "video/ogg" SHOULD support
482   multiplexed bitstreams.
483
484   Author: See "Authors' Addresses" section.
485
486   Change controller: The Xiph.Org Foundation.
487
48810.3.  audio/ogg
489
490   Type name: audio
491
492   Subtype name: ogg
493
494   Required parameters: none
495
496   Optional parameters: codecs, whose syntax is defined in RFC 4281.
497   See section 4 of RFC 5334 for a list of allowed values.
498
499   Encoding considerations: See section 6 of RFC 5334.
500
501   Security considerations: See section 7 of RFC 5334.
502
503
504
505
506Goncalves, et al.           Standards Track                     [Page 9]
507
508RFC 5334                    Ogg Media Types               September 2008
509
510
511   Interoperability considerations: None, as noted in section 8 of RFC
512   5334.
513
514   Published specification: RFC 3533
515
516   Applications which use this media type: Multimedia applications,
517   including embedded, streaming, and conferencing tools.
518
519   Additional information:
520
521   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
522   correspond to the string "OggS".
523
524   File extension(s): .oga, .ogg, .spx
525
526   Macintosh File Type Code(s): OggA
527
528   Person & Email address to contact for further information: See
529   "Authors' Addresses" section.
530
531   Intended usage: COMMON
532
533   Restrictions on usage: The type "audio/ogg" SHOULD be used when the
534   Ogg bitstream predominantly contains audio data.  Content served
535   under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
536   bitstream when using the default .oga file extension.  The .ogg and
537   .spx file extensions indicate a specialization that requires no
538   Skeleton due to backward compatibility concerns with existing
539   implementations.  In particular, .ogg is used for Ogg files that
540   contain only a Vorbis bitstream, while .spx is used for Ogg files
541   that contain only a Speex bitstream.
542
543   Author: See "Authors' Addresses" section.
544
545   Change controller: The Xiph.Org Foundation.
546
54711.  Acknowledgements
548
549   The authors gratefully acknowledge the contributions of Magnus
550   Westerlund, Alfred Hoenes, and Peter Saint-Andre.
551
55212.  Copying Conditions
553
554   The authors agree to grant third parties the irrevocable right to
555   copy, use and distribute the work, with or without modification, in
556   any medium, without royalty, provided that, unless separate
557   permission is granted, redistributed modified works do not contain
558   misleading author, version, name of work, or endorsement information.
559
560
561
562Goncalves, et al.           Standards Track                    [Page 10]
563
564RFC 5334                    Ogg Media Types               September 2008
565
566
56713.  References
568
56913.1.  Normative References
570
571   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
572               Extensions (MIME) Part One: Format of Internet Message
573               Bodies", RFC 2045, November 1996.
574
575   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
576               Requirement Levels", BCP 14, RFC 2119, March 1997.
577
578   [RFC3533]   Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
579               RFC 3533, May 2003.
580
581   [RFC4281]   Gellens, R., Singer, D., and P. Frojdh, "The Codecs
582               Parameter for "Bucket" Media Types", RFC 4281,
583               November 2005.
584
585   [RFC4288]   Freed, N. and J. Klensin, "Media Type Specifications and
586               Registration Procedures", BCP 13, RFC 4288,
587               December 2005.
588
58913.2.  Informative References
590
591   [CMML]      Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
592               Media Markup Language (CMML)", Work in Progress,
593               March 2006.
594
595   [Codecs]    Pfeiffer, S. and I. Goncalves, "Specification of MIME
596               types and respective codecs parameter", July 2008,
597               <http://wiki.xiph.org/index.php/MIMETypesCodecs>.
598
599   [Dirac]     Dirac Group, "Dirac Specification",
600               <http://diracvideo.org/specifications/>.
601
602   [FLAC]      Coalson, J., "The FLAC Format",
603               <http://flac.sourceforge.net/format.html>.
604
605   [libogg]    Xiph.Org Foundation, "The libogg API", June 2000,
606               <http://xiph.org/ogg/doc/libogg>.
607
608   [Ogg]       Xiph.Org Foundation, "Ogg bitstream documentation: Ogg
609               logical and physical bitstream overview, Ogg logical
610               bitstream framing, Ogg multi-stream multiplexing",
611               <http://xiph.org/ogg/doc>.
612
613   [RFC3534]   Walleij, L., "The application/ogg Media Type", RFC 3534,
614               May 2003.
615
616
617
618Goncalves, et al.           Standards Track                    [Page 11]
619
620RFC 5334                    Ogg Media Types               September 2008
621
622
623   [RFC3552]   Rescorla, E. and B. Korver, "Guidelines for Writing RFC
624               Text on Security Considerations", BCP 72, RFC 3552,
625               July 2003.
626
627   [RFC4648]   Josefsson, S., "The Base16, Base32, and Base64 Data
628               Encodings", RFC 4648, October 2006.
629
630   [RFC5215]   Barbato, L., "RTP Payload Format for Vorbis Encoded
631               Audio", RFC 5215, August 2008.
632
633   [Skeleton]  Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
634               Bitstream", November 2007,
635               <http://xiph.org/ogg/doc/skeleton.html>.
636
637   [Speex]     Valin, J., "The Speex Codec Manual", February 2002,
638               <http://speex.org/docs/manual/speex-manual>.
639
640   [SpRTP]     Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
641               "RTP Payload Format for the Speex Codec", Work
642               in Progress, February 2008.
643
644   [Theora]    Xiph.Org Foundation, "Theora Specification",
645               October 2007, <http://theora.org/doc/Theora.pdf>.
646
647   [ThRTP]     Barbato, L., "RTP Payload Format for Theora Encoded
648               Video", Work in Progress, June 2006.
649
650   [Vorbis]    Xiph.Org Foundation, "Vorbis I Specification", July 2004,
651               <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674Goncalves, et al.           Standards Track                    [Page 12]
675
676RFC 5334                    Ogg Media Types               September 2008
677
678
679Authors' Addresses
680
681   Ivo Emanuel Goncalves
682   Xiph.Org Foundation
683   21 College Hill Road
684   Somerville, MA  02144
685   US
686
687   EMail: justivo@gmail.com
688   URI:   xmpp:justivo@gmail.com
689
690
691   Silvia Pfeiffer
692   Xiph.Org Foundation
693
694   EMail: silvia@annodex.net
695   URI:   http://annodex.net/
696
697
698   Christopher Montgomery
699   Xiph.Org Foundation
700
701   EMail: monty@xiph.org
702   URI:   http://xiph.org
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730Goncalves, et al.           Standards Track                    [Page 13]
731
732RFC 5334                    Ogg Media Types               September 2008
733
734
735Full Copyright Statement
736
737   Copyright (C) The IETF Trust (2008).
738
739   This document is subject to the rights, licenses and restrictions
740   contained in BCP 78, and except as set forth therein, the authors
741   retain all their rights.
742
743   This document and the information contained herein are provided on an
744   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
745   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
746   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
747   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
748   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
749   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
750
751Intellectual Property
752
753   The IETF takes no position regarding the validity or scope of any
754   Intellectual Property Rights or other rights that might be claimed to
755   pertain to the implementation or use of the technology described in
756   this document or the extent to which any license under such rights
757   might or might not be available; nor does it represent that it has
758   made any independent effort to identify any such rights.  Information
759   on the procedures with respect to rights in RFC documents can be
760   found in BCP 78 and BCP 79.
761
762   Copies of IPR disclosures made to the IETF Secretariat and any
763   assurances of licenses to be made available, or the result of an
764   attempt made to obtain a general license or permission for the use of
765   such proprietary rights by implementers or users of this
766   specification can be obtained from the IETF on-line IPR repository at
767   http://www.ietf.org/ipr.
768
769   The IETF invites any interested party to bring to its attention any
770   copyrights, patents or patent applications, or other proprietary
771   rights that may cover technology that may be required to implement
772   this standard.  Please address the information to the IETF at
773   ietf-ipr@ietf.org.
774
775
776
777
778
779
780
781
782
783
784
785
786Goncalves, et al.           Standards Track                    [Page 14]
787
788