ABNF related feedback to: Re: AD review of draft-ietf-httpbis-alt-svc-10

On 2015-12-31 17:38, Barry Leiba wrote:
> Hi, Julian, and thanks for the quick reply on a holiday extended weekend.

Dito :-)

> ...
>>> -- Section 3 --
>>> Please consider using RFC 7405 for the ABNF for "clear".
>>
>> That would replace
>>
>>    clear         = %x63.6C.65.61.72; "clear", case-sensitive
>>
>> with
>>
>>    clear         = %s"clear"; case-sensitive
>>
>> (and add a dependency to the ABNF extension).
>>
>> I'm not super-excited about this notation, and it seems we would be the
>> first ones to actually use it (implying lack of validation tools etc).
>>
>> What do others think?
>
> It's a small thing, and it's up to the working group, of course.  I
> would prefer the change, because (1) I think it makes it more
> readable, and (2) we have put 7405 on the Standards Track, so we
> should use it.  It wouldn't be a bad thing for us to break ground on
> it.

I might invest a bit of time to teach bap (Bill's ABNF Parser) to accept 
this; and once I can validate it I could be convinced to actually use it.

>>>      alt-authority = quoted-string ; containing [ uri-host ] ":" port
>>>
>>> This seems poor.   Why not this?:
>>>
>>> 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.

> I'm generally not a fan of putting substantive ABNF information into
> ABNF comments, and prefer to reserve that sort of thing for cases when
> it's *not* reasonable to do otherwise.

It's in the prose as well:

"The "alt-authority" component consists of an OPTIONAL uri-host ("host" 
in Section 3.2.2 of [RFC3986]), a colon (":"), and a port number."

>>> -- Section 3.1 --
>>> For the persist ABNF, why 1DIGIT, and not just DIGIT?  Or, for that
>>> matter, why not simply "1" ?  Other specifications might then add other
>>> values using << persist =/ "2" >>, for example.
>>
>> I believe the intent was that new values do not imply changing the parser
>> (which would be implied by changing the ABNF), but simply would allow new
>> values here.
>
> Three questions here, really, bundled into one:
>
> 1. Why "1DIGIT", rather than "DIGIT"?  Purely editorial, of course...
> what's the benefit of using the "1"?
>
> 2. Why does "persist" have to be digits at all?  I'm generally not a
> fan of unnecessarily coding concepts into numbers, rather than using
> short words.  If it's necessary (or useful), that's fine.  I don't see
> why here.

I'll pass this to those who suggested the syntax :-)

> 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.

> And the fact is that "persist=2" is not currently valid.
>
> There's also, I suppose, the question of whether you'd want
> "persist=2" to be considered acceptable (and ignored), and "persist=a"
> to cause the whole field to be rejected as invalid.  If so, maybe
> this, to specify what's valid now and how to extend?:
>
>     persist = "1" / persist-ext
>     persist-ext = DIGIT ; extensions can be specified in future

That's a good question.

 > ...

Best regards, Julian

Received on Thursday, 31 December 2015 17:02:51 UTC