RE: Separate LCUP cookie vs replication - was RE: Comments onLCU P draft - opaque cookie

Kurt,

This problem can solved by having one or more
standards-track OID/payload pairs that clients
and servers can support.

Just having the clients pay attention and react
appropriately to OID/payload pairs doesn't constitute
an interoperability problem - it actually constitutes
one way of supporting a minimum level of interoperability
between a client from one implementer and a server from
another. That's the essence of the guidelines that the
authors have adopted with respect to this topic. The
guidelines make no definitive statement about the details
of how clients are expected to behave in the event that
they encounter unknown/unsupported OIDs.

I suspect that where we will end up is having the LCUP
document as revised by its editors plus one or more
standards-track OID/payload documents.

Its been pointed out that this is not the only way of
supporting client-server interoperability. That is a
true statement. Its also been pointed out that having
standards-track OID/payload pairs is a more assured
path to being able to interoperate between LCUP-compliant
implementations than relying on market forces decide
if and when such implementations should interoperate.
Going down the latter path would mean that LCUP doesn't
really belong in an IETF WG at all and would be better
off in a closed industry consortia group.

And no, I'm NOT suggesting that the document should be
removed from the LDUP charter at this point. We need to
see the next version of it and discuss the possibility of
and obtain a few informal proposals from WG members on
standards-track OID/payload pairs that are useful.

If I understand your position correctly, you do not believe
that there are any OID/payload pairs that would be useful
for clients to be capable of understanding and reacting
to in a way more intelligently than simply passing back
a cookie previously set by a server.

Or am I reading too much into what you have said so far?

No judgment implied at all - just trying to understand
your position.

Keep in mind that there would be nothing wrong with
having certain OID/payload pairs be opaque to clients
but exposed to servers from any implementer because they
are standards-track; whereas other OID/payload pairs could
be exposed to both clients and servers from any implementer.

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: Friday, July 06, 2001 12:59 PM
   >To: Christopher Apple
   >Cc: '[email protected]'; Christopher Apple;
   >[email protected]; 'Richard Huber'; [email protected]
   >Subject: RE: Separate LCUP cookie vs replication - was RE: Comments
   >onLCU P draft - opaque cookie
   >
   >
   >At 09:11 AM 7/6/2001, Christopher Apple wrote:
   >>The guidelines I recommended for modifying the document
   >>have been adopted by the document editors. Specifically
   >>about the label/OID, these guidelines indicate that the
   >>document should describe how implementations are to
   >>respond when they encounter labels/OIDs that they do not
   >>natively support or understand.
   >
   >My point is that a client should not care what the
   >labels/OIDs are.  It should just return the cookie to
   >the server.  A client which cares will cease to
   >interoperate with servers providing other labels/OIDs.
   >
   >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
EMAIL;PREF;INTERNET:[email protected]
REV:20010621T205341Z
END:VCARD