Subject: RE: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 2 Jun 2005 20:13:31 -0700

The word "MUST" promotes interop, the word "SHOULD" does not really (for
me). Using your own argument, we should be strict for the sender, a
"MUST" seems to do that.

You have not convinced me that the word "SHOULD" should be used.
-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Altman
Sent: Thursday, June 02, 2005 6:57 PM
Cc: [email-masked]
Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry:

If you say the server MUST do X, then the client can be programmed
to assume the server is going to do X.   If you say the server SHOULD do
X, then the client will have to be programmed to expect not X.

Please change the MUST to a SHOULD.

Jeffrey Altman

Liqiang(Larry) Zhu wrote:
>  The draft does not ask the client to fail if the responses are not
> ordered. It only asks something trivial to the sender in order to make
> it easier for the receiver to pick up the responses.
> 
> -- Larry

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 03 Jun 2005 12:10:35 -0400

> me). Using your own argument, we should be strict for the sender, a

I would note that the words "MUST" and "SHOULD" as used in this context are 
requirements language, NOT plain English.  I would suggest that folks who 
are unsure as to their meanings consult RFC2119 for their precise 
definitions.

Jeff is correct - if the server is REQUIRED to behave in a certain way, 
then the implication (unless otherwise specified) is that clients may 
assume the server will behave that way, and may fail to interoperate if the 
server fails to do so.  On the other hand, if the spec says the server 
SHOULD do something, then the client might choose to optimize for that 
case, but also must be prepared to handle the case where the server does 
something else instead.

> it easier for the receiver to pick up the responses.

Your proposal doesn't "ask" the server to order responses; it REQUIRES it.
And in so doing, it doesn't "ask" the client to fail if the responses are 
not ordered, but it does _permit_ it.

I do not yet see a consensus on this issue.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Jun 2005 11:44:14 -0500

> case, but also must be prepared to handle the case where the server does 

Right, one MUST at least is needed.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Jun 2005 15:34:24 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> I do not yet see a consensus on this issue.

I support Larry's text at a minimum.  I wonder whether we should try
and go beyond that text and say that the responses should be ordered.
I suspect that writing that text would be challenging because of cases
where a response covers multiple certs or where responses are not
provided for all certs.