RE: Response to the LCUP cookie format issue

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



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.

	<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)

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.

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

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