Subject: RE: Comments on LCUP draft - opaque cookie

From: Christopher Apple <[email-masked]>
Date: Tue, 12 Jun 2001 11:45:59 -0400

Definitely agree with what Rick said.

Here's another perspective, strictly not speaking
as a co-chair, related to upgrading from a version of
LCUP in which the cookie is opaque to one in which the
cookie is exposed:

I work for an ASP, specifically, a messaging ASP. Messaging
applications are often tightly coupled with an LDAP or
other directory implementation. Also, we happen to host
3 distinct messaging platforms from 3 different vendors,
each of whom have their own LDAP/Directory implementations.

Assume that we have a substantial portion of our customer
base requiring synchronization services for which LCUP
would be a fairly close match in a theoretical sense.

Nearly all of these customers refuse to allow custom-built
software (built by developers at my company) to be installed
on servers that they operate. Couple this with the fact
that as a whole, they have very diverse operating environments
for their internally hosted IT systems and do not want to have
to change that environment significantly to be able to outsource
messaging application hosting to us.

If we were to elect to use LCUP as a solution to the
appropriate subset of synchronization problems that our
customer base has, we would have to let them choose the
LCUP client implementation that would operate in their
own local environment - and we would, for operational
simplicity, constrain ourselves to operating LCUP
server-side interfaces that would be associated with
the directories/LDAP servers tied to our 3 different
messaging platforms.

In my company's ASP environment, you end up with a couple
of nasty problems if the cookie format is not standards
track now but becomes so later on:

1) A complex upgrade situation affecting multiple customers'
corporate messaging systems.

2) An overly complex operating environment from day 1. Assume
LCUP becomes deployed. ASP customers often will not allow their
ASPs to drive the selection of software necessary to integrate
end-user client application address books with the LDAP servers
associated with the messaging platforms that we host. Some of
our customers actually require that some of their end-users be
hosted on one messaging platform with the rest on a different
platform. These customers also usually have:

	- 2 or 3 different end-user client machine environments
	- 6 or 7 different messaging clients (some of which are
	  the same vendor's but different versions) that have
	  address book applications or add-ons

Even with a standards-track cookie format, that's a complex
operating environment in which to get everything working
smoothly from an LCUP perspective. But with a standards-track
cookie format, you at least have a framework that can be used
to certify that appropriately configured LCUP-compliant clients
and servers can work together if from different vendors.
If the cookie format is opaque, I'm not convinced it could ever
work unless we start hacking apart cookies and translating them
on the fly on a pair-wise basis for every deployed combination of
client (including multiple versions) and server through some sort
of application-level gateway. In fact, since most IT managers
either will not or cannot do a flash upgrade of all end-user
messaging client software within a narrow window of time,
a cookie gateway would be a required component during upgrades
if the cookie is opaque.

This scenario would compound the operational complexity of
executing an upgrade from versions of LCUP implementations
that don't support an exposed cookie format to those
that do. So much so, that I wouldn't be able to justify
from an operational or a financial perspective, either the
in-house implementation of an LCUP solution or the licensing
of commercial LCUP technology for building an address book
synchronization solution.

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

-----Original Message-----
From: Richard Huber [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 9:36 AM
To: Kurt D. Zeilenga
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on LCUP draft - opaque cookie

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

"Kurt D. Zeilenga" wrote:

> At 02:44 PM 6/11/2001, Richard V Huber wrote:
> >True.  But shouldn't we be trying to do more than just "not prevent"
> >interoperability?
>
> 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
>
> >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: "John Strassner" <[email-masked]>
Date: Tue, 12 Jun 2001 10:07:09 -0700

I agree with Chris and Richard (and yes, this is an an individual and NOT
as a co-chair). Having an opaque cookie defeats the purpose of
interoperability, period. Promising that somehow, someday, we will agree
on converging on one standard format while multiple private formats have
been deployed won't happen.

regards,
John

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Christopher Apple
Sent: Tuesday, June 12, 2001 8:46 AM
To: 'Richard Huber'; Kurt D. Zeilenga
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on LCUP draft - opaque cookie

Nearly all of these customers refuse to allow custom-built
software (built by developers at my company) to be installed
on servers that they operate. Couple this with the fact
that as a whole, they have very diverse operating environments for their
internally hosted IT systems and do not want to have to change that
environment significantly
to be able to outsource messaging application hosting
to us.

2) An overly complex operating environment from day 1. Assume LCUP becomes
deployed. ASP customers often will
not allow their ASPs to drive the selection of software necessary to
integrate end-user client application address books with the LDAP servers
associated with the messaging platforms that we host. Some of our
customers actually require that some of their end-users be hosted on one
messaging platform with the rest on a different
platform. These customers also usually have:

	- 2 or 3 different end-user client machine
        environments
	- 6 or 7 different messaging clients (some of which
        are the same vendor's but different versions)
        that have address book applications or add-ons

Even with a standards-track cookie format, that's a complex
operating environment in which to get everything working
smoothly from an LCUP perspective. But with a standards-track cookie
format, you at least have a framework that
can be used to certify that appropriately configured
LCUP-compliant clients and servers can work together if
from different vendors.

If the cookie format is opaque, I'm not convinced it could ever work
unless we start hacking apart cookies and translating them on the fly on a
pair-wise basis for
every deployed combination of client (including multiple versions) and
server through some sort of application-level gateway. In fact, since most
IT managers either will not or cannot do a flash upgrade of all end-user
messaging client software within a narrow window of time, a cookie gateway
would be a required component during upgrades if the
cookie is opaque.

Chris Apple

-----Original Message-----
From: Richard Huber [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 9:36 AM
To: Kurt D. Zeilenga
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on LCUP draft - opaque cookie

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

of a
their

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 12 Jun 2001 11:28:34 -0700

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

---

From: "John Strassner" <[email-masked]>
Date: Tue, 12 Jun 2001 12:55:17 -0700

Kurt,

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

regards,
John

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 11:29 AM
To: [email-masked]
Cc: Christopher Apple; 'Richard Huber'; [email-masked];
[email-masked]

Kurt

---

From: "John Strassner" <[email-masked]>
Date: Tue, 12 Jun 2001 13:00:23 -0700

Kurt,

Now that we've split these into two topics, please tell me why you think
that LCUP supporting replicated environments is out of scope. If it is,
then at the minimum we shouldn't have it in LDUP, which we all agreed many
moons ago was the most appropriate wg for this work to be in.

regards,
John

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 11:29 AM
To: [email-masked]
Cc: Christopher Apple; 'Richard Huber'; [email-masked];
[email-masked]

Kurt