=JeffH wrote:
In talking with a couple folks in the past few days, it seems that there
already is some thinking about adding some additional directives (aka
"header
field value tokens") to the STS header field. One such idea is an
"EVonly" flag with nominal semantics of "accept only an EV cert".
In general, having a header field (or any protocol element) that is a
syntactic
moving target is an issue because of the "what to do about deployed
implementations? will they break?" question.
I noticed a suggestion (included below at end of this msg) from Hixie
wrt BNF
techniques to address this sort of situation without employing explicit
versioning information in a header field syntax (or any other BNF based
syntax)
This seems interesting to me, so I hacked up the below sample syntax to see
what it looks like. Seems like it might be workable, tho it would add a
fair
bit to a spec both in terms of syntax specification but also explaining the
technique. But, adding explicit versioning is also a pain.
Below's a couple of quick examples/experiments with re-coding the STS
header field ABNF grammar using Hixie's ideas.
thoughts?
...
Isn't that simply the standard approach used in many IETF specs with
respect to defining an extensibility point (except it's usually prefixed
"ext", not "invalid")?
BR, Julian
