Re: cookie draft available

Dave,

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

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.

All of the Examples in 5.1 name HTTP/1.0; is this meant to be 1.1 ?

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

 
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.

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

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

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

			Best Regards,
				Ted Hardie

Received on Wednesday, 17 April 1996 15:42:18 UTC