summaryrefslogtreecommitdiffhomepage
path: root/ogg/doc/rfc3534.txt
diff options
context:
space:
mode:
Diffstat (limited to 'ogg/doc/rfc3534.txt')
-rw-r--r--ogg/doc/rfc3534.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/ogg/doc/rfc3534.txt b/ogg/doc/rfc3534.txt
new file mode 100644
index 0000000..840f1ec
--- /dev/null
+++ b/ogg/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]
+