Re: draft-west-cookie-prefixes-05 comments

On 3 December 2015 at 09:16, Mike West <mkwst@google.com> wrote:
> Hi Eitan!
>
> On Thu, Dec 3, 2015 at 1:49 AM, Eitan Adler <lists@eitanadler.com> wrote:
>>
>> I have some comments about the draft-west-cookie-prefixes-05 draft:
>
>
> Great, thank you for taking a look!
>
>>
>> The syntax is ugly, but extensible without having to introduce
>> additional extension points.
>
>
> I'd be interested in hearing about the use cases for other prefixes, but I'm
> hopeful that we won't need/want to add many prefixes. The two defined in
> https://tools.ietf.org/html/draft-west-cookie-prefixes seem to close the
> most pressing gaps.

Ideally we won't need any other prefixes.  That said, the RFC should
be explicit about this.

>> I'm concerned about the use of __ for both
>> regular cookies and special handling cookies (such as __host and
>> __secure).
>
>
> What do you mean here? You're concerned that magic cookies like
> (`__SECURE-whatever`) and boring cookies (like `__utma`) can both start with
> "__"?

Yes. See below.

>> I'd like to see the prefix changed to one which it can be specified
>> that conformant implementations MUST NOT use a prefix other other than
>> those defined by an RFC.
>>
>> Perhaps __-SECURE and __-HOST can be used? note the additional "-"
>
>
> I don't understand the concern. What dangers do you see in the current
> syntax? How does adding an additional `-` resolve them?

When some prefixes can cause semantic changes and others are treated
as special it causes complexity in parsing, and in general
understanding of the system.  The proposal to add a "-" or any other
not-currently-used prefix is to make it clear that the prefix has
special meaning.

In other words its the difference between

 - All cookies that begin with "__-" are special
vs
- Some cookies that begin with __, __SECURE, and __HOST, have special
meaning, but most don't.

This isn't a purely technical argument -  no known implementations
will break - but an argument to reduce complexity.

Another concern is that in the unlikely event we will want another
prefix other than SECURE or HOST we won't need to scour the web to
ensure that the newly defined word isn't already used.


-- 
Eitan Adler

Received on Thursday, 3 December 2015 14:48:52 UTC