ietf-smime
[Top] [All Lists]

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

2006-10-16 23:39:57

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