Subject: Comments on lcup-05

From: John McMeeking <[email-masked]>
Date: Fri, 6 Jun 2003 15:00:38 -0500

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

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

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.

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.4.1 Server Initiated Termination.  This para references a
lcupClientDisconnected resultCode.  I didn't see that resultCode defined.

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.

John  McMeeking

---

From: [email-masked] (Mark C Smith)
Date: Mon, 09 Jun 2003 10:54:52 -0400

> state information about deleted or moved/renamed entries."

That sounds like an improvement to me.

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

> This would make it more consistent with 4.2.6.

Good catch.

> "lcupInvalidAttribute" or "unwillingToPerform" resultCode would be

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.

> lcupClientDisconnected resultCode.  I didn't see that resultCode defined.

I think that should be replaced with the canceled response code from 
zeilenga-ldap-cancel.

> 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