rfc-4393

MIME Type Registrations for 3GPP2 Multimedia Files

H. Garudadri
date2006-03 streamIETF wgnon working group statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc4393 doi10.17487/RFC4393
This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

updated by

Extracted elements (15)

design-rationale §3.1

Binary 3GPP2 data should be transmitted using base64 or another encoding that avoids CR/LF conversion or 7-bit stripping, because the format is inherently binary and such transformations would corrupt the content.

interoperability-note §3.1

Interoperability and conformance testing for the 3GPP2 media format is conducted in cooperation with the Open Mobile Alliance (OMA) and the International Multimedia Telecommunications Consortium (IMTC).

interoperability-note §3.1

These MIME types are intended only for file transfer; separate MIME types and RTP payload formats (e.g., RFC 2429 for H.263, RFC 2658 for 13K vocoder) are used for real-time transfer.

rtp, realtime

normative-requirement §1 MUST

Files identified by the MIME types defined in this document MUST contain, in their compatible brands list, a brand defined in a 3GPP2 standard that can apply to 3GPP2 files.

normative-requirement §3.1 MUST NOT

Files served under the audio/3gpp2 type MUST NOT contain any visual material, including 3GPP timed text, which is considered visual material.

normative-requirement §3.1 MUST

For both audio/3gpp2 and video/3gpp2, the file-type box must occur first in the file and MUST contain a 3GPP2 brand in its compatible brands list.

normative-requirement §3.1 MUST

If the audio/3gpp2 body part contains another container format, the Codecs parameter MUST list all codecs indicated by all formats, including any contained formats.

normative-requirement §3.2 MUST

If the video/3gpp2 body part contains another container format, the Codecs parameter MUST list all codecs indicated by all formats, including any contained formats.

normative-requirement §3.1 MAY

The audio/3gpp2 type MAY be used for files containing audio but no visual presentation, providing implementers flexibility in MIME type selection for audio-only 3GPP2 content.

protocol-element §3.1

The audio/3gpp2 MIME type is for 3GPP2 files containing audio but no visual presentation (neither video nor timed text). The optional Codecs parameter (per RFC 4281) enumerates the codecs present.

protocol-element §3.2

The video/3gpp2 MIME type is valid for all 3GPP2 files, including audio-only files. It supports H.263, H.264, or MPEG-4 video; 13K Vocoder, EVRC, AMR Narrow-band, or AAC audio; and 3GPP timed text.

registry §4

Registers two MIME media types with IANA: audio/3gpp2 (for 3GPP2 files containing audio but no visual presentation) and video/3gpp2 (valid for all 3GPP2 files, including audio-only).

registry

security-consideration §2

Certain metadata fields may contain DRM or rights-management information; alteration or removal of such data may constitute an offense under WIPO treaty-based national agreements.

security

security-consideration §2

The 3GPP2 file format currently has no provision for active elements such as scripts, limiting certain attack vectors; however, malicious files could request excessively large picture sizes or high sampling-rate audio, though clients typically protect against this.

security

security-consideration §2

The extensible structure of 3GPP2 files means future metadata fields or media formats could potentially be used to induce actions on the recipient, though no such capability is currently defined in the specification.

security