summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4393.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4393.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4393.txt')
-rw-r--r--doc/rfc/rfc4393.txt395
1 files changed, 395 insertions, 0 deletions
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) <http://www.openmobilealliance.org> and the
+ International Multimedia Telecommunications Consortium (IMTC)
+ <http://www.imtc.org/>.
+
+
+
+
+
+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, <http://www.3gpp2.org>.
+ 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 <http://www.nist.gov/nics/>;
+ 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) <http://www.openmobilealliance.org> and the
+ International Multimedia Telecommunications Consortium (IMTC)
+ <http://www.imtc.org/>.
+ Published specification:
+ 3GPP2 C.S0045, 3GPP2 C.S0050 [3gpp2]
+
+ 3GPP2 specifications are publicly accessible at the 3GPP2 web
+ site, <http://www.3gpp2.org>.
+ 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 <http://www.nist.gov/nics/>;
+ 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]
+