Re: FW: revised trusted cookie spec

Fisher Mark <FisherM@exch1.indy.tce.com> wrote:
>>I agree 100%. I want the way a site tells me what it is doing with my
>>private information to be available via a simple, consistent UA
>>mechanism. I don't want one mechanism for cookies, another mechanism for
>>content negotiation, a third mechanism for deciding whether to supply my
>>email address as the password for anonymous FTP, another mechanism for
>>deciding whether I want to supply personal information in forms I fill
>>out using a web browser, another mechanism for deciding whether I want
>>to supply personal information when interacting with a Java applet. I
>>want just what you're calling for: a single, consistent UA mechanism,
>>adapted for local preferences for charset and language, but I want it
>to
>>be useful for all of those mechanisms. Putting in "Comment" and/or
>>"CommentURL" inside Set-Cookie does nothing to help out with any of the
>>other situations in which privacy is also an issue, and is quite
>>possibly inconsistent or incompatible with those other situations.
>
>I agree -- one mechanism for handling private information would be much
>better than separate mechanisms for cookies, Java, etc.  It should also
>be pursued by another working group, so that http-state can handle the
>rest of the revisions to the cookie spec.  This has been a tremendously
>contentious issue, which should be handled in general purpose fashion
>rather than on a case-by-case basis (which is what commentURL does).

	You are agreeing with a misunderstanding or misrepresentation
of what is in draft-ietf-http-state-man-mec-03.txt.  Efforts to deal
with the "trust" issue within it *consistently* have been rejected,
for a variety of reasons, and instead are "postponed" to future efforts
to address this contentious issue:

	Sorry, I'm not willing to entertain the idea of credentials
	and trusted parties for this version of the spec.  Maybe it's
	reasonable for the future, but lacking a complete description
	of the credentials infrastructure, your proposal isn't practical
	now.
		-- dmk@bell-labs.com (Dave Kristol) 26-Mar-1997


	I believe Jaye's proposal can be defined as an overlay to
	RFC 2109 (or its successor).  Since (I presume) the use of
	certified cookies will be optional, there will still need to
	be a definition of what happens with uncertified cookies.
	It will take awhile to work out the details of Jaye's proposal,
	and I think tying the progress of RFC 2109 to jaye-trust-state-00.txt
	(and its successors) will delay a state management standard
	needlessly.
	From a purely procedural standpoint, it's easier to get
	agreement on smaller things than bigger ones.  Imagine, for a
	moment, that we try to merge RFC 2109 and jaye-trust-....  As
	long as the full document is under discussion, the whole thing
	will be subject to tinkering (and arguing).  Better to nail down
	a substantial portion of the document, namely RFC 2109, and set
	it aside as done.
		-- dmk@bell-labs.com (Dave Kristol) 21-May-1997

	I would rather not have the standards merged. Jaye's proposal
	is something I am extremely interested in implementing. 2109
	is something I would rather not have to deal with. By keeping
	the standards separate I get to more easily pick and choose.
		-- yarong@microsoft.com (Yaron Goland) 21-May-1997

	What I actually had in mind for RFC2109' and jaye-trust-...
	was more like this:  RFC2109' would be much like state-man-mec-01.
	There wouldn't be any specific forward references to new mechanisms. 
	When/if jaye-trust-... becomes an RFC, it would make reference to
	specific sections of RFC2109' and how it supersedes them.  For
	example, there might be a section that says that if a certified
	cookie carries a trust level that is at or above a configured
	level in the user agent, then the rules about unverified transactions,
	which otherwise might be violated, would be satisfied.  (Obviously
	the words would be much more detailed.)
		-- dmk@bell-labs.com (Dave Kristol) 21-May-1997

	My preference is for Set-PICS-Cookie (or some other header name)
	be a strict add-on to RFC 2109 (or successors).
		-- dmk@bell-labs.com (Dave Kristol) 30-May-1997


and so on and so on, through draft-ietf-http-state-man-mec-03.txt!!!!!

	There is not such thing as a "trusted cookie spec" -- subject
line for this thread notwithstanding.  That is a figment of Larry's
and now also your imaginations, probably due to unresolved approach-
avoidance conflict.  But the bottom line is that its still avoided.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Tuesday, 19 August 1997 12:38:09 UTC