Re: [Webpush] Breaking Changes (was Re: Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT))

Ben Campbell <> Wed, 16 August 2017 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9870A1323F7; Wed, 16 Aug 2017 08:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WE2dl2dU5pUK; Wed, 16 Aug 2017 08:03:58 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52F20132430; Wed, 16 Aug 2017 08:03:43 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v7GF3buu065510 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 10:03:38 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Wed, 16 Aug 2017 10:03:37 -0500
Cc: Adam Roach <>, Eric Rescorla <>, draft-ietf-webpush-vapid <>, Phil Sorber <>, The IESG <>,, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [Webpush] Breaking Changes (was Re: Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT))
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Aug 2017 15:04:00 -0000

(Oops ignore the empty message—itchy mousepad finger. Or maybe I want to make sure Martin gets everything twice.)

> On Aug 16, 2017, at 1:22 AM, Martin Thomson <> wrote:
> On 16 August 2017 at 15:41, Adam Roach <> wrote:
>> On 8/16/17 12:09 AM, Martin Thomson wrote:
>>> p.s., It's been a while since I've been on the receiving end of the
>>> old "your code doesn't matter, you took a risk implementing an I-D"
>>> argument.  As an argument it kinda stinks.  I'm embarrassed to confess
>>> that I've used it in the past, despite reminding myself not to.  I'd
>>> be interested in learning whether the IESG has an opinion on the
>>> subject.  A statement of policy might be valuable.
>> Given that the alternative is effectively forbidding breaking changes after
>> WG adoption -- which is clearly untenable -- I'm not sure what kind of
>> policy you're looking for here. Can you clarify?
> (Hmm, I got this message twice...)
> The usual exchange goes a: "I have code", b: "you implemented an I-D,
> that's your problem".
> Some guidance about how to manage this situation would be appreciated.
> I'm not looking for a prohibition on changes at any point in the
> process.  That's ludicrous, after all, people do understand what it
> means to implement an I-D.  But statements like "there is code" or
> "there is deployed code" are valid and useful input to a discussion
> and not just as proof that a given thing is possible.  That means
> potentially affecting the outcome of a decision.
> In this particular case, the arguments presented weren't problematic,
> because the real arguments was actually "well, this change doesn't
> seem that bad to me".  But it's not the first time someone has opened
> with that argument and it annoyed me enough to comment.

From a general policy perspective, I think there are two principles:

1. The IETF maintains change control on IETF stream documents. That suggests we can change things at any time.

2. Working code matters.

How you balance the two depends on the context. We encourage early code. But that’s not necessarily the same as encouraging going production with early code. It’s reasonable to push back on gratuitous changes if code demonstrates things already work well. But I think the usual basis of such an argument is that the existing protocol has been proven to work as is, not that the weight of that code makes it too hard to change.

 It’s reasonable to argue that, while a new feature may be of value, implementors will not deploy it because <arguments>. That seems to happen more often with security features than other things, maybe because the IETF as a whole cares more about security than many deployment communities. But that’s not really an “existing code” argument per se (although existing code can contribute to it.)

There’s a difference between when we choose to standardize something already in wide deployment, vs when we invent something new and people deploy code based on drafts. But even that doesn’t mean we can’t change anything (see principle 1)

 But in any case, I agree that existing implementations/deployments and their scope are proper inputs to the discussion. But they are not trump cards.