[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on lcup-05

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature