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?