[art] On BCP 190

Mark Nottingham <mnot@mnot.net> Tue, 23 July 2019 18:14 UTC

Return-Path: <mnot@mnot.net>
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 3F48812078A for <art@ietfa.amsl.com>; Tue, 23 Jul 2019 11:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nOxW+t35; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CBDrb8r8
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 2WtVG8scdZoH for <art@ietfa.amsl.com>; Tue, 23 Jul 2019 11:14:41 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4669012078B for <art@ietf.org>; Tue, 23 Jul 2019 11:14:41 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8482021DFB; Tue, 23 Jul 2019 14:14:40 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Jul 2019 14:14:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm3; bh=WH+nFe8SfezhlBfJW1G34LLV7OVSak 4HUSC153vdAoE=; b=nOxW+t35+hmTR9GW4pD/M0ziZXRTXRlczk/qESfAzdS4nb gQUeBylCJ06QYc/RnSvg/V+HZInR+/6kmvT3v8OdVSIm1IK+CeczarCYrUwUKf9y VtbAU28dUGCO+ZwFwfwEhXXFBUH0EZHibvkt4k5/oXjVPrOdrnfBEiruDJSFex9r vZrvSI0S/XEYkv3SpPxC8jBDBzpqlIw6HDW9p50me7AXJcBhvKCnitUly1Hb0V6a dJAJ21k0FLVZTCvNp8kYX86b39+Fh1RSW0gzDMX3YfBX/+eR4YX1vyBYbuVemegb O7eN4cSPvLebaJabPoOdPYqao80j4duKnH+TQUEw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=WH+nFe 8SfezhlBfJW1G34LLV7OVSak4HUSC153vdAoE=; b=CBDrb8r8k9Ojdpr8gG+QUl lqxnsbCaiRfbYX+KQcBjL5sWcYAW7i3jXvMwtqYKwSFhMmlmSAOZPo4j8UbL1N+B pHyHYYS9vaWBzqrp5yUi9JMSqAMSv/8r2+mvD+yO4KwyIA4wfU1/fJLTgiRB0Mp/ hN5rI9ZcO/By8poRaLTmk9KNtB9lgmDzKGc3Y65X91sphkJ3JSBC+Ha6YILYsamh StwBpk7C6/ElvMFvexqLm69BDGB6gYEl9A6Mt6G0cRpzIiGY/A6hKLxBF05tMQXr W+VDejmxGbbSsJDZn9q5T/nRZUHDjPWZMVgyi/Ok/l4PGj4MZVrZTTbq8y2FtUWA ==
X-ME-Sender: <xms:j043XdgKCzqMWruakhL7dFE_AsEuaTq5xefaxeq6VlBLAHpvSIyRoA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrjeekgdduvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepth ifihhtthgvrhdrtghomhdphhhtthhpfhholhhkshhinhhvohhlvhgvughinhhthhgvshgv phhrohhpohhsrghlshgvrghrlhhivghrrdhimhdpmhhnohhtrdhnvghtnecukfhppeefud drudeffedrudefjedrvdefgeenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehm nhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:j043XXzzt9xTQxI0qI-EJnT7J12NBiUJ5NigoyjpzuZ7Cc_lTkPr3g> <xmx:j043XT61krLdjNSPTGBC4qVsNtZklUnWXdtNDB5d4HLnWDVwmOCYYA> <xmx:j043XZd2BWx64aYf9yjza6OUnmaTkMkqOldPqyH2xPrP15kmor8SHg> <xmx:kE43XYMiupBxyKSuQroyg_fXYJlSdZLF-r_eQj_ZEqUVjdppJfwoxw>
Received: from dhcp-89ea.meeting.ietf.org (dhcp-89ea.meeting.ietf.org [31.133.137.234]) by mail.messagingengine.com (Postfix) with ESMTPA id D687B380085; Tue, 23 Jul 2019 14:14:38 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net>
Date: Tue, 23 Jul 2019 14:14:36 -0400
Cc: Devon O'Brien <devon.obrien@gmail.com>
To: ART Area <art@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/4UudZS9PTIdKl7kyKtCpEZYzal0>
Subject: [art] On 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 18:14:46 -0000

Hi,

I've been watching the discussion of BCP 190 with interest. It encompassed what we though were good principles in 2014; we've learned a lot more since then, and it could be time to revise some parts of the document*.

However, there's some context that I think is important for people to be aware of. Namely, HTTP's primary use case is the Web, not making the lives of people who have decided to base IETF protocols on it easier (although that's a good secondary goal). When you choose to adopt it to get a job done, it's reasonable to ask it not impact other use cases unduly -- especially the primary one. Even if a protocol is deployed on dedicated standalone servers, how they use URIs deserves scrutiny -- both because HTTP works best when you work with it, and because it sets a precedent that becomes easier to repeat the more it happens. 

In short, I'm not concerned about *this* IETF specification violating the BCP, I'm concerned when there are 1,000 specs that do so (which may not be that far away, given how many specs are being built on top of HTTP). 

BCP190 has a tough job, because it's trying to address against erosion of a commons. That job is made more difficult because best practices for designing HTTP APIs are still in flux, and common practices for an API that's implemented once and deployed on one server that's under the control of the designer (e.g., api.twitter.com) are often not appropriate for an API that is implemented many times, deployed on many servers owned by different people, and sometimes evolved independently (as standards and their extensions often are). However, I continue to believe in general it's important to restrain how standards define URIs; while I understand that it's annoying to protocol designers who just want to get their jobs done, it's important to remember that portions of the URI space are controlled by server owners, not us, and a single-hostname-per-service-type model isn't great.

With all of that said, IMO there are always going to be exceptions, based upon circumstances; the important thing is that they're discussed and thought through. We probably need better communication and support for that; BCP56bis will hopefully help, but we also need to get HTTP folks involved in these proposals earlier.

I'm talking to Devon about the specifics this afternoon, and hopefully we'll come out with a concrete proposal one way or another. After that, it'd be interesting to hear what people think about adjustments to the guidance in 190. I have some ideas that I might scribble down in a draft, in my copious spare time.

Cheers,

* Or subsume the topic into BCP56bis? /cc Tommy, Patrick

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