RE: Comments on LCUP draft - opaque cookie

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 protected]
[mailto:[email protected]]On Behalf Of Christopher Apple
Sent: Tuesday, June 12, 2001 8:46 AM
To: 'Richard Huber'; Kurt D. Zeilenga
Cc: [email protected]; [email protected]
Subject: RE: Comments on LCUP draft - opaque cookie


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 protected]>
(V) 610-425-2860


-----Original Message-----
From: Richard Huber [mailto:[email protected]]
Sent: Tuesday, June 12, 2001 9:36 AM
To: Kurt D. Zeilenga
Cc: [email protected]; [email protected]
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 protected] (Richard V Huber)
> >: From: "Kurt D. Zeilenga" <[email protected]>
> >: Subject: Re: Comments on LCUP draft - opaque cookie
> >: Cc: [email protected], [email protected]
> >:
> >: 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