Re: Comments on lcup-05

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."

That sounds like an improvement to me.


> 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).

I don't have a problem with adding tags, although whether that really 
simplifies decoding of optional elements might depend on what kind of 
BER decoder you have... having tags might make things more bulletproof 
though.


> 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.

Good catch.


> 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.

It is important to encourage server implementors to support 
synchronization of virtual attributes. The problem I see is that if we 
allow servers to reject such requests, clients will be completely out of 
luck. I think this change requires more discussion.



> 4.4.1 Server Initiated Termination.  This para references a
> lcupClientDisconnected resultCode.  I didn't see that resultCode defined.

I think that should be replaced with the canceled response code from 
zeilenga-ldap-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.

Agreed. I think I advised Rich to remove section 4.5. Not sure why that 
did not happen... an oversight I suspect.

Thanks for your detailed comments!

-Mark