Subject: Change from "cert-only" in RFC2633-bis-01

From: "Jim Schaad" <[email-masked]>
Date: Tue, 16 Jul 2002 11:22:47 +0900

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.
2.  I dislike the term cert-management, because you are not doing
certificate managmement.  A better term would be cert-distribution.

Personally I have no problem with leaving this smime-type as is.

Jim

---

From: "Blake Ramsdell" <[email-masked]>
Date: Mon, 15 Jul 2002 19:25:22 -0700

----- Original Message ----- 
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>; "'Blake Ramsdell'" <[email-masked]>
Sent: Monday, July 15, 2002 7:22 PM
Subject: Change from "cert-only" in RFC2633-bis-01

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

> 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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Jul 2002 09:15:11 +0900

Blake,

I have just noticed in doing some re-writes on the CMC draft in the PKIX
group that it also refers to "certs-only".  I don't know if there are
other RFC's that might also do this.  I think that this might be a good
reason to revert back.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Blake Ramsdell
> Sent: Tuesday, July 16, 2002 11:25 AM
> To: [email-masked]; [email-masked]
> Subject: Re: Change from "cert-only" in RFC2633-bis-01
> 
> 
> 
> 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.
> 
> 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 ;).
> 
> 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
>

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 17 Jul 2002 01:53:47 -0400

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:

>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.
>
>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 ;).
>
>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