Subject: Response to the LCUP cookie format issue

From: Richard Megginson <[email-masked]>
Date: Tue, 12 Jun 2001 14:07:04 -0600

One of the main goals of LCUP is that it will be lightweight and easy to

implement, both from a client and a server perspective.  Having an
opaque
cookie makes the client easier to implement, and makes the server much
easier
to implement.  Another thing that worries me about defining the cookie
format
is that we may end up dragging a lot of LDUP into this, which may mean a

dependence on an LDUP implementation before we can implement LCUP, and
that
is definitely contrary to the goals of LCUP.

However, we (the authors of LCUP) do see the need to have a known cookie

format to foster interoperability at some point in the future.  To
acheive
this goal, Mark Smith has proposed the following:
Specify that the cookie format is <scheme>-<payload> where the scheme is

an OID that can be implementation specific for now but an LDUP scheme
will be defined also.  In other words, LCUP provides the hook to allow
cookie formats to be common but does not mandate they be common.

Note that use of an opaque cookie format or use of a
<scheme>-<payload> extensible format will NOT prevent an LCUP client
from vendor A from interoperating with an LCUP server from vendor B.

---

From: Christopher Apple <[email-masked]>
Date: Wed, 13 Jun 2001 11:17:38 -0400

-----Original Message-----
From: Richard Megginson [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 4:07 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Response to the LCUP cookie format issue

	<scheme>-<payload> seems like a good fit to me.

	John Strassner pointed out to me yesterday on the phone
	that this is very similar to something that the POLICY WG
	did. <scheme> OIDs are registered with IANA and corresponding
	<payload> syntaxes/structures are published.

	One thing that still concerns me is when you mention
	"foster interoperability at some point in the future."

	I do understand your concerns about keeping LCUP in the
	pipeline until LDUP protocol work is sufficiently far
	along.

	Given that scenario, how's this for a way to proceed:

	1) go with <scheme>-<payload> as a proposed cookie structure
	   in the next revision of the LCUP document

	2) add text proposing how the <scheme> OIDs should be
	   registered with IANA and how the <payload> syntax/structures
	   should be published (it would be fine if these topics were
	   dealt with in a separate document at some point, but I'd like
	   to see a place holder for this in the next revision of the
	   LCUP document)

	3) add text indicating that the <payload> will have a
syntax/format
	   that may be opaque or exposed (or some other appropriate
choices)

	4) add text indicating that it is expected that there will
	   be one or more standards-track <scheme>-<payload>
combinations
	   and that those will be defined in other documents

	5) add text indicating how implementations should respond to
	   each other in the event that they receive or attempt to set
	   a cookie with a <scheme>, <payload>, or combination that
	   they do not understand, is somehow invalid, or is understood
	   but unsupported

	5) John and I will add an agenda item for the London WG meeting
	   to gauge interest in adding one or more such standards-track
	   <scheme>-<payload> specifications to the WG charter based on
	   a proposed charter revision derived from discussion mentioned
	   in 6

	6) we should discuss what sorts of <scheme>-<payload>
combinations
	   would be useful and feasible as a minimum and mandatory to
	   implement set on the LDUP list (I have trouble believing that
	   there are none that would be useful based on the sorts of
	   operational scenarios I've seen so far on the list for LCUP)

	Sure. But that's not sufficient to provide some guarantee of
	minimum interoperability between those same types of entities.
	As a co-chair, that's one of the things that I'm supposed to
	be sure happens - or at least be able to make very clear
	arguments when requesting IESG review of the document about
	why the WG doesn't believe lack of such a guarantee is a
problem.

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