Re: [art] Against BCP 190

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
>