Although interesting I don't see anything in this that would make
the situation regarding the 3280 AIA CaIssuers a clear-cut case.
The editors as far as I can tell have to chose between:
1. Ignoring the since 7Y+ firmly established methods This is
the current proposal which (if followed) would with high
certainty break the majority of systems out there including
one of the editors' own.
2. Documenting the established practice (de-facto standard)
which indeed is a viable option since neither the 3280 nor its
predecessor mentioned anything regarding MIME types.
3. In some way combining the wanted scheme with
the existing scheme. If I were to do such a "combo",
I would go for a somewhat slimy method were I would
only refer to certificate-using software (consumers) and
say nothing about producers.
Since there is no way you can register a MIME type or other
IANA object without an RFC, I still don't see how you could
actually begin testing software in early incarnations (except for
in your own lab) without using an "x-" or "vnd." extension. But
as soon as you have put your stuff outside of the lab, it is by
definition as standard. At least if you are Microsoft.
This is MSFT's latest s.c. "violation" of IETF rules and principles:
The "offending" line:
<OBJECT type="application/x-informationCard" name="xmlToken">
Those who claim that this is a solved problem, have probably not
[recently] tried establishing an open, Internet-scale solution where
early-access software is downloaded by millions of unknown, and
non-paying parties, and where there may be dozens of competing
implementations as well.
----- Original Message -----
From: "Kemp David P." <DPKemp(_at_)missi(_dot_)ncsc(_dot_)mil>
To: "Blake Ramsdell" <blake(_at_)sendmail(_dot_)com>; "Russ Housley"
Sent: Friday, October 13, 2006 15:41
Subject: RE: Fwd: The state of PKI-related MIME-type standards
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
The path of standards evolution is well-trodden, and x- MIME types
are not only a non-problem, they are an accepted mechanism for
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Blake
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>
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
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 Ramsdell | Sendmail, Inc. | http://www.sendmail.com