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

Barry Leiba <barryleiba@computer.org> Thu, 31 December 2015 17:44 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D3A1A8949 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Dec 2015 09:44:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.29
X-Spam-Level:
X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxmsr0RhACmB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Dec 2015 09:44:52 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4D41A8948 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 31 Dec 2015 09:44:51 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aEhDz-0001Yz-Rb for ietf-http-wg-dist@listhub.w3.org; Thu, 31 Dec 2015 17:41:19 +0000
Resent-Date: Thu, 31 Dec 2015 17:41:19 +0000
Resent-Message-Id: <E1aEhDz-0001Yz-Rb@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <barryleiba@gmail.com>) id 1aEhDt-0001YE-B3 for ietf-http-wg@listhub.w3.org; Thu, 31 Dec 2015 17:41:13 +0000
Received: from mail-vk0-f53.google.com ([209.85.213.53]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <barryleiba@gmail.com>) id 1aEhDr-0007Ay-PH for ietf-http-wg@w3.org; Thu, 31 Dec 2015 17:41:12 +0000
Received: by mail-vk0-f53.google.com with SMTP id f2so179675862vkb.3 for <ietf-http-wg@w3.org>; Thu, 31 Dec 2015 09:40:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AZ/rtfLrpiYZHcTaA3QIXmNnUAOfVsTVGgpedhWNIk0=; b=uVW6TzlcfIVloLRpQeTVDjv0UPIO2EXxYcM+AUSipC6ITCJA45KtkX3ihGk4o7bWlg zTbrQUHtZAfjw3MPms8VL0m/lDcrspohdM/HyOvrl64wkhqD8vRvM3g10UwjsYikdhNI C7f+fnrRV1OZ3su8M5YYTsqVSMmhfVeDF0EcXyVxrtSypCYfOCN5wD9c4Zf51b3lFVJD l5XDKSYxfkYXtAGcIsPuuu4r1r143s03mmYgRUFCqlcWNLBf+YLrlx12ZM2pEHcRr2AW gdSM3cpALR3jbOFbXsABTU2krvbuCa2ovrTgQBTjbQUS5dH1miCMuda//7trS3tBX6w8 LUFw==
MIME-Version: 1.0
X-Received: by 10.31.150.215 with SMTP id y206mr8838195vkd.63.1451583645141; Thu, 31 Dec 2015 09:40:45 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.31.182.211 with HTTP; Thu, 31 Dec 2015 09:40:45 -0800 (PST)
In-Reply-To: <56855F2E.6020300@gmx.de>
References: <CALaySJK5fYy_JCv0Y7Fs3QpPk95fUxyt272JMc-QUpVKO7_gJA@mail.gmail.com> <56853BCC.7030005@gmx.de> <CALaySJJxbDX0m2XurAXe0+DoC4iDam8CXOv4B3Gr1+NGk+Nzow@mail.gmail.com> <56855F2E.6020300@gmx.de>
Date: Thu, 31 Dec 2015 12:40:45 -0500
X-Google-Sender-Auth: wjsGUvAMRZV0rGkQOzzt4Tyqzzc
Message-ID: <CALaySJJuX7geSJE99Wua_cD_O-5ek6p4uuG=OB2nbkrnYHQrYw@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: draft-ietf-httpbis-alt-svc@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.213.53; envelope-from=barryleiba@gmail.com; helo=mail-vk0-f53.google.com
X-W3C-Hub-Spam-Status: No, score=-7.7
X-W3C-Hub-Spam-Report: AWL=1.872, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: maggie.w3.org 1aEhDr-0007Ay-PH 8eea008b0dff3d00756089ad25e545c6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: ABNF related feedback to: Re: AD review of draft-ietf-httpbis-alt-svc-10
Archived-At: <http://www.w3.org/mid/CALaySJJuX7geSJE99Wua_cD_O-5ek6p4uuG=OB2nbkrnYHQrYw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30836
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>

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