VirtualBox

source: vbox/trunk/src/libs/libogg-1.3.5/doc/rfc5334.txt

Last change on this file was 96360, checked in by vboxsync, 22 months ago

libogg, libvorbis: export to OSE

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

© 2023 Oracle
ContactPrivacy policyTerms of Use