Re: RFC2109 addition...

Quoting Marc Hedlund:

> Jonathan, thanks for reviewing the RFC.
> 
> On Mon, 24 Mar 1997, Jonathan Stark wrote:
> > I would like to have a CommentURL which contains the path to comments
> > regarding the privacy policies of the site that deal with the cookie.
> 
> The potential loop problem (setting a cookie on the cookie information page
> -- which you address in your proposed language) is pretty funny. 

Yeah, it is funny...  But I don't think most people who are using
cookies are going to necessarily think about taking the extra
effort to exclude a certain page.

> I think this suggestion creates UI weirdness -- the proposal seems to
> assume that the client can open a second window for review of the policy

Perhaps.  I think the prefered method would be a unique dialog box that
happens to have html in it... I think it's important that the user deal
with this issue before proceeding, and that it look uniquely different
that JUST another web page, and the only real way to do that is if the
browser makes the window look a little bit differnt.  But that is UI... 
it's not really our problem here as I understand it.  It's good to think 
of it's limitations, though.  Does anybody who's worked on a browser
have any comments?

> before making an accept/decline decision on the cookie.  That may not be
> true for, say, a Pilot Web browser, or other limited-UI browsers.  I don't

Good point.  Is it reasonable to accept a browser to be able to make two
connection at a time?  I'm not sure.  Maybe those browsers would need to
acquire the ability to make multiple connections or just not support this
feature.
> 
> I like David's point about language negotiation being handled through the
> follow-up request, though.  

I'm afraid I don't fully understand this issue.  Language negotiation
is a part of the cookie spec?  I think I missed that part.  Somebody
wanna point me at a URL?

> > I would like this URL to be relative to the URL that issued the cookie,
> > unless otherwise specified (as being server relative or fully qualified).
> 
> Hm....what if I want to reference the generic eTRUST cookie policy (if such
> a thing were to exist) at the eTRUST site?  Then eTRUST could say, "5
> million people examined our cookie policy before accepting a cookie this
> month, so privacy is important to them."  (My point being that there is
> value to centralized policies, and thus absolute commenturls, be they for
> privacy advocates or Better Business Bureaus or whatever.) 

I agree completely.  But we would get that information from logs or a cgi
that counts the hits.  What I said (meant to say?) is that they should
be interpreted EXACTLY as a src="..." field in the body of an html doc.
ie, a request to "http://www.etrust.org/thing/text.html" could have the 
following values in ComentURL translating to the following pages:

	policies.html	->	http://www.etrust.org/thing/policies.html
	/policies.html	->	http://www.etrust.org/policies.html
	http://privacy.goodguy.org/disclosure.html	->
				http://privacy.goodguy.org/disclosure.html

My purpose in doing this is to make the commenturl value as short as
is reasonably possible.  The code in most browsers is already there
to expand server and page relative URLS, so use it.

> 
> > CommentURL=commenturl
> 
> How about 
>   CommentURL = '<' commenturl '>'

I'm new to this whole process, so I guess I don't understand the
difference in notation.  Does this now imply that the attributeline would
look like this:
	CommentURL=<http://www.privacy.net/disclosure>
?
If so, I disagree.  It should be parsed the same as all the other
attributes...
	CommentURL=http://www.privacy.net/disclosure
However you notate that.... :)  I'm not sure... are there problems
with escaped characters in a URL meaning something in the Cookie?
Somebody help me out here...   Maybe <> is necessary?
	
> > Optional.  The CommentURL allows an origin server to specify a document
> > that explains the usage of this cookie, and could optionally also explain
> > the policies governing the use of information collected through this cookie.
> 
> Add: "A server SHOULD send a comment if sending a commentURL, for use by
> those browsers unable to display the CommentURL contents."

I question this a little bit.  My goal (in addition to the one you
pointed out, in providing a common location for collecting policies)
is to reduce the amount of data that has to be sent to the client.
If you send a comment AND a URL, that doesn't really achive my goal.

I suspect that "the market" will dictate it's own rules on using
one or the other or both based upon the implementations of the day.
And, to some extent, that's probably ok.  I guess my point is that
the best practices will change over time, and we maybe shoudn't outline
a static practice in the RFC.  Do others agree or disagree?  This is
a tricky issue.  If you don't set down a best practice, you may not
get what you want, but it you do, you may end up outdated.

There certainly is value to both methods, and I do see your point.
Perhaps the best thing to do would be to recommend that in the absence of
a comment, the CommentURL (if present) should be offered to the user
in a similar way as the Comment.  This isn't extremely graceful, but then 
someone truly concerned has the option to not accept the cookie originally, 
and go look at the comment URL even on a browser that only allows one
connection at a time.  I don't really think I'd like what this would look
like, but it's something.

> > A user-agent can offer the user the option of inspecting this page before
> > accepting a cookie.  
> 
> Should be: "A user-agent MAY..."

I'll go half way... how about "A user-agent should"? :)

> > Any cookies issued while attempting to retrieve the
> > document at commenturl should be refused.
> 
> Marc Hedlund <hedlund@best.com>
> 

Thanks for the comments, Marc,

Jonathan

Received on Monday, 24 March 1997 20:09:59 UTC