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

Julian Reschke <> Sun, 10 January 2016 15:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0AE871ACDDF for <>; Sun, 10 Jan 2016 07:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dh3RCHpp07zJ for <>; Sun, 10 Jan 2016 07:46:27 -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 253731ACDE8 for <>; Sun, 10 Jan 2016 07:46:26 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1aII74-0006Pe-Tx for; Sun, 10 Jan 2016 15:41:02 +0000
Resent-Date: Sun, 10 Jan 2016 15:41:02 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aII71-0006Ou-JV for; Sun, 10 Jan 2016 15:40:59 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1aII70-0002Ss-0e for; Sun, 10 Jan 2016 15:40:59 +0000
Received: from [] ([]) by (mrgmx101) with ESMTPSA (Nemesis) id 0M35iN-1a1aSq47ux-00swhC; Sun, 10 Jan 2016 16:40:20 +0100
To: Mike Bishop <>, Barry Leiba <>
References: <> <> <> <> <> <>
Cc: "" <>, HTTP Working Group <>
From: Julian Reschke <>
Message-ID: <>
Date: Sun, 10 Jan 2016 16:40:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:XEw4b5wHnX/y45ffPQtgFcnvXk6JpRfpX4CfERU20lJl1DDT7zR HAw4lwjnbRbFmCG8GIut6HbbIyD2IOTygZytwuJNFxvTYpOLofVZ7UvJ6xXonLHyBJdyvBv 5K4Xj9MRkmMRZRbqYzeEsq1YRr2hocYrWaKNfk5BJp9PLHSzOUzTqqlJtlT2x7yez0bRTaZ fuvYhdjywV+Ld3yQEnJZg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:JLWW5xa6czE=:kI29zFvKRpGPOy2MFt5eOy 7fX4m54RmKSpVNlJYi2yuKaQ2sr6YPMVzf8GsCFI8/yb3fZkOfhZFzpCv2y07R3xwFanFAyRy ayRrWdvjEzJL0lKpSYB8n30jpmLRQ6k1BdaACDgwLCus6XHw1LH2v4N39/gSia5XuADyQ5Zxd FlFZ7lJPlB/5ZZ3P+W4/ZBL6tWaSIIF0yBh5fVdhqUkCoB9UiKyNL6HUrp//SZwoxVbuRbU0K QfrxaxIAbfLbanjdncRl0SEetRsNeGN6GP3fCvFZHaC+zoWJbCjUinX5Ce9yxi9da3PY4/rtu II7UAb1RL+4NKLNBLndBRBd1GyeWBFQErmOtAvsM38E0kZO495MNjJCugaKEeOEL6YVn00rfe skIQp2KegMrGAy3MqqLfq+BzzNzs4EGshfr7GTLqHpSeCL2jGnN9o6EnAVL1Bu9DbWQ7IEBAD CLI86zCGRBsjss6w5zY1QXpy3UH/C9KYUarPVPktPpkIK40TzoOLdSJxmX2GlFU+VE+FcJwv3 Mjd4OgdcBmx/GtZ0qrhZYEgSwq8AAriosI16pPTTpyT77LVWnV3QUx6AwG2r5YO4OkgW4bOfg Fm7+0ZGgp7vIsDrds55meEzw3Q60Z6UGs7zhB0H0L6P2xZhuUdl7fmyU/eAp1oOW4ITIqggQT 4sWw00CqkSKTXlSwVcSpE8QmKj2HTbjJAz7LTx5VO/5ZZNCLg+w+OpRt6+pBfXMZp4Ot+P7Sh WQtebAiEWB5xWDnikydMYnvGaf3RJTP484JIHgQxLgV7gU3MxC5Shz1hygjMx/G0qeyxIOlZE wG/ax2g
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.426, 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: 1aII70-0002Ss-0e cd4c1d42e68f2eddbe1b1d326ea914cb
Subject: Re: ABNF related feedback to: Re: AD review of draft-ietf-httpbis-alt-svc-10
Archived-At: <>
X-Mailing-List: <> archive/latest/30873
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2015-12-31 18:54, Mike Bishop wrote:
> "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.

Sounds right to me.

Any objections to changing this to simply "1"? Or do we want to change 
it to %s"t" (for "true")?

Best regards, Julian