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/rfc3839.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc3839.txt (limited to 'doc/rfc/rfc3839.txt') diff --git a/doc/rfc/rfc3839.txt b/doc/rfc/rfc3839.txt new file mode 100644 index 0000000..a297405 --- /dev/null +++ b/doc/rfc/rfc3839.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group R. Castagno +Request for Comments: 3839 Nokia Mobile Phones +Category: Standards Track D. Singer + Apple Computer, Inc. + July 2004 + + + MIME Type Registrations for + 3rd Generation Partnership Project (3GPP) 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 (2004). + +Abstract + + This document serves to register and document the standard MIME types + associated with the 3GPP multimedia file format, which is part of the + family based on the ISO Media File Format. + +1. Introduction + + 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 BCP 14, RFC 2119 + [RFC2119]. + + The third-generation partnership project (3GPP) for third-generation + cellular telephony has defined a standard file format to contain + audio/visual sequences which may be downloaded to cellular phones + [3GPP]. At the time of writing, the 3GPP file format (3GP) can + contain H.263 or MPEG-4 video, and AMR Narrow-band speech, AMR wide- + band speech, or AAC audio, and 3GPP timed text. + + 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'. + + + + +Castagno & Singer Standards Track [Page 1] + +RFC 3839 MIME Type Registrations for 3GPP July 2004 + + + Files identified by the MIME [MIME1] type defined here MUST contain a + brand defined in a standard issued by 3GPP that can apply to 3GPP + files, in their compatible brands list. + + The MIME types defined here are needed to correctly identify such + files when they are served over HTTP, included in multi-part + documents, or used in other places where MIME types are used. + +2. Security Considerations + + The 3GPP 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 which 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 agreements based on World Intellectual Property + Organization (WIPO) treaties. + + 3GPP files have an extensible structure, so that it is theoretically + possible that metadata fields or media formats could be defined in + the future which could be used to induce particular actions on the + part of the recipient, thus presenting additional security risks. + However, this type of capability is currently not supported in the + referenced specification. + + There is no current provision in the standards for encryption, + signing, or authentication of these file formats. + +3. MIME Types + + This registration applies to all files defined as using the '3GP' + file format and identified with a suitable brand in a 3GPP + specification. The usual file suffix for all these files is ".3gp". + +3.1. Files with audio but no video + + The type "audio/3gpp" may be used for files containing audio but no + visual presentation (neither video nor timed text, for example). + + + + + +Castagno & Singer Standards Track [Page 2] + +RFC 3839 MIME Type Registrations for 3GPP July 2004 + + + To: ietf-types@iana.org + Subject: Registration of Standard MIME media type audio/3gpp + +MIME media type name: audio +MIME subtype name: 3gpp +Required parameters: none +Optional parameters: none + Ongoing work related to this + registration may introduce new + optional parameters. One example + area of effort may introduce a + parameter that would allow for + codecs in use within the MIME type + to be asserted and determined + without examination of the file. + Those with interests in the area + should monitor registrations for + updates. +Encoding considerations: files are 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 AMR audio + [RFC3267]. +Security considerations: see the security considerations + section in RFC 3839 +Interoperability considerations: The 3GPP organization has defined the + specification, interoperability, and + conformance, and conducts regular + interoperability testing. +Published specification: 3GPP 26.234, Release 5; 3GPP 26.244, + Release 6 or later. 3GPP + specifications are publicly + accessible at the 3GPP web site, + www.3gpp.org. +Applications which use this media type: Multi-media +Additional information: The type "audio/3gpp" 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 to be visual + material). + + + +Castagno & Singer Standards Track [Page 3] + +RFC 3839 MIME Type Registrations for 3GPP July 2004 + + +Magic number(s): None. However, the file-type box + must occur first in the file, and + MUST contain a 3GPP brand in its + compatible brands list. +File extension(s): 3gp and 3gpp are both declared at + http://www.nist.gov/nics/; 3gp is + preferred +Macintosh File Type Code(s): '3gpp' +Person & email address to contact for further information: + Nokia MIME manager, mime@nokia.com +Intended usage: COMMON +Change controller: 3GPP + +3.2. Any files + + The type "video/3gpp" is valid for all files. It is valid to serve + an audio-only file as "video/3gpp". + + To: ietf-types@iana.org + Subject: Registration of Standard MIME media type video/3gpp + +MIME media type name: video +MIME subtype name: 3gpp +Required parameters: none +Optional parameters: none +Encoding considerations: files are 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 AMR audio + [RFC3267]. +Security considerations: see the security considerations + section in RFC 3839 +Interoperability considerations: The 3GPP organization has defined the + specification, interoperability, and + conformance, and conducts regular + interoperability testing. +Published specification: 3GPP 26.234, Release 5; 3GPP 26.244, + Release 6 or later. 3GPP + specifications are publicly + accessible at the 3GPP web site, + www.3gpp.org. +Applications which use this media type: Multi-media + + + +Castagno & Singer Standards Track [Page 4] + +RFC 3839 MIME Type Registrations for 3GPP July 2004 + + +Additional information: +Magic number(s): None. However, the file-type box + must occur first in the file, and + MUST contain a 3GPP brand in its + compatible brands list. +File extension(s): 3gp and 3gpp are both declared at + http://www.nist.gov/nics/; 3gp is + preferred +Macintosh File Type Code(s): '3gpp' +Person & email address to contact for further information: + Nokia MIME manager, mime@nokia.com +Intended usage: COMMON +Change controller: 3GPP + +4. IANA Considerations + + This document registers the MIME types audio/3gpp and video/3gpp, + defined above. + +5. Acknowledgments + + The review of the 3GPP SA4 committee is gratefully acknowledged, in + particular Per Frojdh. The chairs of the AVT working group, in + particular Colin Perkins, have provided both excellent guidance and + feedback, for which the authors are grateful. + +6. References + +6.1. Normative References + + [3GPP] Published specifications in releases 5 and 6: Release 5: + 3GPP TS 26.234: Transparent end-to-end packet switched + streaming service (PSS); Protocols and codecs. Release 6: + 3GPP TS 26.244: Transparent end-to-end packet switched + streaming service (PSS); 3GPP file format (3GP) + + [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. + + + + + + + + + +Castagno & Singer Standards Track [Page 5] + +RFC 3839 MIME Type Registrations for 3GPP July 2004 + + +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. + + [RFC3267] Sjoberg, J., Westerlund, M., Lakaniemi, A. and Q. Xie, + "Real-Time Transport Protocol (RTP) Payload Format and File + Storage Format for the Adaptive Multi-Rate (AMR) and + Adaptive Multi-Rate WideBand (AMR-WB) Audio Codecs", RFC + 3267, June 2002. + +7. Authors' Contact Information + + Roberto Castagno + Nokia Mobile Phones + PO Box 88, FIN-33721 Tampere + (Tieteenkatu 1, FIN-33720 Tampere) + Finland + + Phone: +358 7180 35796 + EMail: roberto.castagno@nokia.com + + + David Singer + Apple Computer, Inc. + One Infinite Loop, MS:302-3MT + Cupertino CA 95014 + USA + + Phone: +1 408 974 3162 + EMail: singer@apple.com + + + + + + + + + + + + + + + + + + +Castagno & Singer Standards Track [Page 6] + +RFC 3839 MIME Type Registrations for 3GPP July 2004 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (2004). 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 currently provided by the + Internet Society. + + + + + + + + + +Castagno & Singer Standards Track [Page 7] + -- cgit v1.2.3