Subject: LCUP applicability

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 05 May 2003 18:55:28 -0700

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

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

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.
I'll post a more detailed discussion of this in a separate
message at a later time.

Kurt

---

From: [email-masked] (Rich Megginson)
Date: Tue, 06 May 2003 09:02:57 -0600

Kurt D. Zeilenga wrote:

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

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

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

---

From: "Chris Apple" <[email-masked]>
Date: Fri, 23 May 2003 12:00:38 -0400

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:[email-masked]

http://www.dsi-consulting.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rich Megginson
Sent: Tuesday, May 06, 2003 11:03 AM
To: Kurt D. Zeilenga
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: LCUP applicability

No problem here.

No problem here.

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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 May 2003 08:50:05 -0700

I content that the I-D has not been updated to discuss
applicability.  That is, it has been updated to discuss
which applications are well suited to it and which are
not, and why.  The updates are mainly highlight implementation
constraints, and while useful, are not quite the same thing.

The applicability statement exercise purpose, I thought,
was to focus some the problem both I-Ds report to solve
and their suitability of each of the solutions.  To that
purpose, we still have a long way to go.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Tue, 27 May 2003 08:42:35 -0400

Note from the Co-Chair: I consider this issue to be worth discussing
regardless of the request from Kurt relating to the pending WG Last
Call initiation for LCUP. It will need to be resolved regardless of
the outcome of the WG considering his request.

Kurt,

One way of characterizing the problem(s) technology is intended
to solve is by including discussion about applications for which
that technology is a good (or a bad) solution.

That is clearly *one* way of documenting applicability. It has been
the most common way of doing so in many engineering documents I've
encountered in the past.

So far, its not clear what this particular disagreement is about.

Can you provide a few references for applicability statements
that are more like those you would prefer to see in the LCUP
document?

DSI Consulting, Inc.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Monday, May 26, 2003 11:50 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: LCUP applicability

Kurt