Kurt, We'll be able to handle word-smithing during the WG Last Call for LCUP. However, with regard to this particular thread, I don't see support on the mailing list for your position that the applicability statement language is unclear. I therefore must conclude that the WG doesn't agree with your position and consider this particular issue closed unless reopened by other WG members during the upcoming LCUP WG Last Call. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@xxxxxxxxxxxxxxxxxx http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@xxxxxxxxxxxx [mailto:owner-ietf-ldup@xxxxxxxxxxxx] On Behalf Of Rich Megginson Sent: Tuesday, May 06, 2003 11:03 AM To: Kurt D. Zeilenga Cc: ietf-ldup@xxxxxxx; mcs@xxxxxxxxxxxx; olgan@xxxxxxxxxxxxx; jeffparh@xxxxxxxxxxxxxxxxxxxxx; richm@xxxxxxxxxxxx Subject: Re: LCUP applicability Kurt D. Zeilenga wrote: >LCUP's applicability statement, I think, needs a bit of work. >The "will work best" phrase, I find a bit odd, seems these >are more "design assumptions". > I'm not sure what the difference is between an "applicability statement" and a "design assumption", but isn't that the whole point of the section anyway? To provide suggestions to implementers about what types of server and client applications are best suited for LCUP? I don't see a problem here. >Anyways... > >The first item implies that LCUP "works" when the server >maintains no historical information. It should be clear, >that without historical information, the server can only >determine that change occurred since the time indicated by >the cookie, not what that change was. Hence, only if there >were no changes in the context, the could the server could respond >successfully. In any change occurred in the context, the >server would have to fail with lcupReloadRequired. > Well, that is "working". Some definition of "working" is that the client does a full resync every time (or does nothing, if there is nothing to do). I think the statement in LCUP is pretty clear without going so far as to "bash potential implementers over the head with implementation details". No problem here. >The second item says the client is not assumed to understand >the "physical information model" implemented by the >server, however it provides as instances of the physical >model "virtual attributes, operational attributes, [and]subentries". I think the authors meant LCUP assumes >only knowledge of the "directory user information model" >[X.501(93)]. > I think the wording is pretty clear and easy to understand as it is. The document provides as instances those items to provide clarity within the context without requiring the reader of the document to refer to other documents just to get an idea of what is being referred to here. >Anyways, I think LCUP does require the >client to understand directory administrative and >operational models in certain areas. For example, as >LCUP doesn't support alias dereferencing during searching, >a user client desiring aliases objects has to understand >alias objects. > Right. This particular "exception to the rule" was discussed a long time by the LDAP community, and it was decided that this particular exception was worthy of inclusion in LCUP. >I assume it does so to reduce complexity. >There are other cases where assuming or requiring client >knowledge of aspects of select administrative and operational >models would significant reduce complexity and/or chattiness. > Then the implementer can either choose to accept LCUP with its "chattiness in certan cases" or reject LCUP in favor of another approach. No problem here. >With regard to the third item, I think LCUP has significant >problems dealing with a number of everyday DIT update >situations and forces full reloads far too frequently. > Those situations are explicitly listed in the LCUP document, and the document lists the reasons that LCUP chose to handle them in the way it did. No problem here. >I'll post a more detailed discussion of this in a separate >message at a later time. > I look forward to reading it. But what will be different than what we have already discussed at great length in the past? Have you found several other new situations that you didn't know about 2 months ago? The point is that implementers can choose to accept these conditions or not. At least they are explicitly spelled out in LCUP near the beginning. >Kurt > > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature