- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Sun, 16 Jun 1996 16:13:30 PDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
The story so far (summarized by me):
Marc is arguing for inclusion of a feature ("1-n domain cookies")
which has not yet been deployed but which Marc thinks is useful.
In particular, this is a feature which is not prohibited but
is specified as 'undefined' in the text.
Dave Kristol points out that it is not current practice. Koen objects
to the feature on privacy grounds, and Ben rejects this argument,
saying that the privacy concerns are already there, and that the
feature would add no additional concerns.
Marc asks (sarcastically) whether OPTIONS, TRACE, Age are "current
practice", presumably under the argument "if those got in, why
not this?".
Various people (well, Marc and Koen) speculate about the politics of
privacy concerns in Europe vs. anti-gum-chewing countries, browser
vendor PR and crucifixion by the press, the market, corporate
politics, the future of the Internet, press clippings in the Wall
Street Journal, and cookie management suites.
Does anyone other than Marc feel that our cookies need these
particular chocolate chips before we can pass them around? We want to
bake the best cookies we can, but we don't want them to get stale.
Since we're nearly done, it's important to properly assess the
sentiment of the working group. As a reminder, the question is
whether cookies without 1-n cookie domains is suitable for "Proposed
Standard" according to RFC 1602.
Despite the vigorous defense of this enhancment, I don't see
widespread support. The cookie draft has been under consideration for
many months without "1-n cookie domains", and "lack of 1-n cookie
domains" has not been raised as an objection by any of the reviewers
heretofore. So I'm inclined to believe that the 'rough consensus' is
that we should proceed without this feature, but would like to hear
from others.
Larry
Received on Sunday, 16 June 1996 16:17:57 UTC