Re: more flexible ABNF for STS?

=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

Received on Tuesday, 17 November 2009 20:55:18 UTC