[xiph-commits] r13796 - experimental/ivo/drafts

ivo at svn.xiph.org ivo at svn.xiph.org
Thu Sep 13 16:05:16 PDT 2007


Author: ivo
Date: 2007-09-13 16:05:16 -0700 (Thu, 13 Sep 2007)
New Revision: 13796

Removed:
   experimental/ivo/drafts/rfcxxxx.txt
Log:
I thought I had deleted this older file already

Deleted: experimental/ivo/drafts/rfcxxxx.txt
===================================================================
--- experimental/ivo/drafts/rfcxxxx.txt	2007-09-13 23:04:31 UTC (rev 13795)
+++ experimental/ivo/drafts/rfcxxxx.txt	2007-09-13 23:05:16 UTC (rev 13796)
@@ -1,573 +0,0 @@
-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