Thanks for your comments John.|
John McMeeking wrote:
Here is the text I decided to use, which is very similar to yours: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."
"... 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."
Could you (or someone else) give me an example of what the ASN.1 should look like?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).
Done.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.
Here is the new text of 4.3.4 and 4.3.5: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.
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.
Changed to "canceled [CANCEL]".4.4.1 Server Initiated Termination. This para references a lcupClientDisconnected resultCode. I didn't see that resultCode defined.
I would like to get rid of this, or at least not require this section for Last Call.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.
Description: S/MIME Cryptographic Signature