[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&#231;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