W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

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

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Thu, 31 Dec 2015 17:54:32 +0000
To: Barry Leiba <barryleiba@computer.org>, Julian Reschke <julian.reschke@gmx.de>
CC: "draft-ietf-httpbis-alt-svc@ietf.org" <draft-ietf-httpbis-alt-svc@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <CY1PR03MB1374B3703C8BBB1023F9F55D87FE0@CY1PR03MB1374.namprd03.prod.outlook.com>
"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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC