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

BEGIN:VCARD
VERSION:2.1
N:Apple;Chris
FN:Chris Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer=
ica
ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States of America
LABEL;HOME;ENCODING=QUOTED-PRINTABLE:214 New Street, Apt 4-N=0D=0APhiladelphia, PA 19106=0D=0AUnited States of Am=
erica
EMAIL;PREF;INTERNET:[email protected]
REV:20010413T223539Z
END:VCARD