From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4393.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc4393.txt (limited to 'doc/rfc/rfc4393.txt') diff --git a/doc/rfc/rfc4393.txt b/doc/rfc/rfc4393.txt new file mode 100644 index 0000000..2d9d6aa --- /dev/null +++ b/doc/rfc/rfc4393.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group H. Garudadri +Request for Comments: 4393 QUALCOMM +Category: Standards Track March 2006 + + + MIME Type Registrations for 3GPP2 Multimedia Files + +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 (2006). + +Abstract + + 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. + +Table of Contents + + 1. Introduction ....................................................1 + 1.1. Conventions Used in This Document ..........................2 + 2. Security Considerations .........................................2 + 3. MIME Types ......................................................3 + 3.1. Files with Audio but No Video ..............................3 + 3.2. Any Files ..................................................4 + 4. IANA Considerations .............................................5 + 5. Acknowledgements ................................................6 + 6. References ......................................................6 + 6.1. Normative References .......................................6 + 6.2. Informative References .....................................6 + +1. Introduction + + The third-generation partnership project 2 (3GPP2) for 3rd generation + cellular telephony has defined a standard file format to contain + audio/visual sequences that may be downloaded to cellular phones + [3gpp2]. At the time of writing, the 3GPP2 file format (3G2) can + contain H.263, H.264, or MPEG-4 video; and 13K Vocoder, EVRC or AMR + Narrow-band speech, or AAC audio; and 3GPP timed text. + + + + +Garudadri Standards Track [Page 1] + +RFC 4393 3GPP2 Multimedia Registrations March 2006 + + + Within the file, as with all files in the 'ISO' family, there is an + intrinsic file-type box, which identifies those specifications to + which the file complies, and which players (possibly compliant with + only one specification) are permitted by the content author to play + the file. This identification is through four-letter 'brands'. + Files identified by the MIME [MIME1] type defined in this document + MUST contain, in their compatible brands list, a brand defined in a + standard (issued by 3GPP2) that can apply to 3GPP2 files. + + The MIME types defined in this document are needed correctly to + identify such files when they are served over HTTP, included in + multi-part documents, or used in other places where MIME types are + used. + +1.1. Conventions Used in This Document + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in RFC 2119 + [RFC2119]. + +2. Security Considerations + + The 3GPP2 file format may contain audio, video, and displayable text + data. There is currently no provision for 'active' elements (such as + scripts) of any kind. + + Clearly, it is possible to author malicious files that attempt to + call for an excessively large picture size, high sampling-rate audio, + etc. However, clients can and usually do protect themselves against + this kind of attack. + + It should be noted that selected metadata fields may encompass + information partly intended to protect the media against unauthorized + use or distribution. In this case, the intention is that alteration + or removal of the data in the field would be treated as an offense + under national agreement-based World Intellectual Property + Organization (WIPO) treaties. + + 3GPP2 files have an extensible structure, so it is theoretically + possible that metadata fields or media formats could be defined in + the future that could be used to induce particular actions on the + part of the recipient, thus presenting additional security risks; but + this type of capability is currently not supported in the referenced + specification. + + + + + + +Garudadri Standards Track [Page 2] + +RFC 4393 3GPP2 Multimedia Registrations March 2006 + + + Encryption, signing, or authentication of these file formats can be + done using any media-independent transformations of the file or media + data. + +3. MIME Types + + This registration applies to all files defined as using the '3G2' + file format and identified with a suitable brand in a 3GPP2 + specification. The usual file suffix for all these files is ".3g2". + +3.1. Files with Audio but No Video + + The type "audio/3gpp2" may be used for files containing audio but no + visual presentation (neither video nor timed text, for example). + + To: ietf-types@iana.org + Subject: Registration of Standard MIME media type audio/3gpp2 + + MIME media type name: + audio + MIME subtype name: + 3gpp2 + Required parameters: + None. + Optional parameters: + Codecs. See [Bucket]. 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. + Optional parameter values: + [3gpp2] + Encoding considerations: + This data is binary and should be transmitted in a suitable + encoding without CR/LF conversion, 7-bit stripping, etc.; base64 + is a suitable encoding. Note that this MIME type is used only + for files; separate types are used for real-time transfer, such + as for the RTP payload format for 13K vocoder speech [RFC2658]. + Security considerations: + See the security considerations section in RFC 4393 (this + document). + Interoperability considerations: + The 3GPP2 organization has defined the specification of the media + format [3gpp2]. Interoperability and conformance testing is done + in cooperation with other bodies, including the Open Mobile + Alliance (OMA) and the + International Multimedia Telecommunications Consortium (IMTC) + . + + + + + +Garudadri Standards Track [Page 3] + +RFC 4393 3GPP2 Multimedia Registrations March 2006 + + + Published specification: + 3GPP2 C.S0045, 3GPP2 C.S0050 [3gpp2] + 3GPP2 specifications are publicly accessible at the 3GPP2 web + site, . + Applications that use this media type: + Multi-media + Additional information: + The type "audio/3gpp2" MAY be used for files containing audio but + no visual presentation. Files served under this type MUST NOT + contain any visual material. (Note that 3GPP timed text is + visually presented and is considered visual material). + Magic number(s): + None. However, the file-type box must occur first in the file, + and MUST contain a 3GPP2 brand in its compatible brands list. + File extension(s): + 3g2 and 3gpp2 are both declared at ; + 3g2 is preferred. + Macintosh file type code(s): + '3gp2' + Person & email address to contact for further information: + H. Garudadri, hgarudadri@qualcomm.com + Intended usage: + COMMON + Change controller: + 3GPP2 + +3.2. Any Files + + The type "video/3gpp2" is valid for all files. It is valid to serve + an audio-only file as "video/3gpp2". + + To: ietf-types@iana.org + Subject: Registration of Standard MIME media type video/3gpp2 + + MIME media type name: + video + MIME subtype name: + 3gpp2 + Required parameters: + None + Optional parameters: + Codecs. See [Bucket]. 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. + Optional parameter values: + [3gpp2] + + + + + +Garudadri Standards Track [Page 4] + +RFC 4393 3GPP2 Multimedia Registrations March 2006 + + + Encoding considerations: + This data is binary and should be transmitted in a suitable + encoding without CR/LF conversion, 7-bit stripping, etc.; base64 + is a suitable encoding. Note that this MIME type is used only + for files; separate types are used for real-time transfer, such + as for the RTP payload formats for H.263 [RFC2429] and 13K + vocoder speech [RFC2658]. + Security considerations: + See the security considerations section in RFC 4393 (this + document). + Interoperability considerations: + The 3GPP2 organization has defined the specification of the media + format [3gpp2]. Interoperability and conformance testing is done + in cooperation with other bodies, including the Open Mobile + Alliance (OMA) and the + International Multimedia Telecommunications Consortium (IMTC) + . + Published specification: + 3GPP2 C.S0045, 3GPP2 C.S0050 [3gpp2] + + 3GPP2 specifications are publicly accessible at the 3GPP2 web + site, . + Applications that use this media type: + Multi-media + Additional information: + Magic number(s): + None. However, the file-type box must occur first in the file + and MUST contain a 3GPP2 brand in its compatible brands list. + File extension(s): + 3g2 and 3gpp2 are both declared at ; + 3g2 is preferred. + Macintosh file type code(s): + '3gp2' + Person & email address to contact for further information: + H.Garudadri, hgarudadri@qualcomm.com + Intended usage: + COMMON + Change controller: + 3GPP2 + +4. IANA Considerations + + This document registers the MIME media types audio/3gpp2 and + video/3gpp2, defined above. + + + + + + + +Garudadri Standards Track [Page 5] + +RFC 4393 3GPP2 Multimedia Registrations March 2006 + + +5. Acknowledgements + + This document used RFC 3839 as a template. The authors of RFC 3839, + R. Castagno, and D. Singer, are gratefully acknowledged. + +6. References + +6.1. Normative References + + [3gpp2] Published specifications: C.S0050: 3GPP2 File Formats for + Multimedia Services. C.S0045: Multimedia Messaging + Service (MMS) Media Format and Codecs for cdma2000 Spread + Spectrum Systems. + + [Bucket] Gellens, R., Singer, D., and P. Frojdh, "The Codecs + Parameter for "Bucket" Media Types", RFC 4281, November + 2005. + + [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +6.2. Informative References + + [RFC2429] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, + C., Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. + Zhu, "RTP Payload Format for the 1998 Version of ITU-T Rec. + H.263 Video (H.263+)", RFC 2429, October 1998. + + [RFC2658] McKay, K., "RTP Payload Format for PureVoice(tm) Audio", + RFC 2658, August 1999. + +Author's Address + + Harinath Garudadri + Qualcomm Inc + 5775 Morehouse Dr. + San Diego, CA 92121 + + Phone: +1 858 651 6383 + EMail: hgarudadri@qualcomm.com + + + + + + + +Garudadri Standards Track [Page 6] + +RFC 4393 3GPP2 Multimedia Registrations March 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Garudadri Standards Track [Page 7] + -- cgit v1.2.3