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

Mike Bishop <> Thu, 31 December 2015 17:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 046AC1A895D for <>; Thu, 31 Dec 2015 09:57:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.012
X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gGpyi-eQTP0V for <>; Thu, 31 Dec 2015 09:57:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40CBC1A87F2 for <>; Thu, 31 Dec 2015 09:57:00 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1aEhRP-0001iT-8q for; Thu, 31 Dec 2015 17:55:11 +0000
Resent-Date: Thu, 31 Dec 2015 17:55:11 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aEhRH-0000wq-QS for; Thu, 31 Dec 2015 17:55:03 +0000
Received: from ([] by with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1aEhRF-0007Yz-Iv for; Thu, 31 Dec 2015 17:55:03 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=foGiivdwbthTA6t3Eh7mkJbtCHPnLJFwwlCYXET2FvI=; b=RSDzUU1fRoxOYEBnR+CNIpp4GsFOB/ULXn3W78FuMY1Tnu1XA3rQJg8Kj0H7w6+UhIuHyM7Yb9cX00zL0SLOv+FtLI64hON6W/RtpkOHKKeQ0KDWsAGX59IkT6bHv9knC6ORp9uvHQBZJt6bPDwHIYE2J+MWBQCNZw841mJWQ1k=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 31 Dec 2015 17:54:33 +0000
Received: from ([]) by ([]) with mapi id 15.01.0361.006; Thu, 31 Dec 2015 17:54:33 +0000
From: Mike Bishop <>
To: Barry Leiba <>, Julian Reschke <>
CC: "" <>, HTTP Working Group <>
Thread-Topic: ABNF related feedback to: Re: AD review of draft-ietf-httpbis-alt-svc-10
Thread-Index: AQHRQ/MT2fgtHTrYp0eN5OnRNa3SH57lXnAQ
Date: Thu, 31 Dec 2015 17:54:32 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:1::28f]
x-microsoft-exchange-diagnostics: 1; CY1PR03MB1376; 5:YMA9SEfXeVbxS5XG+IaQh6N9wURDKPCEUSbCvXYdWjVZu6gseyNhm4GeyeTQa4a7zVfiCH86fWloJg9ILyhw5DxMgnPiOxQcCARHM1WuOdqg/xJF8Gd0nMc2o04l4BZRxtwgZLrvsHuULaUfQO4hwQ==; 24:Abgmdux+c4x+sSrgws2UjCK7oE8geuUIDQXlLiQazh5Ywkdj72AFVoPxFLd1oywug2igaSqCr74l90gmSX2E86mINbMM+VCEbfBd7tIED5c=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB1376;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:CY1PR03MB1376; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB1376;
x-forefront-prvs: 08076ABC99
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(189002)(52314003)(377454003)(19580405001)(54356999)(97736004)(74316001)(40100003)(5002640100001)(122556002)(2950100001)(19580395003)(189998001)(87936001)(5001770100001)(586003)(102836003)(81156007)(4326007)(5008740100001)(11100500001)(5004730100002)(1220700001)(230783001)(6116002)(76576001)(8990500004)(76176999)(101416001)(1096002)(50986999)(10090500001)(2900100001)(5005710100001)(5003600100002)(10400500002)(33656002)(92566002)(10290500002)(86612001)(93886004)(86362001)(106116001)(99286002)(106356001)(105586002)(5001960100002)(77096005)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB1376;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2015 17:54:32.8749 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB1376
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-2.376, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1aEhRF-0007Yz-Iv 19c27a67ad9697af828c849f50d9a914
Subject: RE: ABNF related feedback to: Re: AD review of draft-ietf-httpbis-alt-svc-10
Archived-At: <>
X-Mailing-List: <> archive/latest/30839
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

"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: [] On Behalf Of Barry Leiba
Sent: Thursday, December 31, 2015 9:41 AM
To: Julian Reschke <>
Cc:; HTTP Working Group <>
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.