1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc3003.txt b/doc/rfc/rfc3003.txt
new file mode 100644
index 0000000..8e0725c
--- /dev/null
+++ b/doc/rfc/rfc3003.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                         M. Nilsson
+Request for Comments: 3003                                 November 2000
+Category: Standards Track
+
+
+                       The audio/mpeg 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 (2000).  All Rights Reserved.
+
+Abstract
+
+   The audio layers of the MPEG-1 and MPEG-2 standards are in frequent
+   use on the internet, but there is no uniform Multipurpose Internet
+   Mail Extension (MIME) type for these files.  The intention of this
+   document is to define the media type audio/mpeg to refer to this kind
+   of contents.
+
+   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 [RFC2119].
+
+1.  MPEG audio
+
+   The audio compression defined as layer I, layer II and layer III in
+   the MPEG-1 [MPEG-1] and MPEG-2 [MPEG-2] standards is a popular method
+   of compressing audio with a low quality loss.  The compressed audio
+   is split into several small data frames, each containing a frame
+   header and compressed audio data.
+
+   The mime type audio/mpeg defines a elementary byte stream containing
+   MPEG frames according to [MPEG-1] and [MPEG-2], possibly interspersed
+   with non MPEG data.  Non MPEG data is data without MPEG
+   synchronization or in other ways not possible to decompress without
+   error.
+
+   Typically MPEG audio meta data is concatenated with the MPEG stream,
+   e.g., the meta data format ID3 puts a 128 byte data block in the end
+   of the stream while ID3v2 [ID3V2] prepends a data block of variable
+
+
+
+Nilsson                     Standards Track                     [Page 1]
+
+RFC 3003               The audio/mpeg Media Type           November 2000
+
+
+   size to the stream.
+
+   NOTE: MPEG audio was not designed as a file format but as a format
+   for transmitting audio streams.  As such, it does not have any well
+   defined way of including meta data along with audio information.
+   Some products embed meta data using zero amplitude frames or
+   disguised as transmission errors.  Others embed the MPEG data in WAV
+   format.
+
+   NOTE: The audio/MPS mime type is in use in addition to the
+   audio/mpeg.  The MPA [RFC 1890] sub-type refers to MPEG audio when it
+   is segmented and send as a Realtime Transport Protocol (RTP) payload.
+
+2.  Registration Information
+
+   To: ietf-types@iana.org Subject: Registration of MIME media type
+   audio/mpeg
+
+   MIME media type name: audio
+
+   MIME subtype name: mpeg
+
+   Required parameters: none
+
+   Optional parameters: none
+
+   Encoding considerations:
+
+       For use over internet it is assumed that lower layers take care
+       of transmission errors, so audio/mpeg data MAY include MPEG
+       frames generated without the optional cyclic redundancy checks
+       (CRC) for improved audio quality.
+
+       The MPEG audio data is binary data, and must be encoded for
+       non-binary transport; the Base64 encoding is suitable for Email.
+       Note that the MPEG audio data does not compress easily using
+       lossless compression.
+
+   Security considerations:
+
+        MPEG is a tagged data format, and some tags are available for
+        private use.  As such, arbitrary material could potentially
+        be transferred in the MPEG stream, including executable content.
+        Tagged data containing executable content SHOULD never be sent
+        and MUST not be executed if it is received.
+
+
+
+
+
+
+Nilsson                     Standards Track                     [Page 2]
+
+RFC 3003               The audio/mpeg Media Type           November 2000
+
+
+                                NOTE
+
+            The requirement that such content not be executed on receipt
+            is especially important since situations exist where content
+            will be generated independently and therefore could contain
+            executable content that the sender is unaware of.
+
+        Audio/mpeg objects are not signed or encrypted internally.
+        External security mechanisms must be employed to ensure content
+        confidentiality
+
+   Interoperability considerations:
+
+       MPEG audio has proven to be widely interoperable across computer
+       platforms.
+
+   Published specification: see [MPEG-1] and [MPEG-2]
+
+   Applications which use this media type:
+
+       MPEG audio is device-, platform- and vendor-neutral and is
+       supported by a wide range of encoders and decoders (players).
+
+   Additional information:
+
+       Magic number(s): none
+       File extension(s): .mp1, .mp2, .mp3
+       Macintosh File Type Code(s): MPEG
+       Object Identifier(s) or OID(s): none
+
+   Person & email address to contact for further information:
+
+       The author of this document.
+
+   Intended usage: COMMON
+
+   Author/Change controller: Martin Nilsson (see section 5)
+
+   3.  Security Considerations
+
+   Security considerations are discussed in the security considerations
+   clause of the MIME registration in section 2.
+
+
+
+
+
+
+
+
+
+Nilsson                     Standards Track                     [Page 3]
+
+RFC 3003               The audio/mpeg Media Type           November 2000
+
+
+4.  References
+
+   [ID3v2]
+     Martin Nilsson, "ID3 tag version 2.3.0".
+     <url:http://www.id3.org/id3v2.3.0.txt>
+
+   [MPEG-1]
+     ISO/IEC 11172-3:1993.
+     Coding of moving pictures and associated audio for digital storage
+     media at up to about 1,5 Mbit/s, Part 3: Audio.
+     Technical committee / subcommittee: JTC 1 / SC 29
+
+   [MPEG-2]
+     ISO/IEC 13818-3:1995
+     Generic coding of moving pictures and associated audio information,
+     Part 3: Audio.
+     Technical committee / subcommittee: JTC 1 / SC 29
+
+     and
+
+     ISO/IEC DIS 13818-3
+     Generic coding of moving pictures and associated audio information,
+     Part 3: Audio (Revision of ISO/IEC 13818-3:1995)
+
+   [RFC2119]
+     Bradner, S., "Key words for use in RFCs to Indicate Requirement
+     Levels", BCP 14, RFC 2119, March 1997.
+
+5.  Author's Address
+
+   Martin Nilsson
+   Rydsvagen 246 C. 30
+   S-584 34 Linkoping
+   Sweden
+
+   EMail: nilsson@id3.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nilsson                     Standards Track                     [Page 4]
+
+RFC 3003               The audio/mpeg Media Type           November 2000
+
+
+6.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nilsson                     Standards Track                     [Page 5]
+