Network Working Group P. Hoschka INTERNET DRAFT W3C draft-hoschka-smil-media-type-05.txt October 2000 The application/smil Media Type Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies the Media Type for version 1 of the Synchronized Multimedia Integration Language (SMIL 1.0). SMIL allows integrating a set of independent multimedia objects into a synchronized multimedia presentation. 1. Introduction The World Wide Web Consortium has issued a Recommendation [1], which defines version 1 of the Synchronized Multimedia Integration Language (SMIL 1.0). This memo provides information about the application/smil Media Type. The definition is based on the RFC defining the use of the "application/xml" media type [3]. Before using the "application/smil" media type, implementors must thus be familiar with [3]. 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 SMIL is defined using XML [2], and the definition of the SMIL media type is based on the defintion of XML media types [3]. 3. Registration Information To: ietf-types@iana.org Subject: Registration of MIME media type application/smil MIME media type name: application MIME subtype name: smil Required parameters: none Optional parameters: charset All of the considerations for "application/xml" media type [3] also apply to the SMIL media type. The relevant paragraphs are copied below for convenience: Although listed as an optional parameter, the use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the character encoding of the XML entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP. "UTF-8" [RFC-2279] is the recommended value, representing the UTF-8 charset. UTF-8 is supported by all conforming XML processors [REC-XML]. If the XML entity is transmitted via HTTP, which uses a MIME-like mechanism that is exempt from the restrictions on the text top- level type (see section 19.4.1 of HTTP 1.1 [RFC-2068]), "UTF-16" (Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646]) is also recommended. UTF-16 is supported by all conforming XML processors [REC-XML]. Since the handling of CR, LF and NUL for text types in most MIME applications would cause undesired transformations of individual octets in UTF-16 multi-octet characters, gateways from HTTP to these MIME applications MUST transform the XML entity from a text/xml; charset="utf-16" to application/xml; charset="utf-16". Conformant with [RFC-2046], if a text/xml entity is received with the charset parameter omitted, MIME processors and XML processors MUST use the default charset value of "us-ascii". In cases where the XML entity is transmitted via HTTP, the default charset value is still "us-ascii". Since the charset parameter is authoritative, the charset is not always declared within an XML encoding declaration. Thus, special care is needed when the recipient strips the MIME header and provides persistent storage of the received XML entity (e.g., in a file system). Unless the charset is UTF-8 or UTF-16, the recipient SHOULD also persistently store information about the charset, perhaps by embedding a correct XML encoding declaration within the XML entityAlthough listed as an optional parameter, the use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the charset of the XML entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP. "UTF-8" [RFC-2279] and "UTF-16" (Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646]) are the recommended values, representing the UTF-8 and UTF-16 charsets, respectively. These charsets are preferred since they are supported by all conforming XML processors [REC-XML]. If an application/xml entity is received where the charset parameter is omitted, no information is being provided about the charset by the MIME Content-Type header. Conforming XML processors MUST follow the requirements in section 4.3.3 of [REC-XML] which directly address this contingency. However, MIME processors which are not XML processors should not assume a default charset if the charset parameter is omitted from an application/xml entity. Since the charset parameter is authoritative, the charset is not always declared within an XML encoding declaration. Thus, special care is needed when the recipient strips the MIME header and provides persistent storage of the received XML entity (e.g., in a file system). Unless the charset is UTF-8 or UTF-16, the recipient SHOULD also persistently store information about the charset, perhaps by embedding a correct XML encoding declaration within the XML entity. Encoding considerations: All of the considerations for "application/xml" media type [3] also apply to the SMIL media type. The relevant paragraphs are copied below for convenience: This media type MAY be encoded as appropriate for the charset and the capabilities of the underlying MIME transport. For 7-bit transports, data in both UTF-8 and UTF-16 is encoded in quoted- printable or base64. For 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64 encoded. For binary clean transport (e.g., HTTP), no content- transfer-encoding is necessary. Security considerations: SMIL documents contain a construct that allows "infinite loops". This is indispensible 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, ...) 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. In addition, SMIL has some of the same security considerations as specified in [3], with the following exceptions: the section on XML entities does not apply, since SMIL 1.0 disallows entities. 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] Applications which use this media type: SMIL players and editors Additional information: Semantics of fragment identifiers in URIs: The SMIL media type allows to append a fragment identifier to a URI pointing to a SMIL resource (e.g. http://www.example.com/test.smil#foo). The semantics of fragment identifers for SMIL resources are defined in [1]. Magic number(s): none All of the considerations for "application/xml" media type [3] also apply to the SMIL media type. 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 strongly recommended not to use the extension ".smi" for storing SMIL files on these platforms. Macintosh File Type Code(s): "TEXT", ".SMI", "SMIL", "PNRM" Object Identifier(s) or OID(s): none Person & email address to contact for further information: The author of this memo. Intended usage: COMMON Author/Change controller: The SMIL 1.0 specification is a work product of the World Wide Web Consortium's SYMM Working Group, and was edited by: Philipp Hoschka (ph@w3.org) The W3C has change control over the SMIL 1.0 specification. 5. 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] "Extensible Markup Language (XML) 1.0", W3C Recommendation REC-xml-19980210, http://www.w3.org/TR/REC-xml/, February 1998. [3] E. J. Whitehead Jr., M. Murata. "XML Media Types", RFC 2376, UC Irvine, Fuji Xerox Info. Systems, July 1998. 6. Author's Address Philipp Hoschka W3C/INRIA 2004, route des Lucioles - B.P. 93 06902 Sophia Antipolis Cedex FRANCE Phone: +33 (0)492387984 Fax:+33 (0)493657765 EMail: ph@w3.org