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

From: Blake Ramsdell <[email-masked]>
Date: Thu, 12 Oct 2006 20:32:55 -0700

>> From: "Anders Rundgren" <[email-masked]>
>> To: <[email-masked]>
>> 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

---

From: "Kemp David P." <[email-masked]>
Date: Fri, 13 Oct 2006 09:41:44 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Blake Ramsdell
Sent: Thursday, October 12, 2006 11:33 PM
To: Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: Fwd: The state of PKI-related MIME-type standards

Blake

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 15 Oct 2006 11:09:19 +0200

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:
http://www.identityblog.com/?page_id=412

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.

Anders

----- Original Message -----
From: "Kemp David P." <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>; "Russ Housley" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, October 13, 2006 15:41
Subject: RE: Fwd: The state of PKI-related MIME-type standards

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Blake Ramsdell
Sent: Thursday, October 12, 2006 11:33 PM
To: Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: Fwd: The state of PKI-related MIME-type standards

Blake

---

From: Ned Freed <[email-masked]>
Date: Mon, 16 Oct 2006 18:24:04 -0700 (PDT)

> 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

I don't know of any specific discussion, which makes me think that this
has become a nonissue.

				Ned

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 17 Oct 2006 07:50:33 +0200

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" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 17, 2006 03:24
Subject: Re: Fwd: The state of PKI-related MIME-type standards

Ned

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 17 Oct 2006 12:43:36 -0400

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Rundgren
Sent: Tuesday, October 17, 2006 1:51 AM
To: Blake Ramsdell; Ned Freed
Cc: Russ Housley; [email-masked]
Subject: Re: Fwd: The state of PKI-related MIME-type standards

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" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, October 17, 2006 03:24
Subject: Re: Fwd: The state of PKI-related MIME-type standards

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.

Ned