summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4536.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4536.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4536.txt')
-rw-r--r--doc/rfc/rfc4536.txt451
1 files changed, 451 insertions, 0 deletions
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]
+