draft-hoschka-smil-media-type-12.txt

[Larry Masinter]

I think the document should explain why it is that it registers
both application/smil and application/smil+xml with exactly
the same meaning.

I think the answer is likely that this was a mistake, that
application/smil+xml is recommended, but that 'application/smil'
is in use in some parts of the community already, and it was
thought better to register it as a valid alias.
But I'm not sure; I'm not even sure it's a good idea
to do this.  Perhaps we want to separate out 'recommended'
practice (as you would find in an IESG approved document
or a W3C 'Recommendation') from some other kind of registration,
e.g., ask IANA to register 'application/smil' with a notation
"MIME type used for what is officially registered as
application/smil+xml'.


> The definition is based on RFC3023 defining the use of the
>   "application/xml" media type [3]. Before using the "application/smil"
>   or "application/smil+xml" media type, implementors must thus be
>   familiar with [3].

As far as I can tell, [3] has nothing to say about 'application/smil'.

>   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+smil MIME type
>   registration [4], and is motivated by very similar considerations.

Presumably you mean xhtml+xml, not xhtml+smil.  Is there any
positive experience using media type parameters in content 
negotiation, in general, or in particular with "profile" with
xhtml+xml, and not using, say, media features?

> It is suggested that the "profile" parameter be
> used until the CC/PP protocol work has been finalized.

By whom would this parameter be used?