Subject: Re: Comments on lcup-05

From: [email-masked] (Rich Megginson)
Date: Wed, 23 Jul 2003 14:29:10 -0600

Thanks for your comments John.

John McMeeking wrote:

>Here's some comments on draft-ietf-ldup-lcup-05.txt:
>
>1. Overview - paragraph on state information.  I would resatate this
>something like: "... the server does not need to maintain state information
>specific to individual clients.  The server may need to maintain additional
>state information about deleted or moved/renamed entries."
>
Here is the text I decided to use, which is very similar to yours:
"... the server does not need to maintain state information specific to 
individual clients.  The server may need to maintain additional state 
information about attribute modifications, deleted entries, and 
moved/renamed entries."

>3.5 (all controls).  All these controls have a significant number of
>optional fields.  I think we should add tags to simplify proper decoding of
>the control data.  Also, given recent discussions about ASN.1 tagging, it
>would be appropriate to state that implicit tagging is used (if it is).
>
Could you (or someone else) give me an example of what the ASN.1 should 
look like?

>4.2.7 Result for Entries that have left the result set.  There are two "An
>entry SHOULD be returned as having left...." clauses.  It appears the
>second one is left over from a rewrite, as it repeats information in 4.2.5.
>This would make it more consistent with 4.2.6.
>
Done.

>4.3.4/4.3.5.  I think the server should be given the option of rejecting a
>LCUP search that includes virtual or collective attributes.  If a server
>would normally return these attributes, it must either properly synchronize
>these attributes or reject the search request.  Maybe a new
>"lcupInvalidAttribute" or "unwillingToPerform" resultCode would be
>appropriate.
>
Here is the new text of 4.3.4 and 4.3.5:

4.3.4 Operational Attributes and Administrative Entries

An operational attribute SHOULD be returned if it is specified in the 
attributes list and would normally be returned as subject to the 
constraints of [RFC2251 Section 4.5].  If the server does not support 
syncing of operational attributes, the server MUST return a 
SearchResultDone message with a resultCode of unwillingToPerform.

LDAP Subentries [SUBENTRY] SHOULD be returned if they would normally be 
returned by the search request.  If the server does not support syncing 
of LDAP Subentries, and the server can determine from the search request 
that the client has requested LDAP Subentries to be returned (e.g. 
search control or search filter), the server MUST return a 
SearchResultDone message with a resultCode of unwillingToPerform.  
Otherwise, the server MAY simply omit returning LDAP Subentries.

4.3.5 Virtual Attributes 

An entry may have attributes whose presence in the entry, or presence of 
values of the attribute, is generated on the fly, possibly by some 
mechanism outside of the entry, elsewhere in the DIT.  An example of 
this is collective attributes [COLLECTIVE].  These attributes shall be 
referred to in this document as virtual attributes.

LCUP treats these attributes the same way as normal, non-virtual 
attributes.  A virtual attribute SHOULD be returned if it is specified 
in the attributes list and would normally be returned as subject to the 
constraints of [RFC2251 Section 4.5].  If the server does not support 
syncing of virtual attributes, the server MUST return a SearchResultDone 
message with a resultCode of unwillingToPerform. 

One consequence of this is that if you change the definition of a 
virtual attribute such that it makes the value of that attribute change 
in many entries in the client's search scope, this means that a server 
may have to return many entries to the client as a result of that one 
change.  It is not anticipated that this will be a frequent occurrence, 
and the server has the option to simply force the client to resync if 
necessary.

It is also possible that a future LDAP control will allow the client to 
request only virtual or only non-virtual attributes.

>4.4.1 Server Initiated Termination.  This para references a
>lcupClientDisconnected resultCode.  I didn't see that resultCode defined.
>
Changed to "canceled [CANCEL]".

>4.5  <What to do about this section????>  This can probably be deleted,
>though it might be helpful earlier to explain what the synchronize and
>persist phases do and the sequence of requests/controls.
>
I would like to get rid of this, or at least not require this section 
for Last Call.

>John  McMeeking