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