- From: Barry Leiba <barryleiba@computer.org>
- Date: Thu, 31 Dec 2015 12:40:45 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: draft-ietf-httpbis-alt-svc@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
>>>> NEW >>>> alt-authority = DQUOTE [ uri-host ] ":" port DQUOTE >>>> END >>> >>> In HTTP specs, we don't like to use DQUOTE unless the thing being quoted >>> used quoted-string syntax. >> >> I don't understand that. I particularly don't understand why we'd >> prefer to specify the content of the string only in the comment, when >> it's perfectly easy and clear to put it into the ABNF, and have it be >> verifiable. > > There's a two-step process here. > > First you need to parse the field value according to HTTP's quoted-string > rules. The *result* of that parsing needs to validate as > > [ uri-host ] ":" port > > There's (IMHO) absolutely no point to force this into a single ABNF > expression. OK: We'll go ahead and disagree on this, but I won't argue the point further. If anyone else has a comment, let's hear it. Otherwise, we'll go with status quo. >> 3. Do you expect a lot of additional values? Clearly not, if you're >> limiting it to ten possible ones. In that case, as above, I prefer >> when the ABNF is specific about it. Consider, for example, RFC 2045's >> definition of Content-Transfer-Encoding (in Section 6.1): >> >> encoding := "Content-Transfer-Encoding" ":" mechanism >> >> mechanism := "7bit" / "8bit" / "binary" / >> "quoted-printable" / "base64" / >> ietf-token / x-token >> >> Here, "mechanism" could have just been defined as << ietf-token / >> x-token >>, but enumerating the existing values in the ABNF is useful. > > I respectfully disagree. For me, (ab)using the ABNF to enumerate values (in > particular when they are extensible) is an anti-pattern. OK here too: as with above, status quo unless there are comments from others. b
Received on Thursday, 31 December 2015 17:41:13 UTC