I would prefer to keep the MIME type the same, but add words that clarify
the processing. I see no reason to assign a second MIME type for the same
thing.
Russ
At 07:25 PM 7/15/2002 -0700, Blake Ramsdell wrote:
----- Original Message -----
From: "Jim Schaad" <jimsch(_at_)nwlink(_dot_)com>
To: <ietf-smime(_at_)imc(_dot_)org>; "'Blake Ramsdell'"
<blake(_at_)brutesquadlabs(_dot_)com>
Sent: Monday, July 15, 2002 7:22 PM
Subject: Change from "cert-only" in RFC2633-bis-01
> Blake,
>
> I think that there may be a major problem in making this change.
>
> Issues:
> 1. You need to have a backwards compability section describing what the
> old "certs-only" smime-type is and what it does.
From draft-ietf-smime-rfc2633bis-01.txt section 3.6:
Please note that in prior versions of S/MIME, the smime-type parameter
was set to "certs-only" for messages that contained only certificates
and/or certificate revocation lists. The new use of "cert-management"
is meant to clarify the semantic that both certificates and
certificate revocation lists might be found in these messages.
Receiving implementations SHOULD accept "certs-only" and
"cert-management" and treat them equivalently (that is, both could
contain certificates and/or certificate revocation lists).
Please let me know what other clarification would be useful here -- indeed
this is something to be careful of if we change this smime-type.
> 2. I dislike the term cert-management, because you are not doing
> certificate managmement. A better term would be cert-distribution.
And I'll further complain that "it distributes CRLs as well as
certs". This might end up being an interesting rathole. Well,
"interesting" as far as ratholes go, that is ;).
> Personally I have no problem with leaving this smime-type as is.
Me neither. Maybe this should change back to "certs-only" and we focus on
clarifying the generation / processing of the data rather than changing
the smime-type.
Blake