Re: [Fwd: LAST CALL: draft-ietf-http-state-man-mec-04.txt]

Yaron Goland sent the following comments to Larry Masinter.  With
permission of both parties, I'm responding to the comments on http-wg.

  > Just to be clear, there is no intent to actually issue the draft as an RFC,
  > rather the purpose of the last call is to get everyone to agree at least on
  > the syntax so that any further arguments will strictly address the privacy
  > issues and not digress into a syntax battle?

That's the idea.

  > 
  > Also, I really think we would be doing the world a major favor if the first
  > half of the draft just specified what the hell the current cookie
  > implementation really is, aka document current implementation. This would
  > mean pointing out various syntax errors in the original proposal,
  > differences in implementation between different browsers, etc. That way we
  > at least know where we stand. From there the draft can then specify
  > backwards compatible extensions and fixes.

I do not know all the possible errors, etc., nor do I know the
implementation behavior of various browsers.  One of the reasons for
writing the cookie spec. was that Netscape's original was so loose, it
was hard to know what it specified.

I would certainly welcome a companion document for the record from
vendors, who are most likely to know what their products actually
do/did.

  > 
  > The definitions given in section 3 don't seem to be either useful or even
  > accurate. For example, most cookie "sessions" are now indefinite. Your
  > cookie gets set with your id or favorite settings and stay there,
  > essentially, forever. I think all of section 3 can be removed without
  > materially effecting the draft.

If you mean "attributes" rather than "definitions", I agree with you.
The world of cookies has evolved a lot in the nearly two years (!) this
spec. has been gestating.

  > 
  > 4.2.2 - A note should be included that the name of the name=value may
  > collide with the name of an attribute in the rest of the cookie but that no
  > confusion is possible as the first attribute is ALWAYS guaranteed to be the
  > name=value pair. This isn't a technical flaw, rather I just think putting in
  > this sentence will clarify matters.

Okay.

  > 
  > In 4.2.2 he defines a production VALUE = value but in so far as I can see,
  > he never defined the production for value.

"value" is defined in 4.1.

  > 
  > In 4.2.2 it says "Comment=comment" as one of the paragraph headers. It
  > should be Comment=value. Additionally he doesn't address the
  > internationalization issues of having a comment. 

Regarding "=comment", I do the same with Domain, Max-Age, Path, ....
The syntax further up defines the actual syntax for each a-v.
"comment" ("domain", "delta-seconds", "path") in the descriptions imply
the semantics.  (In the PostScript version, they're in italics.)

I'm open to alternatives the convey what the semantics are for the value
of each attribute.

There had been some discussion on the mailing list about
internationalization in Comment.  I think the problem of how to support
different languages in request headers is larger than just Comment.
How do you support negotiation of acceptable languages for attributes?
I will confess to being unsure of how to address the issues.  Moreover,
people noted that CommentURL could solve the problem, by using HTTP
content negotiation.

  > 
  > 4.2.2 - Comment_URL - Something should be said about cookies being on the
  > URL that the user is redirected to. I have absolutely no problem with a
  > cookie being sent on that URL, but some mention should probably be made
  > about the issue.

That issue was among the sections I removed between state-man-mec-03 and
-04 because it treads on user interface issues.  So it will return.

  > 
  > 4.2.2 - Discard - What does "agent termination" mean? For example, IE 4.0
  > starts up when you turn the OS on and stops running when you turn the OS
  > off. I suspect that wasn't the duration that was intended. The same sorts of
  > issues apply to browsers running in Kiosks.

Your interpretation is fine.

The intention, which may no longer be realizable in some contexts, was
for an application to be able to say the cookie has a defined lifetime,
but that lifetime should not persist beyond an "invocation" of the
browser.  What we had in mind, for example, is that, if I'm a user of a
shared PC in a college computer room and I exit the browser, cookies
that would otherwise have been saved (because they have a Max-Age
value) will be discarded.  So that's what should happen if you restart
a Win95 system with MSIE 4.0.

  > 
  > 4.2.2 - Domain - It says that if a leading dot isn't specified on a domain
  > then one should be added by the client. Why? After all I may ONLY want a
  > cookie to apply to foo.bar.blah NOT *.foo.bar.blah. Shouldn't we just take
  > the server at its word? If there is a dot, keep it. If there isn't, loose
  > it. Of course I find the domain matching rules really confusing so maybe I
  > am just missing something.

This was actually an attempt at simplification.  If your server is
foo.bar.blah and you want cookies to return only to that server, then
omit the Domain attribute; the default will do what you want.  If you
give an explicit Domain, it's assumed to be for a group of domain names.

  > 
  > 4.2.2 - Path - A more specific reference should be included to specify that
  > there is an implied wildcard at the end of the path specification.

I'm not sure what you're asking for.  Path Selection under 4.3.4
already conveys what I think you want.

  > 
  > 4.2.2 - Secure - 
  > 
  > 	"When it sends a "secure" cookie back to a server, the user agent
  > should use no less than the same level of security as was used when it
  > received the cookie from the server." 
  > 
  > Y'all don't really expect browsers to record the level of security used when
  > a cookie was retrieved? In some cases this information may not even be
  > available because security may be implemented in such a way that the
  > software handling cookies can't find out about it. I think this requirement
  > is unrealistic.

You and I have discussed this item before.  My answer is "yes", but note
that the spec. says "should use".

The goal of the words is to ensure that the information in the cookie is
treated with the same level of security when it is sent to the server as
when it was received from the server.  I'm open to alternative ways to
say that.

  > 
  > 4.3.2 - Rejecting Cookies - In this section a domain attribute with no
  > internal dots results in a cookie that can not be accepted. This effectively
  > means that cookies can not be used on intranets where single name sites are
  > common. I realize this prohibition was put in for things like "com" but we
  > have to realize that one word domain names are widely used on intranets.
  > This discrepancy must be resolved.

There are two possible resolutions:
1) Omit Domain, in which case the default is to send the cookie only to
the server from which it came; or
2) Use a fully qualified domain name for Domain, even on an intranet.

  > 
  > Additionally there is the requirement in this section:
  > 
  > 	"* The request-host is a HDN (not IP address) and has the form HD,
  > where D is the value of the Domain attribute, and H is a string that
  > contains one or more dots."
  > 
  > This requirement is inappropriate because a site may have good reasons for
  > wanting matching more than one level deep. We should allow for such
  > matching, especially when there is a PICs label to go along with it. In
  > general this restriction always seemed arbitrary.

Because this falls under the "privacy" category, will you accept deferring
its discussion?

  > 
  > 4.3.3 - This section contains "[Wording about cookie inspection user
  > interface to be supplied.]". I take this to mean we are bundling together UI
  > issues with privacy issues?

They tend to get bundled together.  The rule of thumb has been that the
user should be able to control privacy by examining what's going on.
That control often implies some kind of user interface features.

Dave Kristol

Received on Monday, 17 November 1997 13:57:12 UTC