> On Apr 25, 2017, at 8:31 AM, Salz, Rich <[email protected]> wrote: > >> >> There's no reason for an RFC to describe trivial lists of pairs. > > Sure there is, because folks will want whitespace, want to linearize it, > support Unicode, etc.
As soon as you ask for a generally applicable syntax you end with ASN.1, JSON, XML, ... There's no shortage of power tools, but our needs here are trivial, and the sensible thing to do is to specify the simplest grammar that meets all the needs. * No nested lists * No multiple objects * No DTDs * No separate string, array, integer types * No complex libraries with CVEs (https://www.suse.com/security/cve/CVE-2015-8863/) Parsing a line that contains a key and a value is trivial. There's a bit of mostly irrelevant bike-shedding over whether that syntax should be: <KEY> 1*<WSP> VALUE 0*<WSP> <CRLF> or <KEY> 0*<WSP> = 0*<WSP> <VALUE> 0*<WSP> <CRLF> where <CRLF> is either of <CR><LF> or just <LF>, and each character of KEY and VALUE is ASCII alphanumeric or one of ".", "-", "+". The value encoding is "xtext" from https://tools.ietf.org/html/rfc3461#section-4, but none of the STSv1 keys require or shall permit hex-encoded xtext characters. Thus "+" may appear only in presently ignored keys from some future update of the protocol in which some additional policy element requires extended characters. Therefore parsers don't need, and will likely never need to actually implement xtext, that's just there to avoid objections that we may need (however unlikely) something more general some day. Speaking of extensibility, I don't see any reasonable migration path from STSv1 to STSv2, except by changing the .well-known URI, in which case putting the version in the policy, rather than the URL is of little value. I doubt any site will want to shut out all the deployed STSv1 clients by switching to a hypothetical STSv2. Therefore, we can either put a list of supported STS versions in the DNS TXT record or live with STSv1 for ever (likely the simplest approach, just add more key/value pairs as needed and maintain a backwards compatible interface). A needlessly complex alternative is either multiple blocks of key/value pairs separated by a blank line with block specific to its own STS version, which must come first, or, worse still, a list of JSON objects. -- Viktor. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
