- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 12 Aug 2015 08:16:54 +0200
- To: Mike West <mkwst@google.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 2015-08-12 08:09, Mike West wrote: > On Wed, Aug 12, 2015 at 8:05 AM, Julian Reschke <julian.reschke@gmx.de > <mailto:julian.reschke@gmx.de>> wrote: > > On 2015-08-12 07:57, Mike West wrote: > > Thanks again, Julian! > > On Mon, Aug 10, 2015 at 5:56 PM, Julian Reschke > <julian.reschke@gmx.de <mailto:julian.reschke@gmx.de> > <mailto:julian.reschke@gmx.de <mailto:julian.reschke@gmx.de>>> > wrote: > > ABNF is correct; I'd just use two different ABNF > productions for > parameter for clarity. > > > I don't understand how that would increase clarity. :) > > > Because somewhere in the prose, you'll be talking about the use of > these grammar elements, right? > > > In the current prose, there's no distinction between parameters. That > is, `Clear-Site-Data: a; b; c` has the same effect as `Clear-Site-Data: > a, b; c` and `Clear-Site-Data: a, b, c` and etc. > > That is, each header has a semicolon-delimited list of key/value pairs, > and we grab all of them when determining what to do. Then why do you have both comma and semicolon-delimited parameters? That sounds very confusing. > At the moment, this is super simple, because everything is just a bare > keyword whose presence is the only important thing. If we make things > more complicated later, we might need to be more stringent with our > processing. Best regards, Julian
Received on Wednesday, 12 August 2015 06:17:36 UTC