Agreed, just write the syntax so that it specified a MIME header-ish tag-value list. Then define the tags and the syntax of the corresponding values separately.
That makes it much easier to extend the protocol at the API level since the API can simply deliver the tag-value list to the caller. Hasn't this been specified somewhere already? On Sun, Sep 25, 2011 at 8:34 AM, Julian Reschke <[email protected]> wrote: > On 2011-09-14 23:08, =JeffH wrote: >> >> > a few questions about the header field syntax: >> > >> > Strict-Transport-Security = >> > "Strict-Transport-Security" ":" OWS STS-v OWS >> > >> > So the header field is *not* using the RFC2616 list syntax. So you >> can have >> > >> > Strict-Transport-Security: a; b >> > >> > but *not* >> > >> > Strict-Transport-Security: a >> > Strict-Transport-Security: b >> > >> > because that would be equivalent to >> > >> > Strict-Transport-Security: a, b >> > >> > (is this intentional?) >> >> well, it was not necessarily intentional as far as I recall. We either >> managed to overlook, or regarded as inappropriate for this header, the >> RFC2616 list syntax (i.e., the "#rule"), that defines such implicit >> comma-separated lists. >> Also, we'd noted that quite a number of header field definitions used >> semi-colons as a delimiter, but perhaps hadn't noted that those overall >> productions often are embedded within such comma-separated lists. > > Yes, that's the list-of-parametrized-things format. > >> However, in thinking about it a little bit, for this particular header >> field, as it's presently defined, it doesn't seem appropriate to have it >> explicitly be comma-separated repeatable (aka #rule), because only one >> instance of "S-T-S: max-age=n" is effective in terms of established the >> cached Known HSTS Host in the UA. > > In that case, as this is security related, you may want to talk about what > recipients are to do when (a) they *do* get multiple instances, and (b) when > an intermediate folds multiple headers using the comma syntax. > >> > Also in >> > >> > ; value >> > STS-v = STS-d >> > / STS-d *( OWS ";" OWS STS-d OWS ) >> > >> > ; STS directive >> > STS-d = STS-d-cur / STS-d-ext >> > >> > ; defined STS directives >> > STS-d-cur = maxAge / [ includeSubDomains ] >> > >> > having includeSubDomains optional is a bit weird. >> > >> > This means that the empty string would be a valid STS-d-cur, thus an >> > empty header field is allowed... >> >> Ah, thanks, yes -- i was unsure of how to make includeSubDomains >> optional while max-age is required, and that hack didn't work. >> >> I've now re-worked it as below -- how's that look? >> >> thanks again, >> >> =JeffH >> >> >> Strict-Transport-Security = >> "Strict-Transport-Security" ":" OWS STS-v OWS >> >> ; STS header field value; must have a max-age: >> >> STS-v = max-age >> / max-age *( OWS ";" OWS STS-d OWS ) > > ...which makes putting max-age first required. > >> ; additional STS directives: >> >> STS-d = STS-d-cur / STS-d-ext >> >> ; currently defined STS directives, >> ; delta-seconds is 1*DIGIT and is from [RFC2616]: >> >> max-age = "max-age" OWS "=" OWS delta-seconds [ OWS v-ext ] >> >> STS-d-cur = includeSubDomains >> >> includeSubDomains = "includeSubDomains" [ OWS v-ext ] >> >> >> ; extension points >> STS-d-ext = name ; STS extension directive >> >> v-ext = value ; STS extension value >> >> name = token >> >> value = OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or >> ; [ ! .. : ] [ < .. ~ ] any visible chars other than ";" >> >> token = 1*tchar >> >> tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" >> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" >> / DIGIT / ALPHA >> ; visible (printing) characters, except visible >> ; separators. >> ; DIGIT, ALPHA, separators are from [RFC2616] >> >> ; Basic rules: >> >> OWS = *( [ CRLF ] WSP ) >> ; Optional White Space >> >> WSP = SP / HTAB >> >> CRLF = CR LF >> >> ; CR, LF, SP, HTAB are from [RFC2616] >> >> >> --- >> end > > I think it would be simpler not to try to express this in the ABNF. > > Just use the ABNF to state the core syntax (that a parser will need to > understand), and then put additional requirements about what directives must > be there in prose (we're doing the same in HTTPbis, but aren't done yet... > :-). > > Best regards, Julian > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
