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