Re: cookie draft available

  > I would restart the abstract with a much more concise statement of
  > what you are up to, like:
  > 
  > |This proposal specifies a method for creating a stateful session
  > |with HTTP requests and responses.  It describes two new headers,
  > |Cookie: and Set-Cookie:, which carry state information between
  > |participating origin servers and user agents.  The method described
  > |differs from Netscape's Cookie proposal, but it can interoperate with
  > |HTTP/1.0 user agents which use Netscape's method.
I like it.  I'll change to use your words.
  > 
  > I'm afraid I feel, in general, that the explanatory material in the
  > draft needs to be tighter.  There is some good stuff in here, but the
  > integration needs work.  The list of Koen's dimensions for the
I invite some specifics, especially specific wording.
  > solution space of stateful dialogs, for example, seems to be a useful
  > thing for implementors to keep in mind, but I believe that the bullets
  > would have to be fleshed out a good bit before someone who has not
  > been following the discussion would be sure of what you meant.  The
Probably true, but probably unimportant.  Adding words here, I think,
would only distract further.
  > current user agent methods for displaying links is a problem in the
  > other direction; it is a fairly detailed list of examples, but it is
  > basically a digression.
The point was to reassure vendors (e.g., Netscape) that they're
probably doing what's needed already, and users, that they shouldn't
necessarily expect too much.
  > 
  > I've also found a number of things that need clarification:
  > 
  > Is the port part of the Fully Qualified Host Name?  Section 4.3
  > implies that it might be, but the definition of FQHN doesn't say the
  > port is included.
No, the port is not part of the FQHN, but it *is* used as a key for
storing cookies.  That is, the client must distinguish cookies that it
receives from servers on different ports of the same host.
  > 
  > All of the Examples in 5.1 name HTTP/1.0; is this meant to be 1.1 ?
Yes.  I changed them.
  > 
  > In section 7.1, you list a number methods for User Agent Control of
  > Cookies, one of which is "control the saving of a cookie on the basis
  > of the cookie's Domain attribute".  That should be broadened at least
  > to allow the user agent to completely disable the saving of cookies
  > (it would be nice, of course to control the saving of cookies on the
  > basis of arbitrary attributes, but that might be too much to ask for).
I guess I need to know what you mean by "save".  If you disable sending
cookies (first bullet), have you achieved what you want?  Or should the
bullet read "sending and saving"?
  > 
  >  
  > In Section 8.2, you discuss Cookie spoofing, but I believe that you
  > are missing at least one of the possible problems--the way domain
  > matching is described, it appears that someone from the host sub.tld
  > could successfully get or spoof cookies for anyhost.sub.tld .  If that
  > is not the case, you should describe how it is prevented; if it is,
  > you should make it clear.
I believe a cookie from anyhost.sub.tld would indeed by sent to host
sub.tld.
  > 
  > The paradigm you describe implies that proxies/caches never introduce
  > a Set-Cookie header; I think it would be useful to make that a MUST
  > NOT (to prevent overlap with potential Cookies set by the origin
  > servers, which might happen if cache designers believed that this set
  > of headers provided an appropriate method for tracking cache usage).
Okay.
  > 
  > The implementation limits of 300 cookies and 20 per host seem a bit
  > high (think of our friends writing the browser on the PDA), what
  > went into that number?  (Depending on how you viewed sessions, for example,
  > you could say 20 per host and 20 total--each session ending when you
  > went to a new host.  That would be really limiting, obviously, but why
  > 300?)
Good point.  The numbers come from the original Netscape proposal.  Lou
Montulli felt that application writers needed some certainty about what
a client could save.  I don't have a good defense for 300 specifically.
Lou?
  > 
  > Sorry to hit you with a bunch of these things--but I will say in my
  > defense that I didn't wait until the 24th :).
Indeed!  Thanks for being early.

Dave

Received on Thursday, 18 April 1996 14:52:54 UTC