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

"persist" could as easily be a toggle; either present or not, no value.  However, the existing syntax doesn't permit that, so we defined it to be =1.  In this situation, I don't see a problem with hard-coding the value into the syntax.

Fundamentally, the question is, "If I see persist=2, what should I do with it?"  If I treat it as an unrecognized value, then it's equivalent to not being present, which may or may not be what the sender wanted.  That means whoever is defining persist=2 would probably have done better to define morerefinedpersist=1-4, and leave persist intact for legacy clients to understand.

If you're going to have to define a new token for other values to be useful anyway, let's formalize that and hard-code that there's only one acceptable value for this one.

-----Original Message-----
From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba
Sent: Thursday, December 31, 2015 9:41 AM
To: Julian Reschke <julian.reschke@gmx.de>
Cc: draft-ietf-httpbis-alt-svc@ietf.org; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: ABNF related feedback to: Re: AD review of draft-ietf-httpbis-alt-svc-10

>>>> 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:55:03 UTC