diff options
Diffstat (limited to 'doc/rfc3534.txt')
-rw-r--r-- | doc/rfc3534.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc3534.txt b/doc/rfc3534.txt new file mode 100644 index 0000000..840f1ec --- /dev/null +++ b/doc/rfc3534.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group L. Walleij +Request for Comments: 3534 The Ogg Vorbis Community +Category: Standards Track May 2003 + + + The application/ogg Media Type + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Ogg Bitstream Format aims at becoming a general, freely-available + standard for transporting multimedia content across computing + platforms and networks. The intention of this document is to define + the MIME media type application/ogg to refer to this kind of content + when transported across the Internet. It is the intention of the Ogg + Bitstream Format developers that it be usable without intellectual + property concerns. + +Conventions used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + +1. The Ogg Bitstream Format + + The Ogg Bitstream format has been developed as a part of a larger + project aimed at creating a set of components for the coding and + decoding of multimedia content (codecs) which are to be freely + available and freely re-implementable both in software and in + hardware for the computing community at large, including the Internet + community. + + Raw packets from these codecs may be used directly by transport + mechanisms that provide their own framing and packet-separation + mechanisms (such as UDP datagrams). + + + + +Walleij Standards Track [Page 1] + +RFC 3534 The application/ogg Media Type May 2003 + + + One such framing and content-separation mechanism is the real-time + transport protocol (RTP). RTP allows the streaming of synchronous + lossy data for broadcasting and similar purposes. If this function + is desired then a separate RTP wrapping mechanism should be used. A + wrapping mechanism is currently under development. + + For stream based storage (such as files) and transport (such as TCP + streams or pipes), Ogg codecs use the Ogg Bitstream Format to provide + framing/sync, sync recapture after error, landmarks during seeking, + and enough information to properly separate data back into packets at + the original packet boundaries without relying on decoding to find + packet boundaries. The application/ogg MIME type refers to this kind + of bitstreams, when no further knowledge of the bitstream content + exists. + + The bitstream format in itself is documented in [1]. + +2. Registration Information + + To: ietf-types@iana.org + + Subject: Registration of MIME media type application/ogg + + MIME media type name: application + + MIME subtype name: ogg + + Required parameters: none + + Optional parameters: none + + Encoding Considerations: + + The Ogg bitstream format is binary data, and must be encoded for + non-binary transport; the Base64 encoding is suitable for Email. + Binary encoding could also be used. + + Security Considerations: + + As the Ogg bitstream file is a container format and only a carrier of + content (such as Vorbis audio) with a very rigid definition (see + [1]), this format in itself is not more vulnerable than any other + content framing mechanism. The main security consideration for the + receiving application is to ensure that manipulated packages can not + cause buffer overflows and the like. It is possible to encapsulate + even executable content in the bitstream, so for such uses additional + security considerations must be taken. + + + + +Walleij Standards Track [Page 2] + +RFC 3534 The application/ogg Media Type May 2003 + + + Ogg bitstream files are not signed or encrypted using any applicable + encryption schemes. External security mechanisms must be added if + content confidentiality and authenticity is to be achieved. + + Interoperability considerations: + + The Ogg bitstream format has proved to be widely implementable across + different computing platforms. A broadly portable reference + implementation is available under a BSD license. + + The Ogg bitstream format is not patented and can be implemented by + third parties without patent considerations. + + Published specification: + + See [1]. + + Applications which use this media type: + + Any application that implements the specification will be able to + encode or decode Ogg bitstream files. Specifically, the format is + supposed to be used by subcodecs that implement, for example, Vorbis + audio. + + Additional information: + + Magic number(s): + + In Ogg bitstream files, the first four bytes are 0x4f 0x67 0x67 0x53 + corresponding to the string "OggS". + + File extension: .ogg + + Macintosh File Type Code(s): OggS + + Object Identifier(s) or OID(s): none + + Person & email address to contact for further information: + + Questions about this proposal should be directed to Linus Walleij + <triad@df.lth.se>. Technical questions about the Ogg bitstream + standard may be asked on the mailing lists for the developer + community. <http://www.xiph.org/archives/> + + Intended usage: COMMON + + + + + + +Walleij Standards Track [Page 3] + +RFC 3534 The application/ogg Media Type May 2003 + + + Author/Change controller: + + This document was written by Linus Walleij <triad@df.lth.se>. + Changes to this document will either be handled by him, a + representative of the Xiph.org, or the associated development + communities. + + The Ogg bitstream format is controlled by the Xiph.org and the + respective development communities. + +3. Security Considerations + + Security considerations are discussed in the security considerations + clause of the MIME registration in section 2. + +4. Normative References + + [1] Pfeiffer, S., "The Ogg encapsulation format version 0", RFC + 3533, May 2003. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +5. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + +Walleij Standards Track [Page 4] + +RFC 3534 The application/ogg Media Type May 2003 + + +6. Author's Address + + Linus Walleij + The Ogg Vorbis Community + Master Olofs Vag 24 + Lund 224 66 + SE + + Phone: +46 703 193678 + EMail: triad@df.lth.se + URI: http://www.xiph.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Walleij Standards Track [Page 5] + +RFC 3534 The application/ogg Media Type May 2003 + + +7. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Walleij Standards Track [Page 6] + |