- From: Eitan Adler <lists@eitanadler.com>
- Date: Fri, 4 Dec 2015 15:54:23 -0800
- To: Mike West <mkwst@google.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 3 December 2015 at 23:33, Mike West <mkwst@google.com> wrote: >> > >> > Ideally we won't need any other prefixes. That said, the RFC should >> > be explicit about this. > > > What would you like the RFC to say in this regard? Something to extent of: cookie names that use the "special cookie" prefix MUST NOT begin with any text other than those described by an RFC. > >> >> > 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. > > > Another way of phrasing this is "All cookies that begin with `__SECURE-` and > `__HOST-` are special." I'd suggest that this rule is fairly easily > understood. > >> > 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. > > > Honestly, I see this as a benefit. Adding prefixes should be hard, and we > shouldn't do it often. Asking whether it's worth it to scour the web for a > suitable prefix seems like a totally reasonable hurdle to place in front of > implementers. My concerns are ones of cleanliness and extensability. If other extensions are highly unlikely to occur, and the list of special prefixes will be kept at exactly two, then my comments can be ignored. -- Eitan Adler
Received on Friday, 4 December 2015 23:55:24 UTC