Issues with the cookie draft

I went through this same debate on the DAV group when I made a
suggestion similar to Larry's. I was told, in no uncertain terms, that
telling people to go off and write their own spec is not the IETF way.
Rather it is the responsibility of the document editor to ensure that
all comments are addressed to the satisfaction of the group. It is clear
that this is not the case. In order to help the document editor out I
will recap my major problems with the current specification. I hope
others who have issues with the specification will do the same.

1. General Points:

Why are names beginning w/$ still reserved? As we have now defined the
position of NAME=VALUE, this restriction is no longer necessary.

Comment should be a language tagged Unicode string not a quoted string.
The actual language used can be implicitly negotiated on by the
accept-language headers with the request. This is clearly not a robust
solution but it is probably appropriate to this situation.

Discard is entering dangerous territory. When exactly does a user agent
terminate? Both MSIE 4.0 and NS 4.0 are moving to desk top models where
the user agent is operational as long as the computer is on.
Furthermore, why would you want to discard a cookie when the user agent
terminates? It sounds like this is an attempt to solve the problem of
shared cash behavior. If the cookie is sensitive and if the cache is
shared, we don't want the cookie hanging around. I think we should
change Discard to Private. Private would indicate that the cookie SHOULD
only be recorded if a private cache is in use.

Version should be optional, if not included, it should default to V1.

The default for Max-Age has the same "how long is a UA session" problem
as Discard. IMHO the most robust solution is to have the cookie kept
indefinitely if no Max-Age is included.

2. Quotes & Responses:

Quote:
"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."

Response:
What is greater or lesser security? Do we expect clients to record what
security they were using when they received the cookie and then, through
some as yet undefined mechanism, decide what "greater" or "lesser"
security than the original security mechanism means? This definition is
too fuzzy to be useful, I believe it should be removed.
Quote:
"If an attribute appears more than once in a cookie, the behavior is
undefined."

Response:
Undefined things have a nasty habit of defining themselves. I propose
the sentence read "If an attribute appears more than once in a cookie,
then the cookie is illegal and MUST be ignored." 

Quote:
"HTTP/1.1 servers must send Expires: old-date (where old-date is a date
long in the past) on responses containing Set-Cookie2 response headers
|
unless they know for certain (by out of band means) that there are no
downsteam(sic) HTTP/1.0 proxies.." 

Response:
I believe this sentence should be changed to read "HTTP/1.1 servers MUST
send Expires: old-date (where old-date is a date long in the past) on
responses containing Set-Cookie2 response headers meant for single users
unless...". We allow caching of Set-Cookie2 headers intended for
multiple people.

Quote:
"   * The request-host is a FQDN (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."

Response:
The company Blah Inc. has the web site blah.com. Blah sells many
products, one of which is called bar. Bar has been released in several
versions, the newest of which is Foo. Blah wants to be able to present
information to its customer that it thinks the customer will be
interested in and it wants to present this information across all of its
sites. So it sends a cookie whose domain is .blah.com. If a user is
visiting foo.bar.blah.com and receives this cookie they will have to
reject it because it violates the above rule. It is totally appropriate
for Blah Inc. to want to hand out cookies that apply to all the sites it
owns. However instead of doing it simply by having a single cookie, it
now has to clutter the user's hard drive with cookies for every
*.blah.com site visited, not to mention complicating the server's
implementation. I believe this requirement is not reasonable, especially
for complicated sites.

Quote:
"User agents should allow the user to control cookie destruction...." 

Response:
If a UA maker wants to never allow a customer access to cookie control
mechanisms, that is the UA maker's business, not the standards. We can
not threaten companies by saying "Well if you don't create your
interface the way we say then you aren't compliant" and expect to remain
credible as a standards organization. This is not a wire protocol
related issue. It is a feature issue and a matter of competitive
advantage for UAs.

Quote:
"   * The value for the $Domain attribute must be the value from the
|
     Domain attribute, if any, of the corresponding Set-Cookie2 response
|
     header.  Otherwise the attribute should be omitted from the Cookie2
|
     request header.
|

   * The value for the $Path attribute must be the value from the Path
|
     attribute, if any, of the corresponding Set-Cookie2 response
