Subject: [art] Against BCP 190

From: Rob Stradling <[email-masked]>
Date: Fri, 12 Jul 2019 16:45:31 +0000

During IESG review of RFC6962-bis (Certificate Transparency Version 
2.0), BCP 190 is creating significant problems in standardizing 
HTTP-based APIs.  Specifically, this paragraph of section 2.3 
(https://tools.ietf.org/html/bcp190#section-2.3):

    Specifying a fixed path relative to another (e.g., {whatever}/myapp)
    is also bad practice (even if "whatever" is discovered as suggested
    in Section 3); while doing so might prevent collisions, it does not
    avoid the potential for operational difficulties (for example, an
    implementation that prefers to use query processing instead, because
    of implementation constraints).

This paragraph should be struck.  It is out of date, since all modern 
web servers can trivially rewrite paths to query components and back 
again.  It also encourages inserting levels of indirection that add 
complexity and bugs.

In RFC6962, all paths are specified relative to a "log server" prefix 
that can contain a path as well as a server name and a port:

   POST https://<log server>/ct/v1/add-chain
   GET https://<log server>/ct/v1/get-sth
   GET https://<log server>/ct/v1/get-entries?start=1000&end=2000
   … 5 more request types defined similarly ...

This version of CT, which preceded BCP 190, has been in production use 
for several years, with multiple independent implementers on both the 
server side and the client side.  There have been no complaints that 
specifying paths in these ways is at all difficult or interferes with 
operation of other software.

A similar problem arose during ACME standardization.  At first it was 
solved by defining a "straight through" issuance path where each step 
provided a URL for the next step.  This was abandoned because there are 
plenty of issuance cases that are not straight-through - for instance, 
revocation.  Now ACME indirects all requests through a "directory" JSON 
object that maps, e.g. "newAuthz" to "https://example.com/newAuthz". 
This works moderately well, but adds complexity, increases the total 
number of requests, and as it turns out, may have bugs 
(https://www.rfc-editor.org/errata_search.php?eid=5771).

For 6962-bis, the TRANS WG has cycled through three different attempts 
to work around BCP 190: a .well-known path prefixing all the paths 
defined by the API, a directory, and treating the entire set of request 
types as parameters to a log definition delivered out of band.  All were 
found to be unsatisfactory.  The affected URI owners (log operators) are 
being prevented by BCP 190 from doing what they would prefer to do with 
their URI space, which is to use URIs constructed in the same manner as 
RFC6962 (with "/ct/v1" changed to "/ct/v2").

BCP 190 is standing in the way of standardizing simple, sensible HTTP 
APIs and should be amended.

Thanks,

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Jul 2019 15:03:17 -0400

I see two separate problems here with relative paths

1) The path is an extension {whatever}/foo/bar
2) The path climbs the tree {whatever} = ../fred

The problem dealing with the second is that you end up with security issues
that affect ZIP files every five years as the code is re-implemented by a
new person who makes the old mistake. So unzipping a zip archive ends up
overwriting the hosts file or whatever and allows the machine to be rooted.

I see no problem with {whatever}/foo/bar if whatever is a simple prefix.
But it is not an approach to Web Service design I find particularly useful
any more. Unless a Web service is genuinely a data retrieval problem, it is
not going to use HTTP for anything more than expanding the effective number
of ports on the machine and punching a hole in the firewall. Both are
necessary and useful. But they use about 5% of the capabilities of HTTP if
that.

My view therefore is that as TLS everywhere and QUIC take over, we should
look forward to being able to specify a new UDP based transport for 'Web
Service' binding that is designed to meet the needs of Web services and
nothing else. The firewall bypass to be provided by TLS/QUIC. So all we
need to provide at the 'Web Service' layer is a means of disambiguating the
sub-service protocol.

So where I expect we will end up in 5-10 years time is that 'Web Services'
run over a different transport where the interaction looks something like

