RE: Comments on LCUP draft - opaque cookie

With co-chair hat on, I fully agree with Chris. That's why I sent the two
messages that I did before reading this one.

-----Original Message-----
From: Christopher Apple [mailto:[email protected]]
Sent: Tuesday, June 12, 2001 12:18 PM
To: 'Kurt D. Zeilenga'; [email protected]
Cc: Christopher Apple; 'Richard Huber'; [email protected];
[email protected]
Subject: RE: Comments on LCUP draft - opaque cookie


There are really two questions that must be answered.
Both of them represent very real issues for the WG
to resolve.

The answers that the WG achieves consensus on are
at the crux of the degree to which LCUP clients
and servers from different vendors will be able
to interoperate.

1) Should LCUP's cookie format be exposed or opaque?

2) Should LCUP explicitly support replicated environments
   based on LDAPv3-based replication (LDUP)?

You could answer 1 without necessarily considering 2
in detail. However, I don't believe that would be a
good idea. Not considering 2 as input for answering
1 means that you could end up with a cookie format
consensus that prohibits the support of operational
scenarios in 2 in a mixed implementation environment
(one which involves the use of a client and a server
from different implementers).

You shouldn't attempt to answer 2 explicitly without
considering and answering 1 first. Doing so would mean
that you do not understand the breadth of tools that
might be available to you as an implementer while
evaluating the overall quality of the LCUP specification.

Speaking as a co-chair:

The WG should achieve consensus on the issue of cookie format
first - based on interoperability considerations. One of those
considerations can be operating in a replicated environment.
By considering that particular issue and being sure that we
achieve consensus on a cookie format that doesn't prohibit it,
the WG has not achieved a default consensus to explicitly
support the operation of LCUP in a replicated environment. It
only means that we don't believe we have prohibited it. We
can then proceed to discussing the issue of applicability for
this particular LCUP specification in a replicated environment
based on the technical issues and scenarios relevant to it.
There is nothing to prevent the WG from changing a previously
achieved consensus related to cookie format if discussions
related to replicated environment applicability of LCUP lead
the WG to draw that conclusion.

I haven't seen anything posted to the list so far that is
substantive enough to outweigh the impedance of an opaque
cookie on cross-implementation client-to-server interoperability.
In fact, I've seen what I perceive to be some persuasive arguments
in favor of exposing the cookie format rather than making it opaque.

We need to hear from some folks in addition to the document
authors, the co-chairs, Rick, and yourself. Specifically,
we need to see technical and scenario-based arguments for
and against exposed and opaque LCUP cookies.

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


-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email protected]]
Sent: Tuesday, June 12, 2001 2:29 PM
To: [email protected]
Cc: Christopher Apple; 'Richard Huber'; [email protected];
[email protected]
Subject: RE: Comments on LCUP draft - opaque cookie


>From my perspective, the format of the cookie isn't the real issue.
The real issue is whether LCUP will support replicated environments.
In particular, whether a client which updated from replica A can
then incrementally update from replica B where the replicate model
has loose data consistency rules (that is, in replicated environments
where A and B may be out of sync, such as in LDUP-based replication).
Supporting replicated environments will go far beyond specifying the
structure of the cookie and require significant more work.

It's my opinion that LCUP support of replicated environments should
be viewed as beyond the scope of this work and left to future
extension.

Kurt