|
     header.  Otherwise the attribute should be omitted from the Cookie2
|
     request header"

Response:
All cookies have Domain and Path values. When not explicitly defined
they are implicitly defined. Thus a user agent will record these values,
explicit or not. The above requirements now dictate that the UA has to
record extra information, an indication if the Domain and Path are
implicit or explicit. I can find no good reason to place this
requirement on the UA. Instead we should simply require that the Domain
and Path, explicit or not, should always be returned with the cookie.

Quote:
"Domain Selection
     The origin server's fully-qualified host name must domain-match the
     Domain attribute of the cookie.  The origin server's port number
|
     must equal the port number of the server that sent the cookie."

Response:
Why do we have the port number requirement? If Blah Inc. has an HTTP
server on ports 80 and 81, why would we want to prevent sharing between
two ports on the same system?

Quote:
"If multiple cookies satisfy the criteria above, they are ordered in the
|
Cookie2 header such that those with more specific Path attributes
precede those with less specific.  Ordering with respect to other
attributes (e.g., Domain) is unspecified."

Response:
If we leave domain ordering undefined doesn't that sort of destroy the
utility of requiring path ordering?

Quote:
"User agents may offer configurable options that allow the user agent,
or
any autonomous programs that the user agent executes, to ignore the
above rule, so long as these override options default to ``off.''"

Response:
Again, I do not feel it is appropriate for this specification to dictate
to UA makers how to build the parts of their product that do not go over
the wire. If a UA maker wants this to default to "ON", that is their
business. If the UA maker wants to default to "ON" and not allow the
user to change the value, that is also their business. The mission, I
hope, is interoperability, not second guessing UA makers.

Quote:
"This state
management specification therefore requires that a user agent give the
user control over such a possible intrusion, although the interface
through which the user is given this control is left unspecified.
However, the control mechanisms provided shall at least allow the user

   * to completely disable the sending and saving of cookies.

   * to determine whether a stateful session is in progress.

   * to control the saving of a cookie on the basis of the cookie's
     Domain attribute."

Response:
Wire protocols have a massive effect on the range of functions a client
can implement. In effect, they restrict products. Software companies
have decided that interoperability is such an important product feature
that it is worth having their functionality restrained. However there is
another reason behind the software maker's behavior, they know that the
real battle is UI not features. Features tend to be a check-list, so
long as everyone has the same check marks, the competitive field remains
flat. The area of competition becomes primarily one of interface. When
standards step beyond the wire, beyond even functionality, and go into
the area that is the heart of computer software, they render themselves
irrelevant. Companies are not going to give up their competitive
advantage in order to be compliant with a standard. Worse yet, due to
press pressures, companies will be forced to look like they are
compliant, even when they are not. This reduces the ability of the IETF
to be an effective standards setting organization. Once companies are
forced to selectively ignore standards the goal of interoperability
becomes impossible.

			Yaron

> -----Original Message-----
> From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
> Sent:	Tuesday, March 18, 1997 12:16 PM
> To:	http working group
> Subject:	Re: Unverifiable Transactions / Cookie draft
> 
> I think that this debate has been revisited sufficiently
> that we're no longer making good progress. I am looking 
> for ways of wrapping up the discussion, rather than repeating
> (endlessly) arguments made and remade again.
> 
> There is a significant divergence of views, and many remain
> steadfast that the original tradeoff in 2109 between privacy
> and capabilities are well considered.
> 
> I think there's also a significant counter-opinion
> developing. I would suggest -- as an alternative to
> continuing on the mailing list -- that we ask those
> who would prefer to see a different resolution on the
> issue of unverifiable transactions to write a separate
> internet draft, outlining what the protocol should say
> instead and addressing the issue of user privacy to the
> same detail as RFC 2109. Perhaps if we can see a complete
> design which adequately protects user privacy, we can
> consider the alternative with sufficient technical detail.
> 
> Is this OK? Can we close down discussion on this point until
> we have a fully worked out alternative from someone?
> 
> Thanks,
> 
> Larry
> -- 
> http://www.parc.xerox.com/masinter

Received on Tuesday, 18 March 1997 17:51:05 UTC