Re: RFC2109 addition...

On Mon, 24 Mar 1997, Jonathan Stark wrote:
> But that is UI...  it's not really our problem here as I understand it.

A much debated point on this list, of late.  But yes, it is definitely not
our concern here.  I raise the UI implications of this proposal simply
because the spec should consider the many clients that may implement it.

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

See the 'Accept-Language' header of HTTP.  Basically, the client could say,
"I prefer Japanese to English," and the server processing the commentURL
request could return a Japanese policy document. 

> What I said (meant to say?) is that they should
> be interpreted EXACTLY as a src="..." field in the body of an html doc.

Okay, that sounds good.  Since we have been debating domain restrictions, I
thought you meant to restrict the policy URL to the same server as the
resource setting the cookie.

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

Yes.

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

Yes, Set-Cookie2 accepts a comma-separated list of cookies.  Since some
sites (the c|net sites come to mind) use commas in URLs, we would need to
protect the URL commas from interpretation.  This would add a little
complexity to URL-parsing.

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

Good point, my suggestion isn't necessary.

> > > 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"? :)

I do think it should be "may" so that browsers unable or unwilling to open
a second HTML-rendering window can feel perfectly comfortable ignoring the
commentURL.  (Hence the suggestion for both commentURL and comment.....)

Marc Hedlund <hedlund@best.com>

Received on Monday, 24 March 1997 20:39:25 UTC