This issue is not specific to either MIME types or the IANA process -
software standards have evolved ever since standards existed. The last
time the IETF declared a "flag day" (where everyone had to change
implementation simultaneously in order to continue to function)
was the switchover from Arpanet to Internet.
Since then, the IETF evolution mantra has been "strict emission,
liberal acceptance". Ideally, the RFC defining a standard MIME type
would declare that compliant applications MUST NOT emit the x- form
of that type (having been preceded by proposed and draft standards
that telegraphed the transition in advance.) Since two interoperable
implementations are required to advance an RFC to standard, it shouldn't
be naïve to expect other implementations to have followed by the time
the RFC reaches standard. Even in a non-ideal world, the standard should
say "MUST NOT" emit x- (rather than SHOULD NOT), and implementations
are still free to support non-compliant options if necessary
to deal with retrograde applications. Even with complex standards
like HTML, the existence of 4.01 (strict) and 4.01-TRANSITIONAL
(bug-compliant) rendering permits orderly evolution of browser
capabilities.
The path of standards evolution is well-trodden, and x- MIME types
are not only a non-problem, they are an accepted mechanism for
facilitating evolution.
Dave
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Blake
Ramsdell
Sent: Thursday, October 12, 2006 11:33 PM
To: Russ Housley
Cc: ietf-smime(_at_)imc(_dot_)org; anders(_dot_)rundgren(_at_)telia(_dot_)com
Subject: Re: Fwd: The state of PKI-related MIME-type standards
From: "Anders Rundgren" <anders(_dot_)rundgren(_at_)telia(_dot_)com>
To: <ietf-pkix(_at_)imc(_dot_)org>
Subject: The state of PKI-related MIME-type standards
Date: Wed, 27 Sep 2006 00:18:26 +0200
Regarding "right" schemes, it appears that the IANA process is
incompatible with the development situation since you cannot get a
name without having an RFC and then your development gets stuck in a
process you have no control over. Due to this you must "begin" with
an x- extension that (if your stuff is successful), will be impossible
to replace since you have no control of the other implementations.
And there you is ;-|
It's been ten years and best practice is "accept both x-pkcs7-signature
and pkcs7-signature" (repeat for the other MIME types defined in the MSG
RFC) today, as evidenced by two mainstream clients (at least one of
which I don't think even existed during the x-pkcs7-signature days) that
emit this.
So as "a group that uses MIME types" I'm not sure what we can do. If we
open the MSG RFC again, we can clarify that some people use X- and
however naughty that is, you MUST accept it. But then again,
contemporary clients MUST NOT emit it. But then again, some (out of
spec) clients might ONLY accept that version... Yaaa.
As a somewhat MIME-specific observation, the only way I can see to avoid
this is to never, ever rename your MIME type, which might mean never
ever have an X- version of your MIME type. And I'm not sure that this is
compatible with MIME type procedure. I imagine that this has been
discussed before in the MIME community, but I personally don't know how
it came out.
Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com