RE: Comments on the new cookie draft

>Could you please cite a line or phrase that says that?  I don't intend to
defend
>Netscape's specification, which heaven knows lacks gobs of detail, but I
don't see
>any mention of unrecognized a-v pairs, or what to do with them, as you imply.
 I do
>see that NAME=VALUE is the only required attribute, and there's (IMO) a
subtle
>suggestion, by virtue of its being described first and used first in all of
the
>examples, that it's the first a-v pair.

In which version of their specification? There have been a number. The
latest I am aware of is at
http://home.netscape.com/newsref/std/cookie_spec.html. The following
pseudo-BNF is included:
Set-Cookie: NAME=VALUE; expires=DATE;
path=PATH; domain=DOMAIN_NAME; secure

It includes only one NAME=VALUE, nor does it indicate that *(NAME=VALUE)
is allowed. Furthermore common practice had become to only include a
single NAME=VALUE pair, a practice that all of the examples in the
specification adhere to. In addition as it would have been illegal to
include multiple Set-Cookie headers (please refer to section 4.2 of
RFC1945) implementers, both on the server and client side, assumed that
only a single NAME=VALUE was allowed. Note I say assume. Without
guidance from the spec, implementers had no choice but to assume.

As for a "subtle suggestion", one does not suggest or infer in a spec,
one states. Netscape didn't. Specifications are a lot like the
constitution, those features not reserved by the specification to itself
belong to the implementers. This helps implementers avoid having to read
the spec writer's mind.

>If you send two headers out (and it's usually not the server *vendors* who do
the
>sending, but the *service authors*, I think, so there are many more of them),
you
>may get either one back.  So you have to be prepared to process either one
and
>handle it appropriately.  That sounds like twice the development work to me.

>Also, keep in mind the additional network traffic incurred by sending two
headers
>instead of one.

We are in the classic trade off situation, time vs space. We can save
space by having servers spend more time processing or visa versa. I
think we can safely ignore the issue of client processing time as it is
minimal. I also think the space issue isn't all that terrible as we are
talking about 14 bytes or so per message. So the key issue would seem to
be server resources.

		Yaron

>-----Original Message-----
>From:	Dave Kristol [SMTP:dmk@bell-labs.com]
>Sent:	Friday, February 21, 1997 11:54 AM
>To:	Yaron Goland
>Cc:	http-wg@cuckoo.hpl.hp.com
>Subject:	Re: Comments on the new cookie draft
>
>Yaron Goland wrote:
>> 
>> >I disagree that these are "illegally formatted cookies".  (To be precise
>> here,
>> >we're talking about Set-Cookie headers, not Cookie headers or "cookies".)
>>We
>> >are talking about Set-Cookie headers that contain unrecognized
>> attribute-value
>> >pairs.
>> 
>> Netscape's drafts allowed for ONE unrecognized attribute-value pair.
>
>Could you please cite a line or phrase that says that?  I don't intend to
>defend
>Netscape's specification, which heaven knows lacks gobs of detail, but I
>don't see
>any mention of unrecognized a-v pairs, or what to do with them, as you imply.
> I do
>see that NAME=VALUE is the only required attribute, and there's (IMO) a
>subtle
>suggestion, by virtue of its being described first and used first in all of
>the
>examples, that it's the first a-v pair.
>
>> This unrecognized attribute-value pair was to be the value of the
>> cookie. Therefore a cookie with multiple unrecognized attribute-value
>
>That's one possible interpretation of their vague spec., though, as I say, I
>find no
>mention of unrecognized a-v pairs.
>
>> pairs is illegal and an implementer is free to handle them anyway they
>> want to. A draft which depends upon how implementers handle an illegal
>> situation for which the specifications provided no guidance is, IMHO,
>> broken.
>
>[sore tongue]
>
>> 
>> >Almost a year ago we discussed introducing a new header for "new
>> >cookies" but decided against it.  I believe the main reason we decided
>> >against it was that servers would have to send both flavors for an
>> >indeterminate length of time.  Or they would take the easy way out and
>> >continue to send "old cookies", and we would never be able to accrue
>> >the privacy and anti-spoofing benefits of "new cookies".
>> 
>> Alas this is the fortune reaped by the wide spread acceptance of a
>> proprietary standard. At least with two headers the load on server
>
>[sorer tongue]
>
>> processing is reduced versus having to sniff for UAs in order to
>> determine how to format the cookie. Given that the crux of the issue is
>> the server vendor's needs, it would seem appropriate for them to
>> comment. Would they rather sniff UA strings to determine how to properly
>> format their cookies or would they rather be able to always send out two
>> headers and know things will work?
>
>If you send two headers out (and it's usually not the server *vendors* who do
>the
>sending, but the *service authors*, I think, so there are many more of them),
>you
>may get either one back.  So you have to be prepared to process either one
>and
>handle it appropriately.  That sounds like twice the development work to me.
>
>Also, keep in mind the additional network traffic incurred by sending two
>headers
>instead of one.
>
>Dave Kristol

Received on Friday, 21 February 1997 19:34:24 UTC