From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc4536.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 451 insertions(+)
 create mode 100644 doc/rfc/rfc4536.txt

(limited to 'doc/rfc/rfc4536.txt')

diff --git a/doc/rfc/rfc4536.txt b/doc/rfc/rfc4536.txt
new file mode 100644
index 0000000..232add9
--- /dev/null
+++ b/doc/rfc/rfc4536.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         P. Hoschka
+Request for Comments: 4536                                           W3C
+Category: Informational                                         May 2006
+
+
+       The application/smil and application/smil+xml 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 (2006).
+
+Abstract
+
+   This document specifies the media type for versions 1.0, 2.0, and 2.1
+   of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL
+   2.0, SMIL 2.1).  SMIL allows integration of a set of independent
+   multimedia objects into a synchronized multimedia presentation.
+
+1.  Introduction
+
+   The World Wide Web Consortium (W3C) has issued specifications that
+   define versions 1.0 [1], 2.0 [2] and 2.1 [3] of the Synchronized
+   Multimedia Integration Language (SMIL).  This memo provides
+   information about the application/smil and application/smil+xml media
+   types.
+
+   The definition is based on RFC 3023, which defines the use of the
+   "application/xml" media type [4].  Before using the
+   "application/smil" or "application/smil+xml" media type, implementors
+   must thus be familiar with [4].
+
+2.  Synchronized Multimedia Integration Language
+
+   SMIL allows integrating a set of independent multimedia objects into
+   a synchronized multimedia presentation.  Using SMIL, an author can
+
+   1. describe the temporal behavior of the presentation,
+   2. describe the layout of the presentation on a screen,
+   3. associate hyperlinks with media objects, and
+   4. define conditional content inclusion/exclusion based on
+      system/network properties.
+
+
+
+
+Hoschka                      Informational                      [Page 1]
+
+RFC 4536       application/smil and application/smil+xml        May 2006
+
+
+3.  Registration Information
+
+3.1.  Registration of MIME media type application/smil
+
+   MIME media type name: application
+
+   MIME subtype name: smil
+
+   Required parameters: none
+
+   Optional parameters:
+
+      charset
+
+         Same as charset parameter considerations of application/xml in
+         RFC 3023.
+
+      profile
+
+         See Section 5 of this document.
+
+   Encoding considerations:
+
+      Same as encoding considerations of application/xml in RFC 3023
+
+   Security considerations: See Section 6, "Security Considerations", of
+   this document.
+
+   Interoperability considerations:
+
+      SMIL documents contain links to other media objects.  The SMIL
+      player must be able to decode the media types of these media in
+      order to display the whole document.  To increase
+      interoperability, SMIL has provisions for including alternate
+      versions of a media object in a document.
+
+   Published specification: See [1], [2], and [3]
+
+   Applications which use this media type:
+
+      SMIL players and editors
+
+
+
+
+
+
+
+
+
+
+Hoschka                      Informational                      [Page 2]
+
+RFC 4536       application/smil and application/smil+xml        May 2006
+
+
+   Additional information:
+
+      Semantics of fragment identifiers in URIs: The SMIL media type
+      allows a fragment identifier to be appended to a URI pointing to a
+      SMIL resource (e.g., http://www.example.com/test.smil#foo).  The
+      semantics of fragment identifiers for SMIL resources are defined
+      in the SMIL specification.
+
+   Magic number(s):
+
+      There is no single initial byte sequence that is always present
+      for SMIL files.  However, Section 4 of this document gives some
+      guidelines for recognizing SMIL files.
+
+   File extension(s): .smil, .smi, .sml
+
+   NOTE: On the Windows operating system and the Macintosh platform, the
+   ".smi" extension is used by other formats.  To avoid conflicts, it is
+   thus recommended to use the extension ".smil" for storing SMIL files
+   on these platforms.
+
+   Macintosh File Type Code(s): "TEXT", ".SMI", "SMIL"
+
+   Object Identifier(s) or OID(s): none
+
+   Person & email address to contact for further information:
+
+   The author of this memo.
+
+   Intended usage: OBSOLETE
+
+   Author/Change controller:
+
+   The SMIL specification is a work product of the World Wide Web
+   Consortium's SYMM Working Group.
+
+   The W3C has change control over the specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoschka                      Informational                      [Page 3]
+
+RFC 4536       application/smil and application/smil+xml        May 2006
+
+
+3.2.  Registration of MIME media type application/smil+xml
+
+   MIME media type name: application
+
+   MIME subtype name: smil+xml
+
+   Required parameters: See registration of application/smil.
+
+   Optional parameters: See registration of application/smil.
+
+   Encoding considerations: See registration of application/smil.
+
+   Security considerations: See Section 6, "Security Considerations", of
+   this document
+
+   Interoperability considerations: See registration of
+   application/smil.
+
+   Published specification: See registration of application/smil.
+
+   Applications which use this media type: See registration of
+   application/smil.
+
+   Additional information: See registration of application/smil.
+
+   Magic number(s): See registration of application/smil.
+
+   File extension(s): See registration of application/smil.
+
+   Macintosh File Type Code(s): See registration of application/smil.
+
+   Object Identifier(s) or OID(s): See registration of application/smil.
+
+   Person & email address to contact for further information: See
+   registration of application/smil.
+
+   Intended usage: COMMON
+
+   Author/Change controller: See registration of application/smil.
+
+
+
+
+
+
+
+
+
+
+
+
+Hoschka                      Informational                      [Page 4]
+
+RFC 4536       application/smil and application/smil+xml        May 2006
+
+
+4.  Recognizing SMIL Files
+
+   All SMIL files will have the string "<smil" near the beginning of the
+   file.  Some will also begin with an XML declaration that begins with
+   "<?xml", though that alone does not indicate a SMIL document.
+
+   All SMIL 2.0 files must include a declaration of the SMIL 2.0
+   namespace.  This should appear shortly after the string "<smil", and
+   should read 'xmlns="http://www.w3.org/2001/SMIL20/Language"'.
+
+   All SMIL 2.1 files must include a declaration of a SMIL 2.1
+   namespace, appearing shortly after the string "<smil".  The namespace
+   string depends on the language profile.  Please refer to the SMIL 2.1
+   specification for the definition of the relevant namespace names.
+
+5.  The "profile" Optional Parameter
+
+   This parameter is meant to be used in MIME media-type-based content
+   negotiation (such as that done with the HTTP "Accept" header) to
+   negotiate for a variety of SMIL-based languages.  It is modelled
+   after the "profile" parameter in the application/xhtml+xml MIME type
+   registration [5] and is motivated by very similar considerations.
+
+   The parameter is intended to be used only during content negotiation.
+   It is not expected that it be used to deliver content, or that origin
+   web servers have any knowledge of it (though they are welcome to).
+   It is primarily targeted for use on the network by proxies in the
+   HTTP chain that manipulate data formats (such as transcoders).
+
+   The value of the profile attribute is a URI that can be used as a
+   name to identify a language.  Though the URI need not be resolved in
+   order to be useful as a name, it could be a namespace, schema, or
+   language specification.
+
+   For example, user agents supporting only SMIL Basic (see
+   http://www.w3.org/TR/smil20/smil-basic.html) currently have no
+   standard means to convey their inability to fully support SMIL 2.0.
+   While SMIL 2.0 Basic user agents are required to parse the full SMIL
+   2.0 language, there is potentially a substantial burden in receiving
+   and parsing document content that will not be presented to the user,
+   since its functionality is not included in SMIL Basic.
+
+   In the future, the functionality afforded by this parameter will also
+   be achievable by the emerging work on a protocol to transfer
+   Composite Capability/Preferences Profiles (CC/PP) descriptions [6].
+   It is suggested that the "profile" parameter be used until the CC/PP
+   protocol work has been finalized.
+
+
+
+
+Hoschka                      Informational                      [Page 5]
+
+RFC 4536       application/smil and application/smil+xml        May 2006
+
+
+   An example use of this parameter as part of a HTTP GET transaction
+   would be:
+
+        Accept: application/smil+xml;
+           profile="http://www.w3.org/2001/SMIL20/HostLanguage"
+
+6.  Security Considerations
+
+   SMIL documents contain a construct that allows "infinite loops".
+   This is indispensable for a multimedia format.  However, SMIL clients
+   should foresee provisions such as a "stop" button that lets users
+   interrupt such an "infinite loop".
+
+   As with HTML, SMIL documents contain links to other media (images,
+   sounds, videos, text, etc.), and those links are typically followed
+   automatically by software, resulting in the transfer of files without
+   the explicit request of the user for each one.  The security
+   considerations of each linked file are those of the individual
+   registered types.
+
+   The SMIL language contains "switch" elements.  SMIL provides no
+   mechanism that ensures that the media objects contained in a "switch"
+   element provide equivalent information.  An author knowing that one
+   SMIL player will display one alternative of a "switch" and another
+   will display a different part can put different information in the
+   two parts.  While there are legitimate use cases for this, it also
+   gives rise to a security consideration: The author can fool viewers
+   into thinking that the same information was displayed when in fact it
+   was not.
+
+   In addition, all of the security considerations of RFC 3023 also
+   apply to SMIL.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoschka                      Informational                      [Page 6]
+
+RFC 4536       application/smil and application/smil+xml        May 2006
+
+
+7.  Normative References
+
+   [1]  "Synchronized Multimedia Integration Language (SMIL) 1.0
+        Specification", W3C Recommendation REC-smil-19980615,
+        http://www.w3.org/TR/1998/REC-smil/, July 1998.
+
+   [2] "Synchronized Multimedia Integration Language (SMIL 2.0) -
+        [Second Edition]", W3C Recommendation,
+        http://www.w3.org/TR/2005/REC-SMIL2-20050107/, January 2005.
+
+   [3] "Synchronized Multimedia Integration Language (SMIL 2.1)", W3C
+        Recommendation, http://www.w3.org/TR/2005/REC-SMIL2-20051213/,
+        December 2005.
+
+   [4]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC
+        3023, January 2001.
+
+8.  Informative References
+
+   [5]  Baker, M. and P. Stark, "The 'application/xhtml+xml' Media
+        Type", RFC 3236, January 2002.
+
+   [6]  H. Ohto, J. Hjelm, G. Klyne, M. Butler, L. Tran, F. Reynolds, C.
+        Woodrow "Composite Capability/Preferences Profiles (CC/PP):
+        Structure and Vocabularies 1.0", W3C Recommendation
+        http://www.w3.org/TR/CCPP-struct-vocab/, January 2004.
+
+Author's Address
+
+   Philipp Hoschka
+   W3C/ERCIM
+   2004, route des Lucioles - B.P. 93
+   06902 Sophia Antipolis Cedex
+   FRANCE
+
+   EMail: ph@w3.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoschka                      Informational                      [Page 7]
+
+RFC 4536       application/smil and application/smil+xml        May 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).
+
+
+
+
+
+
+
+Hoschka                      Informational                      [Page 8]
+
-- 
cgit v1.2.3