Subject: Re: Use of criticality in dupent-04

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 26 Jul 2000 01:09:47 -0600

I wouldn't mind removing this, but... 2251 is ambiguous in this area. If 2251 were to state that the criticality field is only valid and checked in requests, and ignored for responses, I'd feel more comfortable. Note also that there are a number of other drafts that have the same language (see SSS and VLV).

Jim

>>> "David Chadwick" <[email-masked]> 7/23/00 12:18:07 PM >>>
Jim

In your ID you mention the use of the criticality field in a control 
response. e.g    criticality is FALSE (MAY be absent). 

In fact, RFC2251 says nothing about the use of the criticality field in a 
response. The functionality has been lifted from X.500(93) and criticality 
only has meaning in a request sent to a server. I suggest you remove the text 
about criticality in a response.

David
***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked] 
Home Page  http://www.salford.ac.uk/its024/chadwick.htm 
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm 
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm 
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "David Chadwick" <[email-masked]>
Date: Fri, 28 Jul 2000 19:07:56 +0100

Date forwarded: 	Wed, 26 Jul 2000 00:11:06 -0700 (PDT)
Date sent:      	Wed, 26 Jul 2000 01:09:47 -0600
From:           	"Jim Sermersheim" <[email-masked]>
To:             	<[email-masked]>, <[email-masked]>
Subject:        	Re: Use of criticality in dupent-04
Forwarded by:   	[email-masked]

> I wouldn't mind removing this, but... 2251 is ambiguous in this area.
> If 2251 were to state that the criticality field is only valid and
> checked in requests, and ignored for responses, I'd feel more
> comfortable. Note also that there are a number of other drafts that
> have the same language (see SSS and VLV).

Yep - they are wrong as well. Seems like you all copied from each 
other

David

David Chadwick

---

From: Bruce Greenblatt <[email-masked]>
Date: Fri, 28 Jul 2000 13:04:52 -0700

>Yep - they are wrong as well. Seems like you all copied from each

Are you saying that it is not allowed to put a criticality field in a 
control that appears in an operation response?  This certainly seems to 
make sense.  The LDAP client has already received the result of the 
operation.  It doesn't really seem to matter at that point whether the 
control in the response was critical or not.  If the client doesn't 
understand the control, it won't make use of it in either case.  If the 
client does understand the control, it doesn't matter what the criticality 
is either.  RFC 2251 should definitely say that criticality in controls 
that come back to the client in a response can be safely ignored.

---

From: "David Chadwick" <[email-masked]>
Date: Sun, 30 Jul 2000 13:16:59 +0100

> control that appears in an operation response?  This certainly seems
> to make sense.  The LDAP client has already received the result of the
> understand the control, it won't make use of it in either case.  If
> the client does understand the control, it doesn't matter what the
> criticality is either.  RFC 2251 should definitely say that
> criticality in controls that come back to the client in a response can
> be safely ignored.

I believe this is the case at the moment with all existing RFCs and 
IDs, and is compatible with X.500.

However, we might (only might note, I am not suggesting it) want to 
consider the case for the future, that if the client and server go into 
a prolonged dialogue, where the client must reply to the server and 
must do something that the server is asking, then the client acts on 
the criticality flag and says "sorry cant do" to the server if the client 
does not understand a critical control. But really in this case the 
client is no longer a client but a peer, isn't it?

David

David Chadwick

---

From: Rich Salz <[email-masked]>
Date: Sun, 30 Jul 2000 10:16:18 -0400

I think it's more likely that a repository must want to include a critical
control in its response that allows it to "disclaim" some of its data.  For
example, "these search results are not to be used for spam," "i cannot vouch
for the content you'll get when you follow these referrals," etc.