1 2 3 4 5 6 7 Network Working Group I. Goncalves 8 Request for Comments: 5334 S. Pfeiffer 9 Obsoletes: 3534 C. Montgomery 10 Category: Standards Track Xiph 11 September 2008 12 13 14 Ogg Media Types 15 16 Status 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 24 Abstract 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 30 Table 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 58 Goncalves, et al. Standards Track [Page 1] 59 61 RFC 5334 Ogg Media Types September 2008 62 63 64 1. 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 95 2. 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 115 Goncalves, et al. Standards Track [Page 2] 116 118 RFC 5334 Ogg Media Types September 2008 119 120 121 3. 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 140 4. 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 172 Goncalves, et al. Standards Track [Page 3] 173 175 RFC 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 229 Goncalves, et al. Standards Track [Page 4] 230 232 RFC 5334 Ogg Media Types September 2008 233 234 235 5. 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 265 6. 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 286 Goncalves, et al. Standards Track [Page 5] 287 289 RFC 5334 Ogg Media Types September 2008 290 291 292 7. 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 343 Goncalves, et al. Standards Track [Page 6] 344 346 RFC 5334 Ogg Media Types September 2008 347 348 349 8. 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 365 9. 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 371 10. Ogg Media Types 372 373 10.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 400 Goncalves, et al. Standards Track [Page 7] 401 403 RFC 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 436 10.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 457 Goncalves, et al. Standards Track [Page 8] 458 460 RFC 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 496 10.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 514 Goncalves, et al. Standards Track [Page 9] 515 517 RFC 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 556 11. Acknowledgements 557 558 The authors gratefully acknowledge the contributions of Magnus 559 Westerlund, Alfred Hoenes, and Peter Saint-Andre. 560 561 12. 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 571 Goncalves, et al. Standards Track [Page 10] 572 574 RFC 5334 Ogg Media Types September 2008 575 576 577 13. References 578 579 13.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 599 13.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 628 Goncalves, et al. Standards Track [Page 11] 629 631 RFC 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 685 Goncalves, et al. Standards Track [Page 12] 686 688 RFC 5334 Ogg Media Types September 2008 689 690 691 Authors' 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 (a] gmail.com 700 URI: xmpp:justivo (a] gmail.com 701 702 703 Silvia Pfeiffer 704 Xiph.Org Foundation 705 706 EMail: silvia (a] annodex.net 707 URI: http://annodex.net/ 708 709 710 Christopher Montgomery 711 Xiph.Org Foundation 712 713 EMail: monty (a] 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 742 Goncalves, et al. Standards Track [Page 13] 743 745 RFC 5334 Ogg Media Types September 2008 746 747 748 Full 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 764 Intellectual 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 (a] ietf.org. 787 788 789 790 791 792 793 794 795 796 797 798 799 Goncalves, et al. Standards Track [Page 14] 800 802
