doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc3534.txt b/doc/rfc/rfc3534.txt
new file mode 100644
index 0000000..840f1ec
--- /dev/null
+++ b/doc/rfc/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]
+