Re: Separate LCUP cookie vs replication - was RE: Comments on LCUP draft - opaque cookie

Christopher Apple wrote:
>
> The general answer to your question is that not specifying
> at least one standards-track cookie format means that
> LCUP interoperability will only be achieved if a few
> implementers decide to cooperate to make it happen. Even
> *if* that happens, it may or may not last beyond
> version 1.0 of the implementations themselves...
> 
> As a WG Co-Chair, that's a situation I can't justify
> letting us get into without some very compelling reasons.
> 
> So far, I've heard no arguments that I consider compelling
> enough to outweigh the risk to interoperability that
> an opaque cookie poses. 

Consider these two scenarios:

1) Vendor A's LCUP client synchronizes (perhaps repeatedly) with vendor
B's LCUP server implementation.  Interoperability is achieved if the
cookie format is opaque or if the client and the server both implement a
common cookie format.

2) Vendor A's LCUP client synchronizes with vendor B's LCUP server. 
Later, the same client tries to synchronize using the same search
criteria with vendor C's LCUP server (presumably vendor C's server holds
a replica of the content).  If server B and C both support the same
cookie format, the LCUP session with server C will ideally be an
incremental synchronization.  If a common cookie format is not supported
or used by the two servers, the synchronization session with server C
will have to be a full synchronization.

Note that scenario 1 argues for defining an opaque cookie format while
scenario 2 argues for exposing the contents of the cookie format (likely
based on the replication model used by the two servers, e.g., LDUP).


> I am definitely OK with the approach of specifying a high-level
> cookie structure of "<OID>-<payload>" in the LCUP spec itself
> and dealing with the issue of publishing one or more OIDs with
> associated payload syntaxes that are standards track.
> 
> This approach is outlined here:
> 
> http://www.imc.org/ietf-ldup/mail-archive/msg01079.html

This approach has been adopted by the LCUP document authors.  A new I-D
will be published very soon.

-Mark Smith
 Netscape