Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt

At 10:33 AM 3/10/2003, John Merrells wrote:
>Hmm. I can't resist dipping into this thread.
>>The most obvious problems are with the requests for content
>>refresh.
>>
>>Without historical information, 
>In a state-based system the state records the history.

When I referred to a "state-based" system, I hoped it was
obvious that I was referring to a system which maintained
the current state of directory and meta information but
did not maintain historical state information, in particular
histories of state and/or content updates.  If this was
unclear, I apologize.

>>a server has no means to
>>determine whether or not an entry whose state indicates it was
>>updated (add,modify,rename) since the previous refresh
>>request has left the content.  It can only determine whether
>>the updated entry is currently in the content or not.  The
>>server must assume the entry was previously in the content.
>>Hence, the server must generate a message (update or entryLeft)
>>for each updated entry in the context or require a reload.
>A state-based system can record the deleted/left entires in its state.

I do not view such a system as being a state-based system.
I view it as a log-based system.   Do we need to more precisely
defined these terms?

>>But worse, if any entry was deleted from the context, a
>>server which maintains no historical information is forced
>>to respond that a reload is required.
>Too bad. The server implementation is up to the server implementor.

I disagree.  Every technical specifications limit implementation
approaches to those which can produce conformant implementations.
However, standard track technical specifications should avoid
placing undue constraints on implementation details.

Here I believe, as the author clarified, it was not/is not the
intent of the authors to preclude a state-based implementation
approach.  My follow-up message serves only to elaborate on why I
believe the technical specification does preclude state-based
implementation approaches.

It is possible that the authors misunderstood my initial question
in this thread.  If so, I assume they will post a clarification.

>The server can store no state, some state, or all state.

I believe that LCUP should be designed such that implementors may
choose whether to pursue a state-based or a log-based approach
(or, possibly, some hybrid approach).  I am attempting to demonstrate
how the current specification precludes the state-base (e.g., no
history) approach.

Kurt