[xiph-commits] r13788 - experimental/ivo/drafts
ivo at svn.xiph.org
ivo at svn.xiph.org
Wed Sep 12 05:28:34 PDT 2007
Author: ivo
Date: 2007-09-12 05:28:33 -0700 (Wed, 12 Sep 2007)
New Revision: 13788
Added:
experimental/ivo/drafts/draft-xiph-rfc3534bis.txt
Log:
renaming per suggestion
Copied: experimental/ivo/drafts/draft-xiph-rfc3534bis.txt (from rev 13787, experimental/ivo/drafts/rfcxxxx.txt)
===================================================================
--- experimental/ivo/drafts/draft-xiph-rfc3534bis.txt (rev 0)
+++ experimental/ivo/drafts/draft-xiph-rfc3534bis.txt 2007-09-12 12:28:33 UTC (rev 13788)
@@ -0,0 +1,573 @@
+NOTICE: 56 lines x 73 characters per page; no RFC number yet
+
+
+
+
+
+Network Working Group Xiph.Org Foundation
+Request for Comments: xxxx September 2007
+Category: Informational
+
+
+ Ogg Multimedia Media Types
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2007).
+
+Abstract
+
+ This document describes the registration of media types for the
+ Ogg Multimedia container and conformance requirements for
+ implementations of these types.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conformance and Document Conventions ............................2
+ 3. Deployed Media Types and Compatibility ..........................2
+ 5. Security Considerations .........................................6
+ 6. IANA Considerations .............................................8
+ 7. Ogg Media Types .................................................9
+ 7.1. application/ogg ............................................9
+ 7.2. video/ogg .................................................10
+ 7.3. audio/ogg .................................................11
+ 9. References .....................................................13
+ 9.1. Normative References ......................................13
+ 9.2. Informative References ....................................13
+
+
+
+
+
+
+
+
+Xiph.Org Foundation Informational [Page 1]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+
+1. Introduction
+
+ This memo describes media types for the Ogg container format.
+ Refer to "Introduction" in [RFC3533] and "Overview" in [Ogg] for
+ background information on this multimedia container format.
+
+ Multimedia streams, such as Vorbis and Theora, have historically
+ been interchanged using the application/ogg media type as defined by
+ [RFC3534]. This document obsoletes [RFC3534] and defines three
+ media types for different multimedia streams in Ogg to reflect this
+ usage in the IANA media type registry, to foster interoperability by
+ defining underspecified aspects, and to provide general security
+ considerations.
+
+2. Conformance and Document Conventions
+
+ 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, [RFC2119] and
+ indicate requirement levels for compliant implementations.
+ Requirements apply to all implementations unless otherwise stated.
+
+ An implementation is a software module that supports one of the media
+ types defined in this document. Software modules may support
+ multiple media types, but conformance is considered individually for
+ each type.
+
+ Implementations that fail to satisfy one or more "MUST" requirements
+ are considered non-compliant. Implementations that satisfy all
+ "MUST" requirements, but fail to satisfy one or more "SHOULD"
+ requirements, are said to be "conditionally compliant". All other
+ implementations are "unconditionally compliant".
+
+3. Deployed Media Types and Compatibility
+
+ The application/ogg media type has been used in an ad-hoc fashion to
+ label and exchange multimedia content in Ogg containers.
+
+ Use of the "application" top-level type for this kind of content is
+ known to be problematic. This document thus defines application/ogg
+ but marks it for non-video, non-audio streams only.
+
+ The media types,
+
+ * video/ogg
+ * audio/ogg
+
+ which are also defined in this document, are intended for common use
+ and should be used when dealing with A/V streams.
+
+
+Xiph.Org Foundation Informational [Page 2]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+
+5. Security Considerations
+
+ Refer to [RFC3552] for a discussion of terminology used in this
+ section. Examples in this section and discussions of interactions of
+ host environments with scripts and extensions to [ECMA] are to be
+ understood as non-exhaustive and of a purely illustrative nature.
+
+ The programming language defined in [ECMA] is not intended to be
+ computationally self-sufficient, rather it is expected that the
+ computational environment provides facilities to programs to enable
+
+
+
+
+Xiph.Org Foundation Informational [Page 6]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+
+ specific functionality. Such facilities constitute unknown factors
+ and are thus considered out of the scope of this document.
+
+ Derived programming languages are permitted to include additional
+ functionality that is not described in [ECMA]; such functionality
+ constitutes an unknown factor and is thus considered out of the scope
+ of this document. In particular, extensions to [ECMA] defined for
+ the JavaScript programming language are not discussed in this
+ document.
+
+ Uncontrolled execution of scripts can be exceedingly dangerous.
+ Implementations that execute scripts MUST give consideration to their
+ application's threat models and those of the individual features they
+ implement; in particular, they MUST ensure that untrusted content is
+ not executed in an unprotected environment.
+
+ Specifications for host environment facilities and for derived
+ programming languages should include security considerations. If an
+ implementation supports such facilities, the respective security
+ considerations apply. In particular, if scripts can be referenced
+ from or included in specific document formats, the considerations for
+ the embedding or referencing document format apply.
+
+ For example, scripts embedded in application/xhtml+xml [RFC3236]
+ documents could be enabled through the host environment to manipulate
+ the document instance, which could cause the retrieval of remote
+ resources; security considerations regarding retrieval of remote
+ resources of the embedding document would apply in this case.
+
+ This circumstance can further be used to make information, that is
+ normally only available to the script, available to a web server by
+ encoding the information in the resource identifier of the resource,
+ which can further enable eavesdropping attacks. Implementation of
+ such facilities is subject to the security considerations of the host
+ environment, as discussed above.
+
+ The facilities defined in [ECMA] do not include provisions for input
+ of external data, output of computed results, or modification of
+ aspects of the host environment. An implementation of only the
+ facilities defined in [ECMA] is not considered to support dangerous
+ operations.
+
+ The programming language defined in [ECMA] does include facilities to
+ loop, cause computationally complex operations, or consume large
+ amounts of memory; this includes, but is not limited to, facilities
+ that allow dynamically generated source text to be executed (e.g.,
+ the eval() function); uncontrolled execution of such features can
+ cause denial of service, which implementations MUST protect against.
+
+
+
+Xiph.Org Foundation Informational [Page 7]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+
+ A host environment can provide facilities to access external input.
+ Scripts that pass such input to the eval() function or similar
+ language features can be vulnerable to code injection attacks.
+ Scripts are expected to protect against such attacks.
+
+ A host environment can provide facilities to output computed results
+ in a user-visible manner. For example, host environments supporting
+ a graphical user interface can provide facilities that enable scripts
+ to present certain messages to the user. Implementations MUST take
+ steps to avoid confusion of the origin of such messages. In general,
+ the security considerations for the host environment apply in such a
+ case as discussed above.
+
+ Implementations are required to support the UTF-8 character encoding
+ scheme; the security considerations of [RFC3629] apply. Additional
+ character encoding schemes may be supported; support for such schemes
+ is subject to the security considerations of those schemes.
+
+ Source text is expected to be in Unicode Normalization Form C.
+ Scripts and implementations MUST consider security implications of
+ unnormalized source text and data. For a detailed discussion of such
+ implications refer to the security considerations in [RFC3629].
+
+ Scripts can be executed in an environment that is vulnerable to code
+ injection attacks. For example, a CGI script [RFC3875] echoing user
+ input could allow the inclusion of untrusted scripts that could be
+ executed in an otherwise trusted environment. This threat scenario
+ is subject to security considerations that are out of the scope of
+ this document.
+
+ The "data" resource identifier scheme [RFC2397], in combination with
+ the types defined in this document, could be used to cause execution
+ of untrusted scripts through the inclusion of untrusted resource
+ identifiers in otherwise trusted content. Security considerations of
+ [RFC2397] apply.
+
+ Implementations can fail to implement a specific security model or
+ other means to prevent possibly dangerous operations. Such failure
+ could possibly be exploited to gain unauthorized access to a system
+ or sensitive information; such failure constitutes an unknown factor
+ and is thus considered out of the scope of this document.
+
+6. IANA Considerations
+
+ This document registers two new media types and modifies the existing
+ application/ogg as defined in the following section.
+
+
+
+
+
+Xiph.Org Foundation Informational [Page 8]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+
+7. Ogg Media Types
+
+7.1. application/ogg
+
+ Type name: application
+ Subtype name: ogg
+ Required parameters: none
+ Optional parameters: none
+ Encoding considerations: n/a
+
+ Security considerations: See section 5.
+ Interoperability considerations:
+ None, except as noted in other sections of this document.
+
+ Published specification: [Ogg]
+ Applications which use this media type:
+ Script interpreters as discussed in this document.
+
+ Additional information:
+
+ Magic number(s): The first four bytes, 0x4f 0x67 0x67
+ 0x53, correspond to the string OggS.
+ File extension(s): .ogx
+ Macintosh File Type Code(s): OggS
+
+ Person & email address to contact for further information:
+ See Authors' Addresses section.
+
+ Intended usage: COMMON
+ Restrictions on usage: n/a
+ Author: See Authors' Addresses section.
+ Change controller: The Xiph.Org Foundation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xiph.Org Foundation Informational [Page 9]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+
+7.2. video/ogg
+
+ Type name: video
+ Subtype name: ogg
+ Required parameters: none
+ Optional parameters: none
+ Encoding considerations: n/a
+
+ Security considerations: See section 5.
+ Interoperability considerations:
+ None, except as noted in other sections of this document.
+
+ Published specification: [Ogg]
+ Applications which use this media type:
+ Script interpreters as discussed in this document.
+
+ Additional information:
+
+ Magic number(s): The first four bytes, 0x4f 0x67 0x67
+ 0x53, correspond to the string OggS.
+ File extension(s): .ogv
+ Macintosh File Type Code(s): OggS
+
+ Person & email address to contact for further information:
+ See Authors' Addresses section.
+
+ Intended usage: COMMON
+ Restrictions on usage: n/a
+ Author: See Authors' Addresses section.
+ Change controller: The Xiph.Org Foundation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xiph.Org Foundation Informational [Page 10]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+
+7.3. audio/ogg
+
+ Type name: audio
+ Subtype name: ogg
+ Required parameters: none
+ Optional parameters: none
+ Encoding considerations: n/a
+
+ Security considerations: See section 5.
+ Interoperability considerations:
+ None, except as noted in other sections of this document.
+
+ Published specification: [Ogg]
+ Applications which use this media type:
+ Script interpreters as discussed in this document.
+
+ Additional information:
+
+ Magic number(s): The first four bytes, 0x4f 0x67 0x67
+ 0x53, correspond to the string OggS.
+ File extension(s): .oga
+ Macintosh File Type Code(s): OggS
+
+ Person & email address to contact for further information:
+ See Authors' Addresses section.
+
+ Intended usage: COMMON
+ Restrictions on usage: n/a
+ Author: See Authors' Addresses section.
+ Change controller: The Xiph.Org Foundation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xiph.Org Foundation Informational [Page 11]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+9. References
+
+9.1. Normative References
+
+ [CHARSETS] IANA, "Assigned character sets",
+ <http://www.iana.org/assignments/character-sets>.
+
+ [ECMA] European Computer Manufacturers Association,
+ "ECMAScript Language Specification 3rd Edition",
+ December 1999, <http://www.ecma-international.org/
+ publications/standards/Ecma-262.htm>
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
+ Procedures", BCP 19, RFC 2978, October 2000.
+
+ [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
+ Types", RFC 3023, January 2001.
+
+ [RFC3536] Hoffman, P., "Terminology Used in Internationalization
+ in the IETF", RFC 3536, May 2003.
+
+ [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing
+ RFC Text on Security Considerations", BCP 72, RFC
+ 3552, July 2003.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+9.2. Informative References
+
+ [E4X] European Computer Manufacturers Association,
+ "ECMAScript for XML (E4X)", June 2004,
+ <http://www.ecma-international.org/
+ publications/standards/Ecma-357.htm>
+
+ [EcmaCompact] European Computer Manufacturers Association,
+ "ECMAScript 3rd Edition Compact Profile", June 2001,
+ <http://www.ecma-international.org/
+ publications/standards/Ecma-327.htm>
+
+ [JS15] Netscape Communications Corp., "Core JavaScript
+ Reference 1.5", September 2000,
+ <http://web.archive.org/*/http://
+ devedge.netscape.com/library/manuals/2000
+ /javascript/1.5/reference/>.
+
+
+
+Xiph.Org Foundation Informational [Page 13]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+
+ [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
+ August 1998.
+
+ [RFC3236] Baker, M. and P. Stark, "The 'application/xhtml+xml'
+ Media Type", RFC 3236, January 2002.
+
+ [RFC3875] Robinson, D. and K. Coar, "The Common Gateway
+ Interface (CGI) Version 1.1", RFC 3875, October 2004.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC3987] Duerst, M. and M. Suignard, "Internationalized
+ Resource Identifiers (IRIs)", RFC 3987, January 2005.
+
+Authors' Addresses
+
+ Ivo Emanuel Goncalves
+ EMail: ivo at xiph.org
+ URI: http://spreadopenmedia.org
+ Note: Please write "Goncalves" with c-cedilla (U+00E7) wherever
+ possible, e.g., as "Ivo Emanuel Gonçalves" in HTML and XML.
+
+ Add your name here if you are contributing to the RFC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xiph.Org Foundation Informational [Page 14]
+
+RFC xxxx Ogg Multimedia Media Types September 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2007).
+
+ 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.
+
+ The author(s) agree to grant third parties the irrevocable right to
+ copy, use and distribute the work, with or without modification, in
+ any medium, without royalty, provided that, unless separate
+ permission is granted, redistributed modified works do not contain
+ misleading author, version, name of work, or endorsement information.
+
+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 at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Xiph.Org Foundation Informational [Page 15]
More information about the commits
mailing list