Re: p2: Expectation extensions

Mark Nottingham <mnot@mnot.net> Tue, 23 April 2013 22:16 UTC

Return-Path: <ietf-http-wg-request@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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2759D21F93AA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 15:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.516
X-Spam-Level:
X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15d4ttDzEjv3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 15:16:08 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2279921F939C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 15:16:07 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUlTv-0005rX-9i for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Apr 2013 22:14:35 +0000
Resent-Date: Tue, 23 Apr 2013 22:14:35 +0000
Resent-Message-Id: <E1UUlTv-0005rX-9i@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UUlTq-0005qo-Ne for ietf-http-wg@listhub.w3.org; Tue, 23 Apr 2013 22:14:30 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UUlTp-0007To-Uj for ietf-http-wg@w3.org; Tue, 23 Apr 2013 22:14:30 +0000
Received: from [192.168.1.80] (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A9E6850A84; Tue, 23 Apr 2013 18:14:07 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <51769362.808@treenet.co.nz>
Date: Wed, 24 Apr 2013 08:14:01 +1000
Cc: ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <160E1A34-AAD2-4A3B-9873-913B5BCE8955@mnot.net>
References: <0509CFF1-0A48-46D9-93F0-5CEF60A9DE37@mnot.net> <51769362.808@treenet.co.nz>
To: Amos Jeffries <squid3@treenet.co.nz>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.384, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UUlTp-0007To-Uj 3458f458df22d8136471d38e9446d4ae
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p2: Expectation extensions
Archived-At: <http://www.w3.org/mid/160E1A34-AAD2-4A3B-9873-913B5BCE8955@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17511
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 23/04/2013, at 11:57 PM, Amos Jeffries <squid3@treenet.co.nz>; wrote:

>> Given how many problems we already have with Expect, should we consider disallowing further extensions here, and removing this requirement?
> 
> So whats gained by making it an expectation if the expectation is ignored? nothing.
> 
> Removing it also removes the fail-closed property of Expect:. I know the property is a great annoyance to new featrue rollout. But it does offer the concrete assurance that what is expected is supported which is quite useful when designing security related extensions. We have the Prefer header coming up to provide the expectation negotiation with fail-open semantics.

Disallowing future extensions recognises that interop on this feature is low -- i.e., that deploying an extension here isn't likely to work well. I don't see much in the way of "concrete assurances" through its use at all, as a protocol designer; only a lot of nasty problems.


--
Mark Nottingham   http://www.mnot.net/