Anders,
1) Is a personal opinion and I kind of agree then again I'm not saying their
specs are better written they just look nicer. I think the point of the
simple format was a universal acceptance and that we should dazzle them
brilliance and not baffle them with BS. I wouldn't mind if the IETF chose
another format, but then again I'm going to pick to not fight that battle.
2) I agree that is a fact of life. Further I think it's a fact that
sometimes implementers will make design decisions that are not in the spec
that may or may not lead to interoperability.
On your original point of helping implementers figure out what's standard
and what's not really ought to be rephrased as what's in the standard and
what is the defacto/implemented standard. The idea of the standardization
process was to get working code and then move through the RFC track:
proposed, draft, and then internet. I see folks getting a proposed standard
RFC and popping the bubbly and never returning. We need to get working code
in bake-offs and then mode the standards accordingly, assuming the intent is
that they actually move beyond the stages. As usual I think the process is
fine it's the operator error that's causing all the problems.
spt
-----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 Anders Rundgren
Sent: Tuesday, October 17, 2006 1:51 AM
To: Blake Ramsdell; Ned Freed
Cc: Russ Housley; ietf-smime(_at_)imc(_dot_)org
Subject: Re: Fwd: The state of PKI-related MIME-type standards
There are many issues here that explains the situation.
1. Not all folks intend to publish their thing as an I-D which is hardly
surprising since I-Ds are ugly compared to for example OASIS documents.
2. Some people are not prepared to publish details on stuff that is still in
an early phase. Right or wrong but this is a fact.
3. If you want to assign XML name-spaces in the IETF tree you need an RFC
number. But you cannot get an RFC number without having an RFC. The
current solution is to purchase a domain and use that as name-space.
I actually tried to define an IANA DNS RR type but it was rejected as the
documentation was in PDF and the DNS community did not approve as well since
it was about putting XML in the DNS which BTW is already a de-facto standard
but they feared that making it a "real" standard would be bad.
Anders
----- Original Message -----
From: "Ned Freed" <ned(_dot_)freed(_at_)mrochek(_dot_)com>
To: "Blake Ramsdell" <blake(_at_)sendmail(_dot_)com>
Cc: "Russ Housley" <housley(_at_)vigilsec(_dot_)com>;
<ietf-smime(_at_)imc(_dot_)org>;
<anders(_dot_)rundgren(_at_)telia(_dot_)com>
Sent: Tuesday, October 17, 2006 03:24
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.
This is indeed the right approach. x- is in retrospect a bad idea.
And I'm not sure that this is compatible with MIME type procedure.
I know of no conflict with current procedures. If you're going after a
standards tree type, simply write your draft using the name you want. There
has
never been a case of a conflict - it isn't like the type namespace is so
tiny
that there's appreciable risk of someone steaking your type name out from
under
you.
If, OTOH, you want a type in the vendor or personal tree, nothing prevents
you from registering these as soon as you come up with the name.
I imagine that this has been
discussed before in the MIME community, but I personally don't know how
it came out.
I don't know of any specific discussion, which makes me think that this
has become a nonissue.
Ned