Re: [art] Against BCP 190

Adam Roach <adam@nostrum.com> Tue, 23 July 2019 15:46 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A571203DD for <art@ietfa.amsl.com>; Tue, 23 Jul 2019 08:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
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 KMwYhhOYOU94 for <art@ietfa.amsl.com>; Tue, 23 Jul 2019 08:46:40 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2DB12031D for <art@ietf.org>; Tue, 23 Jul 2019 08:46:32 -0700 (PDT)
Received: from Orochi.local ([196.52.21.210]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6NFkSDW091717 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 10:46:30 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563896791; bh=qFpHxhAlXPy944rKVaJ2X5odDTxM/rOe7iCkUOBdb/E=; h=Subject:To:References:From:Date:In-Reply-To; b=NVrBYmM6X1Np1a7rpIqnCKYlXVhAU+xB7FttZTtbtgE/8NQn608efBxW/DbKA4BeE /xXluLkveYK9awOgIM5OZWQqiN9ZotQEQcc19KkcAM5iM9SNmk5whq988iJSrblVEU MzFHAUbYPixVSm5hI5E1repaL2ok7LLZrsSnnGH0=
X-Authentication-Warning: raven.nostrum.com: Host [196.52.21.210] claimed to be Orochi.local
To: Leif Johansson <leifj@mnt.se>, art@ietf.org
References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <6.2.5.6.2.20190713054207.0bbd9b58@elandnews.com> <008901d5410d$90607b00$b1217100$@gmail.com> <529b1f23-75e7-c426-f884-8dd07825182d@nostrum.com> <f834b9cd-0dff-7725-a959-6514c22d3ae4@mnt.se> <eb6485fa-d3dd-8eb9-7886-b17ef9d10f81@nostrum.com> <1e6e3567-59d8-b868-4917-603b848ae984@mnt.se>
From: Adam Roach <adam@nostrum.com>
Message-ID: <c8e5c099-fd38-e206-7145-81eb2b3d467a@nostrum.com>
Date: Tue, 23 Jul 2019 11:46:28 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <1e6e3567-59d8-b868-4917-603b848ae984@mnt.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/ZjPZei_0VV2I4zRaWzbXhvbngdY>
Subject: Re: [art] Against BCP 190
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 15:46:49 -0000

On 7/23/19 11:28, Leif Johansson wrote:
> I am having trouble articulating the sense of unease I am feeling
> over this issue...
>
> The best I can muster right now is this: Reading section 2.3 of BCP190
> I see nothing whatsoever that speaks to the interoperability concerns
> that motivate the normative language in that (or for that matter any
> other) section of BCP190.


The purpose of BCP 190 has never been to provide advantages to protocol 
designers. That is, in fact, the opposite of its purpose. The purpose of 
BCP 190 is to provide protections to the URI namespace and the people 
who own its governance (e.g., domain owners) against protocol designers. 
It's effectively a restatement of the well-understood principle of 
"don't squat on protocol codepoints," but spelled out in terms of URIs. 
 From that perspective, it is always going to be vaguely adversarial to 
protocol developers, in the same way that IANA registration policies 
more strict than "First Come First Served" are: its job is to protect a 
common resource against having parts of the URI namespace carved off for 
the exclusive use of one protocol or another.

/a