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

Julian Reschke <julian.reschke@gmx.de> Thu, 31 December 2015 17:05 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id DC8961A87AF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Dec 2015 09:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WjXDA-roNn2D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Dec 2015 09:05:50 -0800 (PST)
Received: from frink.w3.org (frink.w3.org []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111CF1A87A9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 31 Dec 2015 09:05:50 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aEgcs-0005yd-2K for ietf-http-wg-dist@listhub.w3.org; Thu, 31 Dec 2015 17:02:58 +0000
Resent-Date: Thu, 31 Dec 2015 17:02:58 +0000
Resent-Message-Id: <E1aEgcs-0005yd-2K@frink.w3.org>
Received: from lisa.w3.org ([]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <julian.reschke@gmx.de>) id 1aEgcl-0005xs-1E for ietf-http-wg@listhub.w3.org; Thu, 31 Dec 2015 17:02:51 +0000
Received: from mout.gmx.net ([]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <julian.reschke@gmx.de>) id 1aEgcj-0005eu-AD for ietf-http-wg@w3.org; Thu, 31 Dec 2015 17:02:50 +0000
Received: from [] ([]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LZzY9-1ZpGpL0Btl-00lpRD; Thu, 31 Dec 2015 18:02:13 +0100
To: Barry Leiba <barryleiba@computer.org>, Julian Reschke <julian.reschke@gmx.de>
References: <CALaySJK5fYy_JCv0Y7Fs3QpPk95fUxyt272JMc-QUpVKO7_gJA@mail.gmail.com> <56853BCC.7030005@gmx.de> <CALaySJJxbDX0m2XurAXe0+DoC4iDam8CXOv4B3Gr1+NGk+Nzow@mail.gmail.com>
Cc: draft-ietf-httpbis-alt-svc@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <56855F2E.6020300@gmx.de>
Date: Thu, 31 Dec 2015 18:00:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CALaySJJxbDX0m2XurAXe0+DoC4iDam8CXOv4B3Gr1+NGk+Nzow@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:XdUtljeG0A+l3C2P26Xmjf0LT3bhVt4bBu44G6UQJixW805j0ub lAqURlYLG3IIuHXkOd71LjyDPagQ6rphqVwwZziU9iWvMru5ED7I7eBPB4qENCM0T/tTamJ mxBc2ojABx21hkwmiiuBJE0DTH+tSFlyHfIAsSY9Z66O4hwwRFjdXCq/v8D7wqIoZTELXzT mz3IobRlGOa7XHycxplBA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:zU4SItgDBj4=:69MqSoBRg7UiAPzx92q4O2 XlGtUOnORenuvIKrW1h/zO546X8vPyBv8YooYu2/GTJIDkQcIRYPMOEYQgzl4nBfT5ealz8DP SNs6fBX4/FrZ8YTSymgtf0l/wum2pC4yLra3QGVEABHeyDWNPgnjXZvUP670RzPzSoqRUz+yC dx1h1MauTl/nFFy5KGbmY2qhiFebQD6E1+A4rJxEhgIOMTkBRkpuaGGN6Kxm/4BufaJyat+pf vL+cq9eCOCXiBVeY6+S6D11ZXtx72ajFSMYcGFtz9xZUw7Qn847lKWUxKByfIZSNyfI8HWeXS 1KHeKTNtLQ6C7MgyWZrj++Z0bBjNrvGcXlHZqTJSM1TRfZ+2YemEDPUSVRbYzysx4oDIX4ncV hdfIZxcovf50wXFoboHOLwee1fgKBS5LTwGyhO2wLbbqEW+t/nTzpDGvlxmcLSoCUb3jl+1n5 LIIZ6nfvYzgSQimw83gel6muMTVjMVN6janzvzrpxUtfLVG52wN2Bbely24SKieyueeNQVbNl 4XIJhJQOAxBkx41RQ9xqEQTBLQzUlWZ5PAeT2FYz40XfYdma6S49E13GvZYcvLSV/qpv/WxLm OHtg28UJDcjJHTFwT2fU3gLfBP7Gzyk4KsObavOPJHUpqSsxpV2yu5mRmID1uYT1Va2zc6vJ0 Jzzln747V0zfrd6KcBTV0TmswJm4WXGF3q7dgyMFC2LYq7eJosY2Pw6gsBt26KblsRi8fXIyf YM6Sd/EJIW0tQ0+i8IKldsHrzD63vsD7zlnSraTdFphhpmjdzpF1xYBMqsJLuCQhfFZ7e7rq9 deEiiNI
Received-SPF: pass client-ip=; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.427, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1aEgcj-0005eu-AD 6f5fa5d7ebd86a1625165c00a048c7d5
X-Original-To: ietf-http-wg@w3.org
Subject: ABNF related feedback to: Re: AD review of draft-ietf-httpbis-alt-svc-10
Archived-At: <http://www.w3.org/mid/56855F2E.6020300@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30835
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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 

> 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