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

From: Christopher Apple <[email-masked]>
Date: Fri, 6 Jul 2001 16:02:39 -0400

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

   >-----Original Message-----
   >From: Kurt D. Zeilenga [mailto:[email-masked]]
   >Sent: Friday, July 06, 2001 12:59 PM
   >To: Christopher Apple
   >Cc: [email-masked]'; Christopher Apple;
   >[email-masked]; 'Richard Huber'; [email-masked]
   >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
   >

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Jul 2001 14:09:09 -0700

> No judgment implied at all - just trying to understand

My primary concern is that LCUP peers while fail to
interoperate because the client cared too much about
the contents of something it really should treat as
as an opaque.

Now, I do concede the point that to support future extension
of LCUP (for example, to support LDAP Replication) may
require specification of the cookie to be exchanged by
those supporting that extension. 

The authors have stated that their next revision would
include 'sufficient' language to address the above
interoperability concern.

While you may not yet fully understand my concerns (and
I don't fully understand yours), I think the authors have
a decent enough grasp of our concerns (based upon MarkS's
and RichM comments) for them to take a stab at addressing
both of our concerns.

Kurt