RFC 3003

RFC 3003: The audio/mpeg Media Type 🎀

okay bestie, so this is RFC 3003 ✨ titled The audio/mpeg Media Type, written by M. Nilsson and dated November 2000. It's a Standards Track doc, so it's an actual Internet standard 💅 It comes from the Network Working Group, and its title block doesn't list anything it obsoletes or updates, so it's standing completely on its own 🦋

Status of This Memo 📣

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright Notice ©️

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

Abstract 🌸

The audio layers of MPEG-1 and MPEG-2 are used all over the internet, but there's no uniform Multipurpose Internet Mail Extension (MIME) type for these files, which is kinda sad 😭 This document defines the media type audio/mpeg to refer to this kind of content.

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 🎶

okay so 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 super popular because it compresses audio with a low quality loss 🤌 The compressed audio gets split into several small data frames, and each one has a frame header plus compressed audio data.

The audio/mpeg mime type defines an 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 data that otherwise can't be decompressed without error 🙈

Typically, MPEG audio metadata gets concatenated with the MPEG stream. For example, the metadata format ID3 puts a 128 byte data block at the end of the stream, while ID3v2 [ID3V2] prepends a data block of variable size to the stream 🎧

NOTE: MPEG audio was not designed as a file format but as a format for transmitting audio streams. So it doesn't have any well-defined way of including metadata along with the audio info 💀 Some products embed metadata using zero amplitude frames or disguise it as transmission errors. Others embed the MPEG data in WAV format. Chaotic, but that's the vibe.

NOTE: The audio/MPS mime type is in use in addition to audio/mpeg. The MPA [RFC 1890] sub-type refers to MPEG audio when it's segmented and sent as a Realtime Transport Protocol (RTP) payload 🦋

2. Registration Information 📝

Here's the registration template, and yes, I'm copying every field exactly because the form needs it 🍓

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 the internet, it's 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, so it must be encoded for non-binary transport, and Base64 is suitable for Email. Also, MPEG audio data doesn't compress easily using lossless compression, so don't expect miracles 🙃

Security considerations: Okay, this part is serious 🚨 MPEG is a tagged data format, and some tags are available for private use. That means arbitrary material could potentially be transferred in the MPEG stream, including executable content. Tagged data containing executable content SHOULD never be sent, and it MUST not be executed if it is received.

NOTE: The requirement that such content not be executed on receipt is especially important, because situations exist where content will be generated independently. That means it could contain executable content 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, which is honestly iconic 👑

Published specification: see [MPEG-1] and [MPEG-2]

Applications which use this media type: MPEG audio is device-, platform- and vendor-neutral, and it's 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. Go read it, it's giving serious 👀

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

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. Derivative works that comment on or explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. The condition is 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. The exception is when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed. The other exception is translating 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. Forever and ever 🫶

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. Thank you, Internet Society 💅✨