idnits 2.17.1 draft-goncalves-rfc3534bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 617. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3534, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2, 2008) is 5806 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '5' on line 173 -- Looks like a reference, but probably isn't: '7' on line 175 -- Looks like a reference, but probably isn't: '8' on line 183 -- Looks like a reference, but probably isn't: '9' on line 185 ** Downref: Normative reference to an Informational RFC: RFC 3533 ** Obsolete normative reference: RFC 4281 (Obsoleted by RFC 6381) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 3534 (Obsoleted by RFC 5334) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Goncalves 3 Internet-Draft S. Pfeiffer 4 Obsoletes: 3534 (if approved) C. Montgomery 5 Intended status: Standards Track Xiph 6 Expires: December 4, 2008 June 2, 2008 8 Ogg Media Types 9 draft-goncalves-rfc3534bis-07 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 4, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes the registration of media types for the Ogg 43 container format and conformance requirements for implementations of 44 these types. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Changes Since RFC 3534 . . . . . . . . . . . . . . . . . . 3 50 3. Conformance and Document Conventions . . . . . . . . . . . 3 51 4. Deployed Media Types and Compatibility . . . . . . . . . . 4 52 5. Relation Between the Media Types . . . . . . . . . . . . . 5 53 6. Encoding Considerations . . . . . . . . . . . . . . . . . . 6 54 7. Security Considerations . . . . . . . . . . . . . . . . . . 6 55 8. Interoperability Considerations . . . . . . . . . . . . . . 7 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 57 10. Ogg Media Types . . . . . . . . . . . . . . . . . . . . . . 8 58 10.1. application/ogg . . . . . . . . . . . . . . . . . . . . . . 8 59 10.2. video/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 10.3. audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 11 62 12. Copying Conditions . . . . . . . . . . . . . . . . . . . . 11 63 13. References . . . . . . . . . . . . . . . . . . . . . . . . 11 64 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 65 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 This document describes media types for Ogg, a data encapsulation 70 format defined by the Xiph.Org Foundation for public use. Refer to 71 "Introduction" in [RFC3533] and "Overview" in [Ogg] for background 72 information on this container format. 74 Binary data contained in Ogg, such as Vorbis and Theora, has 75 historically been interchanged using the application/ogg media type 76 as defined by [RFC3534]. This document obsoletes [RFC3534] and 77 defines three media types for different types of content in Ogg to 78 reflect this usage in the IANA media type registry, to foster 79 interoperability by defining underspecified aspects, and to provide 80 general security considerations. 82 The Ogg container format is known to contain [Theora] or [Dirac] 83 video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC] 84 audio, and [CMML] timed text/metadata. As Ogg encapsulates binary 85 data, it is possible to include any other type of video, audio, 86 image, text or, generally speaking, any time-continuously sampled 87 data. 89 While raw packets from these data sources may be used directly by 90 transport mechanisms that provide their own framing and packet- 91 separation mechanisms (such as UDP datagrams or RTP), Ogg is a 92 solution for stream based storage (such as files) and transport (such 93 as TCP streams or pipes). The media types defined in this document 94 are needed to correctly identify such content when it is served over 95 HTTP, included in multi-part documents, or used in other places where 96 media types [RFC2045] are used. 98 2. Changes Since RFC 3534 100 o The type "application/ogg" is redefined. 101 o The types "video/ogg" and "audio/ogg" are defined. 102 o New file extensions are defined. 103 o New Macintosh file type codes are defined. 104 o The codecs parameter is defined for optional use. 105 o The Ogg Skeleton extension becomes a recommended addition for 106 content served under the new types. 108 3. Conformance and Document Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in BCP 14, [RFC2119] and 113 indicate requirement levels for compliant implementations. 114 Requirements apply to all implementations unless otherwise stated. 116 An implementation is a software module that supports one of the media 117 types defined in this document. Software modules may support 118 multiple media types, but conformance is considered individually for 119 each type. 121 Implementations that fail to satisfy one or more "MUST" requirements 122 are considered non-compliant. Implementations that satisfy all 123 "MUST" requirements, but fail to satisfy one or more "SHOULD" 124 requirements, are said to be "conditionally compliant". All other 125 implementations are "unconditionally compliant". 127 4. Deployed Media Types and Compatibility 129 The application/ogg media type has been used in an ad-hoc fashion to 130 label and exchange multimedia content in Ogg containers. 132 Use of the "application" top-level type for this kind of content is 133 known to be problematic, in particular since it obfuscates video and 134 audio content. This document thus defines the media types, 136 o video/ogg 137 o audio/ogg 139 which are intended for common use and SHOULD be used when dealing 140 with video or audio content respectively. This document also 141 obsoletes the [RFC3534] definition of application/ogg and marks it 142 for complex data (e.g. multitrack visual, audio, textual and other 143 time-continuously sampled data), which is not clearly video or audio 144 data and thus not suited for either the video/ogg or audio/ogg types. 145 Refer to the following section for more details. 147 An Ogg bitstream generally consists of one or more logical bitstreams 148 that each consist of a series of header and data pages packetising 149 time-continuous binary data [RFC3533]. The content types of the 150 logical bitstreams may be identified without decoding the header 151 pages of the logical bitstreams through use of a [Skeleton] 152 bitstream. Using Ogg Skeleton is REQUIRED for content served under 153 the application/ogg type and RECOMMENDED for video/ogg and audio/ogg, 154 as Skeleton contains identifiers to describe the different 155 encapsulated data. 157 Furthermore, it is RECOMMENDED that implementations that identify a 158 logical bitstream which they cannot decode SHOULD ignore it, while 159 continuing to decode the ones they can. Such precaution ensures 160 backward and forward compatibility with existing and future data. 162 These media types can optionally use the "codecs" parameter described 163 in [RFC4281]. Codecs encapsulated in Ogg require a text identifier 164 at the beginning of the first header page, hence a machine-readable 165 method to identify the encapsulated codecs would be through this 166 header. The following table illustrates how those header values map 167 into strings that are used in the "codecs" parameter when dealing 168 with Ogg media types. 170 Codec Identifier | Codecs Parameter 171 ----------------------------------------------------------- 172 char[5]: 'BBCD\0' | dirac 173 char[5]: '\177FLAC' | flac 174 char[7]: '\x80theora' | theora 175 char[7]: '\x01vorbis' | vorbis 176 char[8]: 'Speex ' | speex 177 char[8]: 'OggMIDI\0' | midi 178 char[8]: 'CMML\0\0\0\0' | cmml 179 char[8]: '\211PNG\r\n\032\n' | png 180 char[8]: '\212MNG\r\n\032\n' | mng 181 char[8]: '\213JNG\r\n\032\n' | jng 182 char[8]: 'CELT ' | celt 183 char[8]: 'PCM ' | pcm 184 char[9]: '\x80kate\0\0\0\0' | kate 185 char[9]: 'YUV4MPEG2' | yuv4mpeg 187 Possible examples include: 189 o application/ogg; codecs="theora, cmml, ecmascript" 190 o video/ogg; codecs="theora, vorbis" 191 o audio/ogg; codecs=speex 193 5. Relation Between the Media Types 195 As stated in the previous section, this document describes three 196 media types which are targeted at different data encapsulated in Ogg. 197 Since Ogg is capable of encapsulating any kind of data, the multiple 198 usage scenarios have revealed interoperability issues between 199 implementations when dealing with content served solely under the 200 application/ogg type. 202 While this document does redefine the earlier definition of 203 application/ogg, this media type will continue to embrace the widest 204 net possible of content with the video/ogg and audio/ogg types being 205 smaller subsets of it. However, the video/ogg and audio/ogg types 206 take precedence in a subset of the usages, specifically when serving 207 multimedia content that is not complex enough to warrant the use of 208 application/ogg. Following this line of thought, the audio/ogg type 209 is an even smaller subset within video/ogg, as it is not intended to 210 refer to visual content. 212 As such, the application/ogg type is the recommended choice to serve 213 content aimed at scientific and other applications that require 214 various multiplexed signals or streams of continuous data, with or 215 without scriptable control of content. For bitstreams containing 216 visual, timed text, and any other type of material that requires a 217 visual interface, but which is not complex enough to warrant serving 218 under application/ogg, the video/ogg type is recommended. In 219 situations where the Ogg bitstream predominantly contains audio data 220 (lyrics, metadata, or cover art notwithstanding), it is recommended 221 to use the audio/ogg type. 223 6. Encoding Considerations 225 Binary: The content consists of an unrestricted sequence of octets. 227 Note: 228 o Ogg encapsulated content is binary data and should be transmitted 229 in a suitable encoding without CR/LF conversion, 7-bit stripping, 230 etc.; base64 [RFC4648] is generally preferred for binary-to-text 231 encoding. 232 o Media types described in this document are used for stream based 233 storage (such as files) and transport (such as TCP streams or 234 pipes); separate types are used to identify codecs such as in 235 real-time applications for the RTP payload formats of Theora 236 [ThRTP] video, Vorbis [VoRTP] or Speex [SpRTP] audio, as well as 237 for identification of encapsulated data within Ogg through 238 Skeleton. 240 7. Security Considerations 242 Refer to [RFC3552] for a discussion of terminology used in this 243 section. 245 The Ogg encapsulation format is a container and only a carrier of 246 content (such as audio, video, and displayable text data) with a very 247 rigid definition. This format in itself is not more vulnerable than 248 any other content framing mechanism. 250 Ogg does not provide for any generic encryption or signing of itself 251 or its contained bitstreams. However, it encapsulates any kind of 252 binary content and is thus able to contain encrypted and signed 253 content data. It is also possible to add an external security 254 mechanism that encrypts or signs an Ogg bitstream and thus provides 255 content confidentiality and authenticity. 257 As Ogg encapsulates binary data, it is possible to include executable 258 content in an Ogg bitstream. Implementations SHOULD NOT execute such 259 content without prior validation of its origin by the end-user. 261 Issues may arise on applications that use Ogg for streaming or file 262 transfer in a networking scenario. In such cases, implementations 263 decoding Ogg and its encapsulated bitstreams have to ensure correct 264 handling of manipulated bitstreams, of buffer overflows, and similar 265 issues. 267 It is also possible to author malicious Ogg bitstreams, which attempt 268 to call for an excessively large picture size, high sampling-rate 269 audio, etc. Implementations SHOULD protect themselves against this 270 kind of attack. 272 Ogg has an extensible structure, so that it is theoretically possible 273 that metadata fields or media formats might be defined in the future 274 which might be used to induce particular actions on the part of the 275 recipient, thus presenting additional security risks. However, this 276 type of capability is currently not supported in the referenced 277 specification. 279 Implementations may fail to implement a specific security model or 280 other means to prevent possibly dangerous operations. Such failure 281 might possibly be exploited to gain unauthorized access to a system 282 or sensitive information; such failure constitutes an unknown factor 283 and is thus considered out of the scope of this document. 285 8. Interoperability Considerations 287 The Ogg container format is device-, platform- and vendor-neutral and 288 has proved to be widely implementable across different computing 289 platforms through a wide range of encoders and decoders. A broadly 290 portable reference implementation [libogg] is available under the 291 revised (3-clause) BSD license, which is a Free Software license. 293 The Xiph.Org Foundation has defined the specification, 294 interoperability, and conformance, and conducts regular 295 interoperability testing. 297 The use of the Ogg Skeleton extension has been confirmed not to cause 298 interoperability issues with existing implementations. Third parties 299 are, however, welcome to conduct their own testing. 301 9. IANA Considerations 303 In accordance with the procedures set forth in [RFC4288], this 304 document registers two new media types and redefines the existing 305 application/ogg as defined in the following section. 307 10. Ogg Media Types 309 10.1. application/ogg 311 Type name: application 313 Subtype name: ogg 315 Required parameters: none 317 Optional parameters: codecs, whose syntax is defined in RFC 4281. 318 See section 4 of RFC XXXX for a list of allowed values. 320 Encoding considerations: See section 6 of RFC XXXX. 322 Security considerations: See section 7 of RFC XXXX. 324 Interoperability considerations: None, as noted in section 8 of RFC 325 XXXX. 327 Published specification: RFC 3533 329 Applications which use this media type: Scientific and otherwise 330 which require various multiplexed signals or streams of data, with or 331 without scriptable control of content. 333 Additional information: 335 Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, 336 correspond to the string "OggS". 338 File extension(s): .ogx 339 RFC 3534 defined the file extension .ogg for application/ogg, 340 which RFC XXXX obsoletes in favor of .ogx due to concerns where, 341 historically, some implementations expect .ogg files to be solely 342 Vorbis-encoded audio. 344 Macintosh File Type Code(s): OggX 346 Person & Email address to contact for further information: See 347 "Authors' Addresses" section. 349 Intended usage: COMMON 351 Restrictions on usage: The type application/ogg SHOULD only be used 352 in situations where it is not appropriate to serve data under the 353 video/ogg or audio/ogg types. Data served under the application/ogg 354 type SHOULD use the .ogx file extension and MUST contain an Ogg 355 Skeleton logical bitstream to identify all other contained logical 356 bitstreams. 358 Author: See "Authors' Addresses" section. 360 Change controller: The Xiph.Org Foundation. 362 10.2. video/ogg 364 Type name: video 366 Subtype name: ogg 368 Required parameters: none 370 Optional parameters: codecs, whose syntax is defined in RFC 4281. 371 See section 4 of RFC XXXX for a list of allowed values. 373 Encoding considerations: See section 6 of RFC XXXX. 375 Security considerations: See section 7 of RFC XXXX. 377 Interoperability considerations: None, as noted in section 8 of RFC 378 XXXX. 380 Published specification: RFC 3533 382 Applications which use this media type: Multimedia applications, 383 including embedded, streaming, and conferencing tools. 385 Additional information: 387 Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, 388 correspond to the string "OggS". 390 File extension(s): .ogv 392 Macintosh File Type Code(s): OggV 394 Person & Email address to contact for further information: See 395 "Authors' Addresses" section. 397 Intended usage: COMMON 399 Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg 400 bitstreams containing visual, audio, timed text, or any other type of 401 material that requires a visual interface. It is intended for 402 content not complex enough to warrant serving under "application/ 403 ogg"; for example, a combination of Theora video, Vorbis audio, 404 Skeleton metadata, and CMML captioning. Data served under the type 405 "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream. 406 Implementations interacting with the type "video/ogg" SHOULD support 407 multiplexed bitstreams. 409 Author: See "Authors' Addresses" section. 411 Change controller: The Xiph.Org Foundation. 413 10.3. audio/ogg 415 Type name: audio 417 Subtype name: ogg 419 Required parameters: none 421 Optional parameters: codecs, whose syntax is defined in RFC 4281. 422 See section 4 of RFC XXXX for a list of allowed values. 424 Encoding considerations: See section 6 of RFC XXXX. 426 Security considerations: See section 7 of RFC XXXX. 428 Interoperability considerations: None, as noted in section 8 of RFC 429 XXXX. 431 Published specification: RFC 3533 433 Applications which use this media type: Multimedia applications, 434 including embedded, streaming, and conferencing tools. 436 Additional information: 438 Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, 439 correspond to the string "OggS". 441 File extension(s): .oga, .ogg, .spx 443 Macintosh File Type Code(s): OggA 445 Person & Email address to contact for further information: See 446 "Authors' Addresses" section. 448 Intended usage: COMMON 450 Restrictions on usage: The type "audio/ogg" SHOULD be used when the 451 Ogg bitstream predominantly contains audio data. Content served 452 under the "audio/ogg" type SHOULD have an Ogg Skeleton logical 453 bitstream when using the default .oga file extension. The .ogg and 454 .spx file extensions indicate a specialization that requires no 455 Skeleton due to backward compatibility concerns with existing 456 implementations. In particular, .ogg is used for Ogg files that 457 contain only a Vorbis bitstream, while .spx is used for Ogg files 458 that contain only a Speex bitstream. 460 Author: See "Authors' Addresses" section. 462 Change controller: The Xiph.Org Foundation. 464 11. Acknowledgements 466 The authors gratefully acknowledge the contributions of Magnus 467 Westerlund, Alfred Hoenes, and Peter Saint-Andre. 469 12. Copying Conditions 471 The authors agree to grant third parties the irrevocable right to 472 copy, use and distribute the work, with or without modification, in 473 any medium, without royalty, provided that, unless separate 474 permission is granted, redistributed modified works do not contain 475 misleading author, version, name of work, or endorsement information. 477 13. References 479 13.1. Normative References 481 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 482 Extensions (MIME) Part One: Format of Internet Message 483 Bodies", RFC 2045, November 1996. 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, March 1997. 488 [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", 489 RFC 3533, May 2003. 491 [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs 492 Parameter for "Bucket" Media Types", RFC 4281, 493 November 2005. 495 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 496 Registration Procedures", BCP 13, RFC 4288, 497 December 2005. 499 13.2. Informative References 501 [CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous 502 Media Markup Language (CMML)", March 2006, 503 . 505 [Dirac] Dirac Group, "Dirac Specification", 506 . 508 [FLAC] Coalson, J., "The FLAC Format", 509 . 511 [libogg] Xiph.Org Foundation, "The libogg API", June 2000, 512 . 514 [Ogg] Xiph.Org Foundation, "Ogg bitstream documentation: Ogg 515 logical and physical bitstream overview, Ogg logical 516 bitstream framing, Ogg multi-stream multiplexing", 517 . 519 [RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534, 520 May 2003. 522 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 523 Text on Security Considerations", BCP 72, RFC 3552, 524 July 2003. 526 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 527 Encodings", RFC 4648, October 2006. 529 [Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata 530 Bitstream", November 2007, 531 . 533 [Speex] Valin, J., "The Speex Codec Manual", February 2002, 534 . 536 [SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard, 537 "RTP Payload Format for the Speex Codec", Work in 538 Progress , July 2007, 539 . 541 [Theora] Xiph.Org Foundation, "Theora Specification", 542 October 2007, . 544 [ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded 545 Video", Work in Progress , July 2006, 546 . 549 [Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004, 550 . 552 [VoRTP] Barbato, L., "RTP Payload Format for Vorbis Encoded 553 Audio", Work in Progress , November 2007, 554 . 556 Authors' Addresses 558 Ivo Emanuel Goncalves 559 Xiph.Org Foundation 560 21 College Hill Road 561 Somerville, MA 02144 562 US 564 EMail: justivo@gmail.com 565 URI: xmpp:justivo@gmail.com 567 Silvia Pfeiffer 568 Xiph.Org Foundation 570 EMail: silvia@annodex.net 571 URI: http://annodex.net/ 573 Christopher Montgomery 574 Xiph.Org Foundation 576 EMail: monty@xiph.org 577 URI: http://xiph.org 579 Full Copyright Statement 581 Copyright (C) The IETF Trust (2008). 583 This document is subject to the rights, licenses and restrictions 584 contained in BCP 78, and except as set forth therein, the authors 585 retain all their rights. 587 This document and the information contained herein are provided on an 588 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 589 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 590 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 591 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 592 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Intellectual Property 597 The IETF takes no position regarding the validity or scope of any 598 Intellectual Property Rights or other rights that might be claimed to 599 pertain to the implementation or use of the technology described in 600 this document or the extent to which any license under such rights 601 might or might not be available; nor does it represent that it has 602 made any independent effort to identify any such rights. Information 603 on the procedures with respect to rights in RFC documents can be 604 found in BCP 78 and BCP 79. 606 Copies of IPR disclosures made to the IETF Secretariat and any 607 assurances of licenses to be made available, or the result of an 608 attempt made to obtain a general license or permission for the use of 609 such proprietary rights by implementers or users of this 610 specification can be obtained from the IETF on-line IPR repository at 611 http://www.ietf.org/ipr. 613 The IETF invites any interested party to bring to its attention any 614 copyrights, patents or patent applications, or other proprietary 615 rights that may cover technology that may be required to implement 616 this standard. Please address the information to the IETF at 617 ietf-ipr@ietf.org. 619 Acknowledgement 621 Funding for the RFC Editor function is provided by the IETF 622 Administrative Support Activity (IASA).