Re: [art] Against BCP 190

Victor Vasiliev <vasilvv@google.com> Tue, 23 July 2019 17:09 UTC

Return-Path: <vasilvv@google.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 368D712046E for <art@ietfa.amsl.com>; Tue, 23 Jul 2019 10:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 GSVcoY3b2vx6 for <art@ietfa.amsl.com>; Tue, 23 Jul 2019 10:09:23 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 25525120446 for <art@ietf.org>; Tue, 23 Jul 2019 10:09:11 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id m23so41723934lje.12 for <art@ietf.org>; Tue, 23 Jul 2019 10:09:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xS+ZkpIZnsfF3zr/tYpwT6/8vgI1zErg9jzkXHxNwug=; b=v3L+0By3FtA6te+7S8rJova8Q3Uyg70znpuokKi7RXLcoxk77812/qxFzuCDQaONiV AK6I1MQHB9okwzW+rmQV+VnfHNU+1xg4djL396fZJV4s7d19OkOca+ulAT3MxZDhkV8D YXjv/fHTe3Oji//vRhfKghxuDj3wFnR0MBJeGjYQ8fJRQkJb39d0/zkoIOvsU3P5zrpc fTydj1+6ZRk+EKAmODxY0SvBK9rV3i4MlXpqpKEXA6NWTeqJKGtX6qasDombekjhOBud DoOelBnHaHmv41DMzmrerW/XEDpC7GK9imCHeiDCAXVRJYVNqWm+ro9cMEqbTEU00haT 5h0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xS+ZkpIZnsfF3zr/tYpwT6/8vgI1zErg9jzkXHxNwug=; b=VhBAMuEEEPq3QDyxk5yGnT1trqq7XN6S2STR6OJmo/NOgs2TKsWUyoRBwCFM4HbhRB eYyrADoMgoL05HbGbGVC3oFAFzLIGOoqgL5R4vUg1NhgHg3ZCGeR5S0gy1mdT0PQlskq 7O4+Xv8Xa1NYJYMZePza3SLoASrlRfplpl34Ev47qIgPojXrlY+4/Tau4YLDrWjfdeeC OrNYSOogSgVW+Liu9cZDwzm86VOJHcT4Bwz4oppLJZe32FMN2mIDNVt9tOrkj4HBST9a UndguKfHg8TRouROQiqjw6rTBNixoBeUFpAhgiDnsXDCcWNxCiFkM+p4ymNEHDscvVOJ baqQ==
X-Gm-Message-State: APjAAAUBDWeyusoo8NMkiX7ysUiyU3z2kw6vpnEJxUhZlkJzW0lKftNu Ur45O05fccQz+ITOqHUuFRlr44NhQ1pVEwGm7e4wOhIaW2NQ7w==
X-Google-Smtp-Source: APXvYqwQZdziiRSDyUpbyCIfIPg6j+JTDTogjkOR/gRIz9mTGKA4/FLLH2sTq5eaDg1loMMwT2d3WKTi916svlQbjFg=
X-Received: by 2002:a2e:b1c1:: with SMTP id e1mr5014161lja.228.1563901748943; Tue, 23 Jul 2019 10:09:08 -0700 (PDT)
MIME-Version: 1.0
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> <c8e5c099-fd38-e206-7145-81eb2b3d467a@nostrum.com>
In-Reply-To: <c8e5c099-fd38-e206-7145-81eb2b3d467a@nostrum.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Tue, 23 Jul 2019 13:08:57 -0400
Message-ID: <CAAZdMadgRJ4GHoNSwy57n9p9Q9MVwNCk_4BEvaxyVLBCwmDLKw@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Leif Johansson <leifj@mnt.se>, art@ietf.org
Content-Type: multipart/alternative; boundary="000000000000362301058e5c40b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/Wjy1xEpfHupOCLJsLik3Zk74dgw>
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 17:09:26 -0000

I don't buy the ownership argument here.  I have an electric kettle in my
room that I bought myself; I own it in every practical sense of that word.
The kettle has a power connector that has to comply with the NEMA standards
in order to be pluggable into most wall sockets around the US.  The fact
that it has to follow those standards in order to be practically operable
doesn't mean that NEMA "usurped" (as BCP 190 puts it) my kettle from me.

I can see the argument that assigning a top-level paths for every website
(e.g. favicon or robots.txt) is harmful, and I agree that we should use a
well-known prefix (/.well-known/) and an IANA registry for those.  However,
paths are inherently hierarchical in nature.  Owners can delegate subpaths
to other owners, for instance. a college webserver can delegate a /~user/
path to individual users.  In the same manner, an owner can delegate a
portion of its path space to an IETF standard.

There are a lot of technical considerations in BCP 190 about why web
application should not do path-based APIs (e.g. it runs on a shared web
hosting that does not support this).  However, those are practical
technical considerations (rather than administrative namespace management),
and as such should not be a MUST-level requirement enforced by the IESG.
It *is* important that the application designers are aware of those
considerations, but they are still the best experts on whether those
considerations actually apply to the protocol in question.

The restriction on query strings similarly has no namespace maintenance
purpose, and should be downgraded to a recommendation.

I guess my biggest issue with BCP 190 is that it diverges with how the
HTTP-based APIs are usually designed around the industry.  Between the
older-style APIs based on query strings, and newer-style APIs utilizing
different paths for endpoints, there is a wide range of commonly used APIs
that violate BCP 190.  This is not only problematic from theoretical side
(if you believe that running code reflects rough consensus), but also
hinders the progression of interfaces from de-facto standards to actual
IETF documents.

Because of the considerations described above, I believe we should relax
the restrictions in BCP 190, by clearly separating the matters of avoiding
namespace collisions (which can remain a MUST), and matters of operational
nature (which needs to be a SHOULD).


On Tue, Jul 23, 2019 at 11:47 AM Adam Roach <adam@nostrum.com> wrote:

> 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
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>