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

["Kurt D. Zeilenga" <Kurt@xxxxxxxxxxxx>]

[resent to fix some nasty typos]

At 12:16 PM 3/10/2003, John McMeeking wrote:
>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)

Without additional historical information, the server however
would not, in general, be able to determine whether or not an
updated entry within the context was in the content at the time
indicated by the cookie.  The server must assume it was in the
content at the time indicated by the cookie and generate an
appropriate message to the client.

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

Yes.  Say the updated entry is within scope of the search but
currently doesn't match the search criteria.  Without additional
historical information, the server would not be able to determine
if the updated entry was in the content at the time indicated by
the cookie.  The server must assume it was in the content at the
time indicated by the cookie and generate an appropriate message
to the client.

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

The problem here is that the server is unable to determine
whether an updated entry in the CONTEXT was previously in the
CONTENT without additional historical information and hence
must assume that it was in the CONTENT at the time indicated
by the cookie.

That is, the problem severity is relative to the changes to
the CONTEXT not just to CONTENT.

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

Well, I thin that if we believe that certain implementation
approaches would lead to implementations which would do harm,
that we should state these beliefs and, where appropriate,
detail implementation-approach-neutral imperatives of what
behaviors are considered harmful.  Lack of "eventual convergence
data consistency" and/or "overly chattiness" would be harmful.

Kurt