Subject: Re: Comments on LCUP draft - opaque cookie

From: [email-masked] (Richard V Huber)
Date: Mon, 11 Jun 2001 17:22:47 -0400

I don't see anything in the current draft that says that your case 1
("If serverB is in sync with serverA and serverB has the same
implementation as serverA, everything is ok") will work.  If the cookie
is opaque, why should we assume that there is no instance-dependent
information in the cookie (for instance, the offset in this particular
server's change log of the last update sent to the client)?  Then even
two sync'ed servers from the same vendor implementation would not have
compatible cookies.

Also, during server upgrades server code from the same vendor might
have incompatible cookies.  And while I grant that your case 1 is
probably more common that case 2, that is in part true because existing
standards do yet not support vendor interoperability for replication
and update.  It seems consistent with IETF goals to deliver standards
that permit case 2.

Think about a mobile user on the road with only dial access.  And think
about a coporate directory with thousands of entries that contain
certificates.  In such situations complete refreshes should be avoided
whenever possible.  The protocol should try to make complete refreshes
a rare event.

Does it really cost so much to expose the cookie format?

Rick Huber

: From: [email-masked] (Rich Megginson)
: To: [email-masked]
: Subject: Re: Comments on LCUP draft - opaque cookie
: 
: 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?
: 
: Christopher Apple wrote:
: 
: > 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: Christopher Apple <[email-masked]>
Date: Mon, 11 Jun 2001 18:55:31 -0400

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Monday, June 11, 2001 4:46 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on LCUP draft - opaque cookie

At 12:57 PM 6/11/2001, Rich Megginson wrote:
>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

I think those statements conflate a few issues that
should really be dealt with separately:

1)Clients should never pass a cookie on to a peer
other than the one which set/provided the cookie.

	I completely agree here. But that doesn't
	require or even necessarily make it a good
	idea to make the structure of the cookie
	content opaque.

2) The term "peer" generally refers to an operational
instance of an LCUP server - in both the real world
and the theoretical sense (e.g., in the protocol spec).

	Its the real world context where I find what
	you've said to be confusing. The reason I find
	this confusing is that my prior posting indicated
	that (I'm paraphrasing for brevity):

3) Clients and Servers from different implementers
should be able to understand enough cookie content
so that some level of cross-implementer Client-Server
interoperability is possible.

	This doesn't mean that any real-world client would
	be required to send all of its cookies to any
	real-world peer (a deployed instance of a server)
	regardless of which real-world peer originally
	set the cookie.

If you buy into 3, above, it means that there must
be some basic level of cookie structure that is specified
and required to be supported by compliant implementations.

There should be a really compelling set of real-world
reasons that the WG achieves consensus on in order for the
co-chairs to make a recommendation that a document containing
a feature that will impede interoperability of client and
server implementations from different implementers be considered
for IETF Last Call. With the present proposal of an opaque
cookie format, that is the document's current status.

I'm not suggesting by any means that discussion related to
this topic should stop - in fact, I'm saying that more opinions
need to be aired on the list about the more fundamental
issue of client-server interoperability; and why it should
or should not be a requirement.

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

---

From: Christopher Apple <[email-masked]>
Date: Mon, 11 Jun 2001 19:06:39 -0400

I was referring more to "out-of-the-box" interoperability
between clients from one implementer and servers from another.

As a co-chair, that's part of the way I have to define
interoperability unless there are compelling reasons
for looking at it in a more constrained way as you've
given examples for below. Those are certainly relevant
scenarios, but I don't believe they should be the only
constraints that we consider as potentially being levied
against the spec.

Need to hear from some other WG participants...

Chris Apple

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 11, 2001 3:57 PM
To: [email-masked]
Subject: Re: Comments on LCUP draft - opaque cookie

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.

Christopher Apple wrote:

> 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
> 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]
> 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:
> >
> > > 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