Client: <well-known> <length> <binary data>
Service: <length> <binary data>
Client: <length> <binary data>

Etc...

Since this would just be using the protocol multiplexing and data framing
capabilities of HTTP, it can be a lot simpler than HTTP. We don't want to
cache in the network (which hasn't worked since SSL) and we certainly don't
want content negotiation.

I don't like REST because I don't find URIs a useful data encoding and see
no value in splitting the request semantics between the URI path and the
POST body. Just do it all in JSON, stick it all in the body and then you
have a simple way to wrap it with a signature or an application level keyed
MAC if you need it.

So that is where I think we should try to head. Just make the traffic look
as nearly like TLS as allows firewall traversal and make sure that legacy
clients and services can downgrade to HTTP.

Web Services require almost none of the functionality of HTTP/1.1 so I see
no reason they would benefit from HTTP/2.

On Fri, Jul 12, 2019 at 12:45 PM Rob Stradling <[email-masked]> wrote:

> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Jul 2019 12:46:18 -0700

Hi Mark,
>HTTP-based APIs.  Specifically, this paragraph of section 2.3

There was a comment from Stephen about Section 2.3 of what became RFC 
7320.  Do you remember whether it was addressed and how, if that is the case?

Regards,
S. Moonesamy

---

From: Adam Roach <[email-masked]>
Date: Fri, 12 Jul 2019 15:58:18 -0500

> 7320.  Do you remember whether it was addressed and how, if that is 

It was -- the document added an example of a concern that this rule is 
intended to protect:

     (for example, an

/a

---

From: S Moonesamy <[email-masked]>
Date: Sat, 13 Jul 2019 06:29:30 -0700

Hi Rob,

The short answer for your request to change RFC 7320 is to consider 
the example at 
https://mailarchive.ietf.org/arch/msg/art/vcUQD4V6PlTMbzfW_89JhvhJEF0

The ACME erratum which you referred to violates the rules set by the 
IESG for processing of errata.  I took a quick look at 
draft-ietf-trans-rfc6962-bis.  It is not aligned with the Working 
Group Charter.  One of the "DISCUSS" is about information disclosure; 
it is currently not addressed in the draft.

If the Working Group is against RFC 7320, it could submit a draft to 
change it.  I suggest considering the time it could take to get that 
through the IETF process.

Regards,
S. Moonesamy

---

From: "Henry S. Thompson" <[email-masked]>
Date: Sat, 13 Jul 2019 15:24:20 +0100

> through the IETF process.

I would also point interested parties to _Building Protocols with HTTP_
(draft-ietf-httpbis-bcp56bis-08 [1]), which covers very similar issues
to those in 7320.  When I pushed back on aspects of an earlier draft
similar to those Rob Stradling is concerned by, I was unsuccessful.  The
rebuttal to my objections was grounded in the fact that this BCP is
focussed on _specifications_. Specifications are (or ought to be) open
to multiple implementations.  Baking in _any_ aspect of URI syntax in a
spec was held to amount to an unreasonable/unnecessary constraint on
implementors.

ht

[1] https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-08
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

---

From: <[email-masked]>
Date: Mon, 22 Jul 2019 21:17:38 -0700

I don't understand
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ballot/ 
5 DISCUSS on a document targeted to be Experimental where most of the
objections 
don't seem to meet the criteria for raising a DISCUSS on a standards-track
document.
https://www.ietf.org/blog/discuss-criteria-iesg-review/#stand-disc
much less Experimental.
I'm especially baffled by the use of BCP 190 (which documents some
guidelines)
as somehow "blocking" anything in IESG Review.

I'd advise inserting a Note at the top of the document pointing to
the extensive comments in the IESG review and get on with publishing
the document, as Experimental, so the standards-track work can begin.

IMHO
--
https://LarryMasinter.net

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 01:33:20 -0400

I write the following in my role as the area director holding the 
BCP-190-related discuss that Larry mentions below.

> as somehow "blocking" anything in IESG Review.

Thanks, Larry, for raising these questions. I think it's important that 
everyone understands the situation that has arisen, and you've done a 
good job of crystallizing a couple of topics that I'm sure several other 
people are also concerned about.

Although a bit of a diversion, I do want to address your point about 
discuss criteria before I get into the status of BCPs in general and BCP 
190 in particular (at least as I understand them; I welcome feedback if 
people believe I'm off-base in my assertions). While I hesitate to 
litigate the list of "discuss criteria" you cite -- in large part 
because it is self-disclaimed by language that it is merely exemplary 
and "cannot be an exhaustive list" -- this specific situation does have 
a bullet point in that list that reads, at least in spirit, on the topic 
at hand. To wit:

> The IETF as a whole does not have consensus on the technical approach 
> or document. There are cases where individual working groups or areas 
> have forged rough consensus around a technical approach which does not 
> garner IETF consensus. An AD may DISCUSS a document where she or he 
> believes this to be the case. While the Area Director should describe 
> the technical area where consensus is flawed, the focus of the DISCUSS 
> and its resolution should be on how to forge a cross-IETF consensus.
>

In this specific case, the IETF wrote down consensus around the general 
principles of stewardship for the URI namespace, and then a working 
group without charter to deal with that topic came to a decision 
contrary to that consensus.

I want to make sure that everyone involved in this conversation is clear 
on a relevant role that BCPs play. BCP documents have the same level of 
maturity and receive the same level of scrutiny as Standards Track 
documents. Their normative statements authoritatively govern the topic 
they deal with -- at least, within the confines of IETF process -- until 
updated or obsoleted. Normative statements in BCPs are not mere 
guidelines; they are the documented and carefully-considered will of the 
responsible community. This is the mechanism the IETF has to make 
durable and binding decisions. Without that ability, we would waste a 
significant quantity of time re-litigating topics about which we had 
already reached conclusions.

That said, "durable" is not the same as "permanent", and it has been 
five years since the publication of BCP 190. It is reasonable for the 
community to revisit earlier decisions in the presence of additional 
experience. I welcome the discussion of whether a revision is warranted 
at this time, and encourage interested parties to present their 
positions politely, factually, and unemotionally.

Importantly, I do not think that I am allowed to stand out of the way of 
what appears to be one working group deciding to set aside established 
IETF consensus without buy-in from the responsible stakeholders. I 
believe that I would be derelict in my obligations as an area director 
in charge of the relevant area if I were to do so. If BCP 190 needs 
revision, that decision needs to come out of the ART community as a 
whole, not out of a single SEC-area working group with a charter 
unrelated to URI design and ownership.

I want to be ultra clear: I am not blocking this document because I feel 
any specific way about the provisions of BCP 190. I am blocking this 
document because the IETF has made a decision, and we need to either 
abide by it or revise it.

/a

---

From: Leif Johansson <[email-masked]>
Date: Tue, 23 Jul 2019 07:44:18 +0200

Thank you Adam,

This was a great summary for somebody like me who sorta heard about
the issue for the first time today.

> contrary to that consensus.

Has there been any similar situations before involving BCP190 and how
where those issues resolved?

	Cheers Leif

---

From: Rob Sayre <[email-masked]>
Date: Mon, 22 Jul 2019 22:54:21 -0700

On Fri, Jul 12, 2019 at 9:46 AM Rob Stradling <[email-masked]> wrote:

> ...since all modern
> again.

I don't think this assertion is correct. Query components don't reflect a
hierarchy, they are unordered, and can be repeated. They can be rewritten
to and from path segments, but not in a way that preserves their semantics.

thanks,
Rob

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 02:32:55 -0400

> where those issues resolved?

There have been a number of similar situations involving BCP 190, at 
varying phases of document development. In my time on the IESG, I can 
recall roughly two cases in which draft authors contacted the ART area 
directors to ask advice while a specification was under development in a 
working group, and there have been probably as many that reached IESG 
evaluation before the issue was identified as blocking.

In the cases where the issue was discussed while still the document was 
under development, the documents were easily adapted to conform to the 
normative requirements of BCP 190. One of these discussions did form 
part of the impetus that eventually led to the revision of RFC 5785 
(which defined .well-known) by RFC 8615, as that discussion did turn up 
a desire in the community to relax some of the constraints that 
originally existed in RFC 5785 (including the one mentioned during 
today's ARTAREA meeting).

In the cases where the issue was only discovered in IESG review, the 
documents have gone back to their respective working groups for further 
discussion. Prior to the current conversation involving the TRANS 
document, the working groups whose documents were found to have BCP 190 
issues made the minimal protocol changes necessary to meet its requirements.

It's notable that discovering these issues earlier in the process 
universally had better outcomes than discovering them during IESG 
review. To that end, the IESG has begun the effort of compiling a list 
of technologies that are likely to require expert input if used outside 
the working groups in which core expertise resides. The final steps of 
this task are on my plate, and I hope to get to them shortly after I 
recover from the current face-to-face meeting. The hope is that we will 
be able to keep the chairs of various working groups apprised of this 
list of technologies, so that such expert input can be sought earlier in 
the process, when it is less likely to cause unwelcome surprises for 
working group participants.

/a

---

From: Rob Sayre <[email-masked]>
Date: Mon, 22 Jul 2019 23:58:55 -0700

> to and from path segments, but not in a way that preserves their semantics.

Trying to be more constructive, I think the issue is that it's true that
you can write a seemingly-simple API that treats an entire host or path
below a certain level as opaque.

Enacting "simple" rules of that sort can cause problems as different HTTP
APIs coexist under one host, each with their own reserved suffixes, paths,
or query parameters. At the very least, you've prevented the host from
delegating its path space (say, for usernames). At worst, you've forced it
into using different hostnames, and taking on all of the associated DNS
latency and confidentiality issues.

It doesn't seem like writing a BCP190-compliant API is complex, but the
evidence does show that it's not the first avenue people think of.

thanks,
Rob

---

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Jul 2019 03:14:05 -0700

Hi Larry,
At 09:17 PM 22-07-2019, [email-masked] wrote:
>objections don't seem to meet the criteria for raising a DISCUSS on 
>a standards-track
>document.

The TRANS Working Group set a milestone for December 2015.  After 
four years, the work item for that is still not in accordance with 
the Working Group Charter [1], i.e. standards-track.  I suggest 
reading the Document Shepherd write-up.

I would like to thank Henry for reminding me about the BCP 56 
update.  I was trying to remember where this case may fit; it might 
be "substrate".

Regards,
S. Moonesamy

1. https://datatracker.ietf.org/wg/trans/about/

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Jul 2019 08:37:16 -0400

(copying architecture-discuss because the comment I'm about to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)

A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations.  

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Jul 2019 11:19:43 -0400

On 7/23/19 6:14 AM, S Moonesamy wrote:
> The TRANS Working Group set a milestone for December 2015.  After four
> years, the work item for that is still not in accordance with the
> Working Group Charter [1], i.e. standards-track. 

By way of a little history and context, 6962 was published as an
independent submission as an experimental standard.  The goal for
trans was to update the protocol through the IETF consensus process
on the standards track.  However, because 6962-bis has been so
difficult to get through the process it's been badly delayed, which
has led to implementation delays as well.  Log operators have said
that they intend to move to the revised protocol within a few years
but in the meantime without implementation experience it became
clear that it was appropriate to publish -bis as an experimental
standard, as well, and we have consensus from the working group and
our AD (who, at the time of the decision, was EKR).

Melinda

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Leif Johansson <[email-masked]>
Date: Tue, 23 Jul 2019 17:28:59 +0200

> working group participants.

Thank you, that is very helpful.

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.

In other words: what parts of the web will crash and burn as the result
of CT having an API that specifies a uri structure outside .well-known?

I'm sure there is a perfectly reasonable answer to that question. Maybe
this understanding is what the CT WG needs in order to get past this
issue??

	Cheers Leif

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 11:30:59 -0400

John --

It's going to take a while for me to formulate my thoughts around what 
you say below. To make sure I understand the class of constraints you're 
concerned about below, can you clarify whether you think they apply to:

  * Documents like BCP 200, RFC 2804, and BCP 188?
  * Documents like BCP 9 and BCP 92?
  * Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list 
above, so I'll state it explicitly: in the general case, one person's 
important protections against a tragedy of the commons is another 
person's annoying impediment to be ignored and defeated. I get that not 
all of the above read on protocol design; but they do share the common 
feature that they've gone through the IETF consensus process (at least 
to the degree that such a process existed at the time of their 
respective publications). If we're going to carefully parse out the 
meanings of some of them as the will of the community while treating 
others as light guidelines to be ignored when they become cumbersome, 
we're going to need to agree on a pretty bright line that divides those 
categories.

/a

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Jul 2019 11:42:23 -0400

> of CT having an API that specifies a uri structure outside .well-known?

The discussions in trans have focused on the question of the
impact of BCP 190 on CT and there's been a lack of clarity on
the question of the impact of the CT namespace on the rest of
the world.  That is to say, CT log servers run in very narrow,
specialized spaces and it's not really clear that there is
potential, in practice, for the sorts of conflicts BCP 190 is
intended to prevent.  So, we've got a situation in which there
are considerable practical impacts of BCP 190 on the CT protocol
in both design and implementation, and any apparent impacts of
the CT protocol using a non-compliant namespace on the rest of
the world appear to be at best theoretical.

Melinda

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 11:46:28 -0400

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jul 2019 16:54:10 +0100

Hiya,

> who own its governance (e.g., domain owners) against protocol designers.

Right. The difference with trans is that there aren't a mass
of domain owners involved here, just a tiny tightly curated
list of them and they're basically the ones who designed the
protocol (give or take). There is no harm accruing here that
I can see.

The "MUST NOT" in BCP190 2.3 is too strongly stated, so yes
adding some sensible caveats there would be good. I hope that
if the conclusion is that there is consensus to let trans ignore
that omission in the BCP, that fixing the BCP does not become
a pre-requisite for what is (as Melinda explained) a spec that's
already been significantly delayed via IETF process.

S.

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 12:02:46 -0400

On 7/23/19 11:54, Stephen Farrell wrote:
> I hope that

I very much recognize this. I've told the TRANS chairs (and just 
recently reiterated on this list) that I plan to clear my discuss if and 
when it becomes evident that the community agrees with their position, 
without waiting for any specific concrete proposal to update BCP 190 
(although I would expect such an update to follow).

/a

---

From: Leif Johansson <[email-masked]>
Date: Tue, 23 Jul 2019 18:03:29 +0200

> the world appear to be at best theoretical.

Oh I completely agree and I think that is clear to everyone who
has looked at the issue.

However there must be a reason the IESG is pushing back hard on
this principle - I hope its not just "but BCP190 has consensus"
because that is just about whose consensus is bigger... not a
good place to be.

Therefore I'm working on the assumption that there are actual
larger interoperability issues hiding in BCP190 that leads the
IESG.

I'm really curious as to what they are.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 23 Jul 2019 18:06:27 +0200

> the exclusive use of one protocol or another.

In that case maybe this is just a matter of qualifying section 2.3 with
something along the lines of "this does not apply if your entire domain
is meant to do just one thing"

	Cheers Leif

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 23 Jul 2019 13:08:57 -0400

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).

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 14:48:09 -0400

> is meant to do just one thing"

You're not the only person to suggest that, and maybe it's worth 
considering.

However.

As I've mentioned up-thread, the TRANS conversation has indicated that 
these origins are *not* single-purpose, so this proposal is somewhat 
unrelated.

I'd like to see the conversation around single-purpose origins happen, 
if we decide to revise BCP 190. But it would appear that the TRANS folks 
are in a hurry to reach a conclusion regarding their specific use case, 
so perhaps we should focus the discussion on that.

/a

---

From: Leif Johansson <[email-masked]>
Date: Tue, 23 Jul 2019 21:28:32 +0200

> these origins are *not* single-purpose, so this proposal is somewhat

I think you may be confusing multi-tentant TRANS with multi-purpose

Using a domain *only* for TRANS but with multiple tenants does not
suggest the same restrictions on the management of the URI namespace
for that domain.

	Cheers Leif

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 15:33:55 -0400

> suggest the same restrictions on the management of the URI namespace

Thanks for the clarification -- I did indeed misinterpret that 
terminology distinction.

I'm also hearing others saying that they don't want to use .well-known 
because they are administratively prevented from doing so. I think that 
went at least as far in implying multi-purpose (rather than merely 
multi-tenant) as anything else that has been said.

Would it be possible to also clarify whether (and how) .well-known ends 
up being administratively reserved in a single-purpose origin?

/a

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Jul 2019 13:57:12 +0100

> protocol (give or take). There is no harm accruing here that

The problem that trans has also applies in circumstances where we might
expect much wider population of servers. It's a problem for any protocol
implemented as a server-side web app.

I have personal web space under https://www.chiark.greenend.org.uk/~fanf/
where I can install web apps, and paths under that prefix have been
delegated to me. I can't use that web space to deploy anything restricted
by BCP 190, so BCP 190 has the opposite of its intended effect of allowing
web server admins and their users to control their URL space, and allowing
them to decide where they would like to install apps.

I understand the point of using .well-known for information about the
server itself or about the server's domain name. I don't understand the
value of forcing an app to use .well-known when (like trans) it has a
completely configurable URL prefix.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rattray Head to Berwick upon Tweed: South or southeast 3 to 5, but variable 2
for a time. Smooth or slight. Thundery showers at first in north, otherwise
fair. Moderate or good, occasionally poor.

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Wed, 24 Jul 2019 21:03:57 +0700

Dear architecture-discuss,
& John,

To share what might be inspiring...

In order to propose what should be understood as "concept", "percept" &
"affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is
Philosophy?") mentioned architecture as the first art as art begins with
house: that of which "the most scientific architecture continually produces
and unifies planes and sections... it could be defined as "frame" with a
connection among various frames oriented differently, applied to other
arts...(There is) a composite system consisting of points and
counterpoints... (there is) a matter of sensations (percepts and affects)
combined... (While) the system still needs a composition plane run
"deframing" opening ways from house territory to city-cosmos, the system in
which there are cosmic forces to create new affects...".

There is "asthetic composition" as the working of sensation which is, so
they said, the definition of art...

Regard,
Guntur Wiseno Putra

Pada Selasa, 23 Juli 2019, Adam Roach <[email-masked]> menulis:

> John --
>
> It's going to take a while for me to formulate my thoughts around what you
> say below. To make sure I understand the class of constraints you're
>    - Documents like BCP 200, RFC 2804, and BCP 188?
>    - Documents like BCP 9 and BCP 92?
>    - Documents like BCP 25, BCP 54, and BCP 83?
>
> important protections against a tragedy of the commons is another person's
> annoying impediment to be ignored and defeated. I get that not all of the
> above read on protocol design; but they do share the common feature that
> they've gone through the IETF consensus process (at least to the degree
> that such a process existed at the time of their respective publications).
> If we're going to carefully parse out the meanings of some of them as the
> will of the community while treating others as light guidelines to be
> ignored when they become cumbersome, we're going to need to agree on a
> pretty bright line that divides those categories.
>
> /a
>
> art mailing [email-masked]://www.ietf.org/mailman/listinfo/art
>
>
>