[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Use of criticality in dupent-04
Date forwarded: Fri, 28 Jul 2000 13:59:15 -0700 (PDT)
From: "Mircea Pana" <mpana@nortelnetworks.com>
>
> 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
> 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:bgreenblatt@directory-applications.com] Sent: Friday, July
> > 28, 2000 4:05 PM To: d.w.chadwick@salford.ac.uk; 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.
> >
> >
>
***************************************************
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 D.W.Chadwick@salford.ac.uk
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
***************************************************