[Top] [All Lists]

RE: Fwd: The state of PKI-related MIME-type standards

2006-10-13 07:09:18

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 
facilitating evolution.


-----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 
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 Ramsdell | Sendmail, Inc. |