Subject: RE: Separate LCUP cookie vs replication - was RE: Comments on LCU P draft - opaque cookie

From: Christopher Apple <[email-masked]>
Date: Fri, 6 Jul 2001 10:23:57 -0400

>-----Original Message-----
   >From: Kurt D. Zeilenga [mailto:[email-masked]]
   >Sent: Friday, July 06, 2001 12:03 AM
   >To: [email-masked]
   >Cc: Christopher Apple; 'Richard Huber'; [email-masked];
   >[email-masked]
   >Subject: Re: Separate LCUP cookie vs replication - was RE: 
   >Comments on
   >LCUP draft - opaque cookie
   >
   >
   >At 12:55 PM 6/12/2001, John Strassner wrote:
   >>if you agree that the format of the cookie isn't the real 
   >issue, then
   >>let's please separate that into two discussions:
   >>
   >>  1) the format of the cookie
   >>  2) whether LCUP will support replicated environments
   >
   >In the absence of support for replicated environments,
   >is there a reason to specify the format of the cookie?
   >
   >Kurt
   >

See my posting related to interoperability concerns that don't
necessarily have anything to do with a replicated environment:

http://www.imc.org/ietf-ldup/mail-archive/msg01067.html

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.

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

Chris Apple
Program Manager - Directory Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email-masked]> 
(V) 610-425-2860

---

From: [email-masked] (Mark C Smith)
Date: Fri, 06 Jul 2001 11:14:59 -0400

> enough to outweigh the risk to interoperability that

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

> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Jul 2001 08:19:07 -0700

Well, my concern is that by labeling a value (the cookie)
which the client should not care about will lead to
interoperability problems as clients will start caring
about a label which shouldn't matter.  As the value of
the cookie matters to the protocol peer which generated
it, the label seems quite pointless to me.  However, as
long as there is language added to the text stating that
the label is irrelevant to the clients implementing this
specification, I can live with it.

Kurt

---

From: [email-masked] (Rich Megginson)
Date: Fri, 06 Jul 2001 09:24:49 -0600

I think the language in our (the LCUP authors') working version of the draft is sufficient.  As Mark said, the new version will be
out shortly.