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

It seem like the log-based vs state-based distinctions may not be necessary
if we borrow some ideas from LDUP.

LDUP has the notion that deleted entries be maintained by the server for
some period of time.  A client search never returns these entries, but the
server keeps knowledge that the entry with UUID 'x-uuid' was deleted at
time 'x-deleted-time'.  This could be implemented using a log (search log
for deleted entries) or state (meta-data).  LDUP doesn't care (though at
some level it starts to be awfully hard to be state/log based agnostic).

If a cookie has some sort of time information, then a server can:
- find entries that have been added (createTimestamp attribute or
equivalent)
- find entries that have been modified (modifyTimestamp or equivalent)
- find entries that have been deleted (delete timestamp described above)

Modify DN presents problems.  Perhaps we could add a superior timestamp
(new superior) and RDN timestamp (rename).  Not knowing where the entry
came from, all modify DN operations (with appropriate time) would be
treated as "entered result set" if they are now in the result set, and as
"left result set" if they are not now in the result set.

I think modify would not follow the letter of the draft.  Any change to an
entry would have to be treated as a change to the attributes the client was
interested in.  But I don't think that should cause problems, unless there
are a lot of these changes relative to changes the client is really
interested in (whatever "a lot" is).

A server probably wouldn't want to keep deleted entry state information
around forever.  A server implementation should be able to prune this --
could be as arbitrary as discarding deleted entry information after a fixed
period.  Any LCUP cookie that corresponded to a time prior to this period
would require a resync.  Deletes should be relatively infrequent, so it
should be possible for this time period to be fairly long.

Assuming everyone views this as appropriate state information, a log-based
implementation is not required.  I doubt LCUP needs to say any of this, but
maybe others think such "hints" are appropriate.


John  McMeeking



                                                                                                                                 
                      "Kurt D.                                                                                                   
                      Zeilenga"                To:       John Merrells <[email protected]>                                  
                      <[email protected]        cc:       Rich Megginson <[email protected]>, [email protected]                  
                      g>                       Subject:  Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt                              
                      Sent by:                                                                                                   
                      owner-ietf-ldup@m                                                                                          
                      ail.imc.org                                                                                                
                                                                                                                                 
                                                                                                                                 
                      03/10/2003 01:18                                                                                           
                      PM                                                                                                         
                                                                                                                                 
                                                                                                                                 





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