Subject: RE: Use of criticality in dupent-04

From: "Mircea Pana" <[email-masked]>
Date: Fri, 28 Jul 2000 16:50:47 -0400

I'd say that if a response operation has a control and the client does not
understand it  then:
a) if the control is critical then the client SHOULD NOT make use of this
response or (obviously) the associated control 
b) if the control is not critical then the client MAY use the response and
discard the control.

If the client doesn't understand the control it will not make use of it -
true, but the criticality is an indication to whether or not the server
recommends the utilization of the response in case the control is not
understood.

For example:
LCUP [should] makes use of criticality in the entryUpdate controls attached
to SearchResultEntries to mark deleted entries:
"   In response to the client's synchronization request, the server
   returns a set of SearchResultEntries that fits the client's
   specification. To represent a deleted entry, the server attaches an
   entryUpdate control to the corresponding SearchResultEntry. The
   SearchResultEntry corresponding to a deleted entry MUST contain a
   valid DN and a valid uniqueid but, to reduce the amount of data sent
   to the client, it SHOULD not contain any other attributes."

Mircea.

> -----Original Message-----
> From: Bruce Greenblatt [mailto:[email-masked]]
> Sent: Friday, July 28, 2000 4:05 PM
> To: [email-masked]; Jim Sermersheim; ietf-ldapext;
> d.w.chadwick
> Subject: Re: Use of criticality in dupent-04
> 
> 
> 
> >
> > > 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
> 
> 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:17:00 +0100

Date forwarded: 	Fri, 28 Jul 2000 13:59:15 -0700 (PDT)
From:           	"Mircea Pana" <[email-masked]>

> 
> For example:
> LCUP [should] makes use of criticality in the entryUpdate controls
> attached to SearchResultEntries to mark deleted entries:

So if the client does not understand the deleted control and it is not 
marked critical, it will ignore the control and will update its copy with 
a set of zero attributes (which is almost a deleted entry :-). If the 
control is critical, what should the client do, ignore the SearchResult 
and leave its copy of the deleted entry with all its attributes? And if 
it does understand the control (regardless of criticality) it will delete 
the entry copy, which is the intended result. So criticality serves 
little purpose, doesn't it? And certainly not the intended purpose of 
"ignore my request if you dont understand this and take no action 
please", since the delete has already been carried out by the server.

David

> "   In
> response to the client's synchronization request, the server
>    valid DN and a valid uniqueid but, to reduce the amount of data
>    sent to the client, it SHOULD not contain any other attributes."
> 
> Mircea.
> 
> 
> 
> > From: Bruce Greenblatt
> > [mailto:[email-masked]] Sent: Friday, July
> > 28, 2000 4:05 PM To: [email-masked]; Jim Sermersheim;
> > ietf-ldapext; d.w.chadwick Subject: Re: Use of criticality in
> > dupent-04
> > 
> > 
> > 
> > >
> > > > 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
> > 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.
> > 
> > 
> 

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

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

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