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

Kurt D. Zeilenga wrote:

>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.
>
I think we do need to be clear on the definitions.  I assumed that a 
state based system would store some historical state information. 
 That's one of the implicit assumptions of the LCUP draft.

It is definitely not the intention of the authors of LCUP that the 
server has to store any histories of content updates.  That is in fact 
stated pretty clearly in the document.  If there is some wording in the 
document that suggests otherwise, I'd like to know about it and remove 
it/change it.

>>>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?
>
Yes.  A state based system can store historical state.  One of the 
assumptions of LCUP is that the server already has some sort of 
underlying historical information storage model, like a log or a 
state-based system with historical information.

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

>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.
>
But I don't want to force implementations to have to send every single 
entry in the LCUP context for every sync session, either the full entry 
(or at least the requested set of attributes) or just the DN.  I just 
don't think that approach will scale and I think it will be more 
unpopular than having to store some historical information.

>
>Kurt 
>
>  
>