RFC 4536

The application/smil and application/smil+xml Media Types

πŸ“… published July 2006, from ietf

Part 1 of 2 πŸŽ€

okay bestie, this is RFC 4536 and it's literally a whole vibe πŸ’– It's from the Network Working Group, it's Request for Comments: 4536, written by P. Hoschka at W3C, filed under Category: Informational, and dated May 2006. The header doesn't list anything it obsoletes or updates, so that's a blank πŸ™ˆ

Status of This Memo ✨

ngl this part is kinda chill. This memo is just here to give info to the Internet community πŸ¦‹ It's not a standard, it doesn't specify an Internet standard of any kind, and anyone's free to share it with zero restrictions.

Copyright (C) The Internet Society (2006).

Abstract πŸ¦‹

okay so this document defines the media type for SMIL versions 1.0, 2.0, and 2.1 (that's Synchronized Multimedia Integration Language, SMIL 1.0, SMIL 2.0, SMIL 2.1) 🎬 SMIL is how you take a bunch of separate multimedia objects and get them playing together as one synchronized presentation. Iconic πŸ‘‘

1. Introduction 🌸

So the World Wide Web Consortium (W3C) put out specs for SMIL 1.0 [1], SMIL 2.0 [2], and SMIL 2.1 [3]. This memo is basically the info sheet for the application/smil and application/smil+xml media types πŸ“„

The whole definition is built on RFC 3023, which is the one that defines the "application/xml" media type [4]. So before you touch "application/smil" or "application/smil+xml", implementors must thus be familiar with [4]. No skipping homework, bestie πŸ“š

2. Synchronized Multimedia Integration Language πŸŽ€

SMIL lets you put a set of independent multimedia objects together into one synchronized multimedia presentation. With 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 🧠.

It's giving full creative control, periodt πŸ’…

3. Registration Information 🧚

3.1. Registration of MIME media type application/smil πŸ’–

Here's the registration template for application/smil, bestie, let's go through it πŸ‘€

  • MIME media type name: application
  • MIME subtype name: smil
  • Required parameters: none
  • Optional parameters:
    • charset: same as the charset parameter considerations of application/xml in RFC 3023.
    • profile: see Section 5 of this document.
  • Encoding considerations: same as the encoding considerations of application/xml in RFC 3023.
  • Security considerations: see Section 6, "Security Considerations", of this document.
  • Interoperability considerations: SMIL documents link to other media objects, and the SMIL player has to be able to decode the media types of those in order to display the whole document 🎞️ To keep things smooth, 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 ✨
  • Additional information: The SMIL media type lets you append a fragment identifier to a URI that points at a SMIL resource (for example, http://www.example.com/test.smil#foo) πŸ” The meaning of fragment identifiers for SMIL resources is defined in the SMIL specification.
  • Magic number(s): There's no single initial byte sequence that's always there for SMIL files. Section 4 of this document does give some guidelines for recognizing SMIL files, though πŸ•΅οΈβ€β™€οΈ
  • File extension(s): .smil, .smi, .sml
  • NOTE: On the Windows operating system and the Macintosh platform, the .smi extension is already used by other formats 😭 So to avoid conflicts, it is thus recommended to use the extension .smil for storing SMIL files on these platforms. Protect your files, bestie πŸ›‘οΈ
  • 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 πŸ† and the W3C has change control over the specification.

3.2. Registration of MIME media type application/smil+xml πŸ¦‹

This one's the sibling registration, and most of it just points back to application/smil, so it's super easy πŸ₯°

  • 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.

Intellectual Property ✨

okay so the IETF is NOT picking a side here πŸ™…β€β™€οΈ It takes no position on whether any intellectual property rights (IPR) that someone might claim over the tech in this doc are valid, or how far they reach. It also doesn't say whether a license for those rights might or might not be available. And it hasn't gone hunting for any such rights itself πŸ•΅οΈ If you want the full rules on rights in RFC documents, check out BCP 78 and BCP 79 πŸ’…

Copies of IPR disclosures sent to the IETF Secretariat are a thing πŸ“„ So are assurances of licenses that might be made available, and the results of anyone trying to get a general license or permission to use those proprietary rights as an implementer or user of this spec. You can grab all of that from the IETF online IPR repository at http://www.ietf.org/ipr πŸ”

And the IETF totally invites anyone to speak up πŸ“£ If you know about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard, tell them at ietf-ipr@ietf.org 🫢

Acknowledgement

The RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) πŸ’–

πŸ“¦ where this page comes from