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]
+