Subject: RE: Comments on LCUP draft - opaque cookie

From: Christopher Apple <[email-masked]>
Date: Fri, 8 Jun 2001 10:43:05 -0400

I have similar concerns about the opaque property
of the cookie.

I see nothing fundamentally wrong with LCUP clients
storing different cookies for different servers, or
even multiple cookies for the same server.

However, I believe that this is still not sufficient to
help encourage interoperability between LCUP clients
and servers from different implementers.

I believe that the structure of cookie content must
be specified. The structure should be designed to support
a minimum set of required elements (to provide some
guarantee that compliant clients and servers can talk
with each other at some level) and also have some mechanism
for augmenting the required set of elements with experimental
or vendor-specific ones.

Clients and servers would have to behave gracefully in
the event that they see an element in a cookie that they
do not support or understand how to react to.

Because I'm one of the co-chairs, I don't consider it
appropriate for me to suggest a specific cookie structure,
but I believe that one needs to be included in the document
if we're to have any hope of achieving interoperability
for LCUP. I also believe that the structure should have
at least the properties described above.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 1:39 PM
To: James Benedict
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Comments on LCUP draft - opaque cookie

This is a good issue to discuss.  I believe the intent is for an LCUP
client to store one (or more) cookie(s) per server.  But if a replicated
set of directory servers are deployed and clients choose "one of many"
to use for their LCUP sessions (for redundancy or load balancing
reasons), it would be nice if the cookie format were consistent.  On the
other hand, specifying the format of the cookie will really tie the
hands of server implementors.  We need to clarify this in the LCUP
specification, one way or another.

-Mark

James Benedict wrote:
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, May 16, 2001 12:55 PM
> > To: [email-masked]; [email-masked]; [email-masked]
> > Subject: Comments on LCUP draft - opaque cookie
> >
> >
> > This comment refers to <draft-ietf-ldup-lcup-00.txt>.
> >
> > The controls defined in the LCUP draft use an opaque cookie
> > supplied by
> > the server.  I'm concerned about the consequences of leaving
> > the cookie
> > opaque.  It seems to me that interoperability with multiple servers
> > will be limited.
> >
> > Section 4.6 of the draft includes the note:
> >
> >   (Note that the client can synchronize with different servers
> during
> >   different synchronization sessions.)
> >
> > If the cookie is opaque, this will only work if the different
> servers
> > are all running the same server implementation.  Different vendors'
> > implementations of LCUP will inevitably use different cookie formats
> 
> > because there is no standard format.
> >
> > Section 7 notes:
> >
> >   By design, the protocol does not specify the format of the cookie.
> 
> >   This is to allow different implementations the flexibility
> > of storing
> >   any information applicable to their environment.
> >
> 
> Haven't we been down this path before (with ACI)?  I agree that the
> standard should not force a particular means of storing data, HOWEVER
> interoperability from a client perspective requires that information
> be common "on-the-wire".
> 
> Or is the intention that LCUP clients maintain one cookie per server
> (or vendor type, or whatever...)?  If this is the plan, then we still
> need to put some more smarts on the cookie so that the client can
> determine which cookie to send to which server.
> 
> > But that flexibility will limit interoperability.  Since
> multi-vendor
> > replicated directory environments are a goal of LDUP, shouldn't the
> > content of the cookie be specified in the standard?
> >
> > Rick Huber

---

From: [email-masked] (Rich Megginson)
Date: Mon, 11 Jun 2001 13:57:27 -0600

To me, LCUP interoperability means that you can issue the same LCUP search
request against different servers and expect to get the same result.

For example:
I have a client who regularly issues LCUP search requests against serverA
for scopeA.  Now, for some reason, serverA is unavailable, and the client
must access serverB.
1) If serverB is in sync with serverA and serverB has the same
implementation as serverA, everything is ok.
2) If serverB is in sync with serverA but is implemented differently, a
client resync is necessary (different cookie).
3) If serverB is not in sync with serverA but has the same implementation,
a client resync is necessary (cookie not fresh).

How likely is scenario 2) above?  Not very likely I think.  The worst case
scenario is that the client must do a full resync in that case.  Note that
case 3) is much more likely (IMHO) than case 2) and the outcome is the
same.

Is it really worth exposing the cookie format?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 11 Jun 2001 13:46:17 -0700

>Is it really worth exposing the cookie format?

IMO, the cookie should be an opaque octet string.
The client should never pass the cookie on to any
peer other than the one which provided the cookie.

Kurt