RE: Use of criticality in dupent-04

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Harald,

I think your example is somewhat at odds with the philosophy of LDAP. All
server replies SHOULD be intelligible. The one exception is the use of
;binary. If the control you mention were to exist, it would have to be
defined in RFC 2251 so that ALL clients would know to expect it.

The only reasonable(TM) alternative is that the response control is sent in
response to a particular request control. This would indicate that the
client can understand the control.

However, there seems to be little motivation for the idea of a critical
response control. The only example (on this list) that came close was the
example of a client requesting replication updates from a server. The need
there was to flag deletes. Two comments on this are: 1) the response control
would be intelligible because the client requested a non-standard
(non-LDAP!) operation, and 2) even here the criticality of the response
control was successfully argued against on the list (d.w.c?).

Ron.

-----Original Message-----
From: Harald Alvestrand [mailto:Harald@Alvestrand.no]
Sent: Tuesday, 1 August 2000 20:44
To: Rich Salz; d.w.chadwick@salford.ac.uk
Cc: Bruce Greenblatt; ietf-ldapext@netscape.com
Subject: Re: Use of criticality in dupent-04


At 10:16 30/07/2000 -0400, Rich Salz wrote:
>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.

another typical case would be "these data are incomprehensible if you don't 
understand this control" - for instance if we (horror!) were to define a 
control for tagging returned text as being Shift-JIS encoded instead of
UTF-8.

The server can't force the client to do anything special, but can give 
appropriate warning that results are likely to be incomprehensible, and the 
only appropriate action on the client's side may be presenting an "upgrade 
your software?" message to the unhappy user.

                 Harald

--
Harald Tveit Alvestrand, alvestrand@cisco.com
+47 41 44 29 94
Personal email: Harald@Alvestrand.no