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]
`
`Page 1 of 5
`
`BMW EXHIBIT 1016
`
`

`

`
`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]
`
`Page 2 of 5
`
`

`

`
`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]
`
`Page 3 of 5
`
`

`

`
`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]
`
`Page 4 of 5
`
`

`

`
`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]
`
`Page 5 of 5
`
`