Subject: Re: Comments on LCUP draft - opaque cookie

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

True.  But shouldn't we be trying to do more than just "not prevent"
interoperability?

Rick

: To: [email-masked] (Richard V Huber)
: From: "Kurt D. Zeilenga" <[email-masked]>
: Subject: Re: Comments on LCUP draft - opaque cookie
: Cc: [email-masked], [email-masked]
: 
: At 02:27 PM 6/11/2001, Richard V Huber wrote:
: >But that would mean that any system with a load-balancer in front of a
: >set of replicated directory servers would require complete resync
: >unless the user lucked out and got the same server they had on their
: >last connection.
: 
: Having an opaque cookie does not prevent a vendor from provide
: such capabilities.
: 
: Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 11 Jun 2001 15:02:38 -0700

>True.  But shouldn't we be trying to do more than just "not prevent"

It is not preventing interoperability in replicated environments,
it is deferring specification of such features to future documents.
LCUP should be a simple client/server update protocol.  If a
particular client can update from a particular server, this
client and server interoperate.

If later, we want extend LCUP to allow a client to update
from any replica in a distributed environment, we can do
that.  But I suggest we try to maintain a narrow focus
on this work.  That is, I believe we should avoid defining
how LCUP works in a replicated/distributed environment at
this time.

Kurt

---

From: Richard Huber <[email-masked]>
Date: Tue, 12 Jun 2001 09:36:18 -0400

It seems to me that it will be a lot harder to add support for replicated
environements later than it would be to put it in now.  If we defer
specification of the cookie,  we will end up with a number of implementations
with completely incompatible cookie formats. Once that has happened it will be
much harder to get agreement on a standard format.

Rick