Subject: [art] On BCP 190

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Jul 2019 14:14:36 -0400

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/

---

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

Hi Mark,

> 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 bu…

Playing devils advocate: how is BCP190 then a BCP? I understand there
may be an argument for the B and the C but if there are really 1000s
of APIs that does what BCP190 say you MUST NOT, then in what sense
does this represent Best Current /Practice/?

I am not being facetious.

	Cheers Leif

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Jul 2019 15:54:24 -0400

> On 23 Jul 2019, at 3:34 pm, Leif Johansson <[email-masked]> wrote:
> 
> Hi Mark,
> 
>> 

There aren't; I was speaking about the future.

Chees,

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

---

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

> There aren't; I was speaking about the future.

Ah so the BCP designation is aspirational? I personally think thats a
problematic use of BCPs

	Cheers Leif

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Jul 2019 16:34:46 -0400

Please re-read; it’s to prevent future problems. 

Sent from my iPhone

> On 23 Jul 2019, at 4:28 pm, Leif Johansson <[email-masked]> wrote:
> 
> 
>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 23 Jul 2019 17:24:33 -0400

Skickat från min iPhone

> 23 juli 2019 kl. 16:34 skrev Mark Nottingham <[email-masked]>:
> 

To me that is the definition of aspiration: you hope that you will alter behaviour in the future.

How do you measure success?

Cheers Leif

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 17:49:03 -0400

Leif --

It seems to me, watching this conversation, that you and Mark are 
talking past each other. While I understand the points he is making, I'm 
having a hard time following your line of logic given that BCP 190 does, 
in fact, codify practices that have largely been applied to URI usage in 
the past (albeit only in an ad-hoc fashion prior to its publication). 
It's done a pretty reasonable job of keeping protocols from co-opting 
parts of the URI space so far, and will ostensibly continue to do so 
into the future.

Perhaps you could take a fresh run at explaining what you think the 
problem is?

/a

---

From: Leif Johansson <[email-masked]>
Date: Tue, 23 Jul 2019 18:25:04 -0400

Skickat från min iPhone

> 23 juli 2019 kl. 17:49 skrev Adam Roach <[email-masked]>:
> 
> Leif --
> 
> It seems to me, watching this conversation, that you and Mark are talking past each other. While I understand the points he is making, I'm having a hard time following your line of logic given that BCP 190 does, in fact, codify practices that have largely been applied to URI usage in the past (albeit only in an ad-hoc fashion prior to its publication). It's done a pretty reasonable job of keeping protocols from co-opting parts of the URI space so far, and will ostensibly continue to do so into the future.
> 

I read Mark saying that there are 1000s of APIs that get it wrong. That made me ask if (and if so you you know) BCP190 is actually working.

> Perhaps you could take a fresh run at explaining what you think the problem is?
>

---

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

> I read Mark saying that there are 1000s of APIs that get it wrong. That made me ask if (and if so you you know) BCP190 is actually working.

Ah. I'm pretty sure -- and Mark can confirm -- that what he meant to 
convey by that statement is that he's concerned about the impacts of 
1000s of APIs eroding the usable URI namespace in the future if we were 
to abandon or substantially weaken the constraints outlined in BCP 190.

/a

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Jul 2019 08:59:36 -0400

Indeed.

> On 23 Jul 2019, at 11:38 pm, Adam Roach <[email-masked]> wrote:
> 
> Ah. I'm pretty sure -- and Mark can confirm -- that what he meant to convey by that statement is that he's concerned about the impacts of 1000s of APIs eroding the usable URI namespace in the future if we were to abandon or substantially weaken the constraints outlined in BCP 190.
> 
> /a

---

From: Leif Johansson <[email-masked]>
Date: Wed, 24 Jul 2019 09:08:22 -0400

Hi Mark,

I didn’t expect this to be this hard to parse. 

I understand you are hoping BCP190 will have an effect in the future.

My question is by what means would you measure or determine success? I ask because I (and clearly others on the list) see a pretty big impedance missmatch between reality and BCP190.

Hope this helps to make what l’m asking for clearer.

Cheers Leif

Skickat från min iPhone

> 24 juli 2019 kl. 08:59 skrev Mark Nottingham <[email-masked]>:
> 
> Indeed.
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Jul 2019 09:15:22 -0400

Do we usually set success criteria for BCPs?

> On 24 Jul 2019, at 9:08 am, Leif Johansson <[email-masked]> wrote:
> 
> 
> Hi Mark,
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 24 Jul 2019 09:19:47 -0400

> Do we usually set success criteria for BCPs?

I've never seen any, but it seems that it might be helpful,
given that the trans wg is saying that being required to
make changes to conform to BCP 190 causes harm to the CT
protocol, to have that requirement based on actual harm done
by not conforming.

Melinda

-- 
Software longa, hardware brevis

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

---

From: Leif Johansson <[email-masked]>
Date: Wed, 24 Jul 2019 09:25:30 -0400

Skickat från min iPhone

> 24 juli 2019 kl. 09:19 skrev Melinda Shore <[email-masked]>:
> 

Bingo

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Jul 2019 09:35:32 -0400

If any impediment to shipping a protocol is considered "harm", we've got a problem. 

> On 24 Jul 2019, at 9:19 am, Melinda Shore <[email-masked]> wrote:
> 
> Signed PGP part

---

From: Melinda Shore <[email-masked]>
Date: Wed, 24 Jul 2019 09:46:37 -0400

> If any impediment to shipping a protocol is considered "harm", we've got a problem. 

Well, if you take a look at the datatracker, you'll see that
the authors have been working hard to develop text to clear
other DISCUSSes.
(https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ballot/).
I'm not going to rehash Devon's talk here, but the pain associated
with making protocol changes to support BCP 190 requirements is
well beyond what we'd have expected, and it doesn't seem unreasonable
to me that there'd be some justification for it based on experience.

In a chat with Adam earlier today he said that there has, in fact,
been squatting on namespace elements like robots.txt and favicon.ico.
That's extremely helpful and the sort of thing that might support
the case for requiring BCP 190.  If we have (or have not) actually seen
the same problem in application namespaces or on single-use servers,
that would be be helpful to know, as well.

Melinda

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Jul 2019 12:15:06 -0400

> that would be be helpful to know, as well.

While I think we need to have a broader conversation on BCP 190 that 
covers this in depth, there is one critically important bit of 
information that has not been made clear about the way that CT is being 
deployed, and I don't think there is any hope of quickly processing the 
CT document until it is clearly answered:

     Is the mechanism defined in the "Certificate Transparency
     Version 2.0" document constrained to run on an origin on
     which no other services are present?

The answer to this question *radically* effects the conversation we need 
to be having to get the document published as quickly as possible. We 
can try to finish the wide-ranging conversation about BCP 190 in general 
without an answer to this question, but unless we want to block the 
TRANS document while we wait for that to happen, we're going to need to 
understand this fundamental property as soon as possible.

/a

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 24 Jul 2019 09:40:13 -0700

>      which no other services are present?

No, definitely not. In practice, that's how people have tended to deploy
it, mainly because origins are cheap, and CT's high availability
requirements mean you don't want your website maintenance events to cause
downtime for your CT log.

However, it's worth reiterating that CT logs are specified by origin + path
prefix, and most CT logs coexist on a single origin with multiple other
logs, distinguished by path prefix.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 24 Jul 2019 09:51:45 -0700

I'd like to reiterate that CT does not squat on namespace elements, like
favicon or robots.txt. CT logs are specified by origin *and path prefix*:

https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-31.txt
>   The <log server> prefix, which is one of the log's parameters, MAY
>   include a path as well as a server name and a port.

So CT is totally fine with regards to this part of BCP 190 Section 2.3
<https://tools.ietf.org/html/bcp190#section-2.3>:

>    For example, an application ought not specify a fixed URI path
>   "/myapp", since this usurps the host's control of that space.

It's this part of BCP 190 Section 2.3 that is causing the issue:

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

To be clear, the "whatever" in this case is referred to as <log server> in
CT, and is discovered via the known logs list (
https://www.certificate-transparency.org/known-logs) and browser CT
programs.

On Tue, Jul 23, 2019 at 11:14 AM Mark Nottingham <[email-masked]> wrote:

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

This is a valuable and subtle point, and I think the crux of the matter.
It's actually surprisingly rare to see an HTTP API that is designed to be
implemented many times. But if you look at those that are (RFC 7482, RFC
7808, RFC 8040, Mastodon, and Git, for example), what they have in common
is that they are all organized around a hostname and path prefix, just like
CT.

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Jul 2019 12:58:40 -0400

On 7/24/19 12:40, Jacob Hoffman-Andrews wrote:
> On Wed, Jul 24, 2019 at 9:15 AM Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> No, definitely not. In practice, that's how people have tended to 
> deploy it, mainly because origins are cheap, and CT's high 
> availability requirements mean you don't want your website maintenance 
> events to cause downtime for your CT log.

Thanks for the clear answer.

Given this information, I would to ask that we *not* focus on the 
question of whether single-use origins can reasonably have more lax 
restrictions than other origins, at least until we figure out the 
question of how to handle the CT document.

To be clear: I'd like the ART community to discuss this topic at some 
point, but I don't want to hold up the CT document on its conclusion. 
This is a request to *defer* the conversation, not a request to abandon it.

/a

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Jul 2019 13:24:50 -0400

On 24 Jul 2019, at 12:51 pm, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 
> So CT is totally fine with regards to this part of BCP 190 Section 2.3:
> 

Yep.

> To be clear, the "whatever" in this case is referred to as <log server> in CT, and is discovered via the known logs list (https://www.certificate-transparency.org/known-logs) and browser CT programs.

Yes -- and this text should definitely be considered when revising 190. Like I said, we've moved on a fair amount since then (although we still have a ways to go). 

One thing I'd like to see in a revision is a clearer separation between "you're potentially harming others by doing this; don't do it" and "you're potentially harming yourself by doing this; think carefully before proceeding."

> 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
> 
> This is a valuable and subtle point, and I think the crux of the matter. It's actually surprisingly rare to see an HTTP API that is designed to be implemented many times. But if you look at those that are (RFC 7482, RFC 7808, RFC 8040, Mastodon, and Git, for example), what they have in common is that they are all organized around a hostname and path prefix, just like CT.

Agreed. 

The discussion I had with Devon the other day led to two paths (not that there aren't others; these just seem most likely as ways forward):

1) Using .well-known. This is precisely what well-known is for, and if hosting multiple logs is a concern, you can just require that /.well-known/mumble/ be the prefix you use; e.g., you could use something like /.well-known/ct-logs/2019/ as a prefix if you want to shard by year.

2) Getting an exception. 

AFAICT the arguments against #1 are:

a) that some people don't have access to .well-known on their servers -- but this seems like a very poor argument for this particular use case.

b) aesthetic   ¯\_(ツ)_/¯

#2's main downside is the process of getting the exception and agreeing on text. FWIW I'm happy to support an exception here (but would be happier if someone could explain why #1 isn't a sufficient option), and help come up with a small bit of text. You might want to talk to ADs about how much process they want to impose before walking down this path, but I can't see it taking that long personally.

Cheers,

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 24 Jul 2019 10:49:20 -0700

On Wed, Jul 24, 2019 at 10:24 AM Mark Nottingham <[email-masked]> wrote:

> > To be clear, the "whatever" in this case is referred to as <log server>
> in CT, and is discovered via the known logs list (
> Yes -- and this text should definitely be considered when revising 190.
> Like I said, we've moved on a fair amount since then (although we still
> have a ways to go).
>
> One thing I'd like to see in a revision is a clearer separation between
> "you're potentially harming others by doing this; don't do it" and "you're
> potentially harming yourself by doing this; think carefully before
> proceeding."
>

Which category to you think that paragraph of Section 2.3 (call it 2.3b)
belongs to? It sounds like it belongs to the "harming yourself" category,
which means that it's not actually protecting a commons.

And to be clear, even though 2.3b sounds advisory-only, it's this clause at
the top of Section 2.3 that has broader normative language:

> specifications MUST NOT constrain,
>   or define the structure or the semantics for any path component.

> a) that some people don't have access to .well-known on their servers --
> but this seems like a very poor argument for this particular use case.
>

Andrew Ayer presented one concrete case where the use of .well-known
presented implementation difficulties for Google, a company that presumably
has full control over its servers. I don't know the details of why, but I
can guess: .well-known is dangerous. As a hosting provider, allowing users
to upload abritrary files to /.well-known/acme-challenge means the users
can get certificates for the hosted domain name. Probably there are other
security-relevant things under /.well-known/. The safe and reasonable thing
is to just block access to /.well-known/. I would guess that Google's
security team has set a policy: All access to .well-known is blocked at the
frontends unless it's gone through a detailed review.

So we have advice in BCP 190 meant to ensure that protocols allow
implementers to implement any way they want (e.g. with query parameters to
represent semantics). But instead, the advice to require /.well-known/ is
creating practical barriers for implementers to implement things in the way
they want.

Also, if the reasoning for 2.3b is that implementers might only be able to
use query parameters, not paths, then specifying paths under .well-known
doesn't solve that problem at all.

Thanks,
Jacob

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Jul 2019 13:59:25 -0400

> On 24 Jul 2019, at 1:49 pm, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 
> Which category to you think that paragraph of Section 2.3 (call it 2.3b) belongs to? It sounds like it belongs to the "harming yourself" category, which means that it's not actually protecting a commons.

Probably the latter. That's just my opinion, though -- which is why if you want to go down the exception path, the best thing to do would be to coordinate with the AD and figure out what that's going to take.

> And to be clear, even though 2.3b sounds advisory-only, it's this clause at the top of Section 2.3 that has broader normative language:
> 

Yep.

> Andrew Ayer presented one concrete case where the use of .well-known presented implementation difficulties for Google, a company that presumably has full control over its servers. I don't know the details of why, but I can guess: .well-known is dangerous. As a hosting provider, allowing users to upload abritrary files to /.well-known/acme-challenge means the users can get certificates for the hosted domain name. Probably there are other security-relevant things under /.well-known/. The safe and reasonable thing is to just block access to /.well-known/. I would guess that Google's security team has set a policy: All access to .well-known is blocked at the frontends unless it's gone through a detailed review.

Having a local policy for control of the name space of a web server seems like a good thing. I'm not finding that a particularly convincing reason -- especially when the review will likely amount to "consult the RFC."  Shrug.

> So we have advice in BCP 190 meant to ensure that protocols allow implementers to implement any way they want (e.g. with query parameters to represent semantics). But instead, the advice to require /.well-known/ is creating practical barriers for implementers to implement things in the way they want.

Going from "google has a policy for their web servers" to "practical barriers" for the entire protocol seems like a long bow to draw. 

Cheers,

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Jul 2019 19:00:36 +0100

Mark Nottingham <[email-masked]> wrote:
>
> 1) Using .well-known. This is precisely what well-known is for,

I'm still having difficulty understanding this. RFC 8615 says:

   Some applications on the Web require the discovery of information
   about an origin [RFC6454] (sometimes called "site-wide metadata")
   before making a request. [...]

   When this happens, one solution is to designate a "well-known
   location" for data or services related to the origin overall, so that
   it can be easily located. [...]

But CT isn't providing metadata about the origin overall. And CT has a
separate mechanism for finding out where an endpointis located so it
doesn't need a fixed well-known location.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Irish Sea: South or southeast 3 to 5. Slight, occasionally moderate. Showers
later. Good occasionally poor.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Jul 2019 14:03:24 -0400

The applicable text is:

"""
At the same time, it has become more popular to use HTTP as a
 substrate for non-Web protocols.  Sometimes, such protocols need a
 way to locate one or more resources on a given host.
"""

(Not particularly defending the clarity of that text overall -- we were trying to graft an expanded set of use cases onto an existing spec).

Cheers,

> On 24 Jul 2019, at 2:00 pm, Tony Finch <[email-masked]> wrote:
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Jul 2019 19:41:22 +0100

>  way to locate one or more resources on a given host.

OK, but that's immediately before the bit that says:

   When this happens, one solution is to designate a "well-known
   location" for data or services related to the origin overall, so that
   it can be easily located.

"One solution" implies to me that .well-known is not aimed at cases where
there are other solutions, as is the case for CT. (Even if BCP 190 doesn't
like CT's solution...)

I can't find any discussion about which non-web protocols were the
inspiration for that paragraph, and what ways they were considered
problematic. Is there more to the problem than how to get from a host
name to a URL without trampling on the host's URL namespace?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy, Sole: South veering west 4 to 6, occasionally 7 at first. Moderate or
rough, becoming very rough in west. Occasional thundery rain. Moderate or
good, occasionally poor in southeast Fitzroy.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 24 Jul 2019 11:45:55 -0700

On Wed, Jul 24, 2019 at 11:03 AM Mark Nottingham <[email-masked]> wrote:

> (Not particularly defending the clarity of that text overall -- we were
> trying to graft an expanded set of use cases onto an existing spec).

It seems like this graft didn't really solve the problem it intended to
solve. Since Section 2.3b isn't about protecting the URL namespace commons,
moving things under .well-known doesn't address the requirements laid out
in 2.3b.

Instead, 2.3b is about practicality, implementation, and "harming
yourself." Since some implementers can only use query parameters
(ostensibly), 2.3b says protocol designers should not define semantics
based on paths. Moving the protocol under .well-known doesn't address those
practical implementation concerns at all. If an implementer can only
implement using query semantics, that is still a problem whether or not the
prefix contains .well-known.

> Probably the latter. That's just my opinion, though -- which is why if you
> want to go down the exception path, the best thing to do would be to
> coordinate with the AD and figure out what that's going to take.

FWIW, Adam Roach, one of the ART ADs, has said that what it would take is
the community's agreement, which is what we're working on establishing
right now.

---

From: Larry Masinter <[email-masked]>
Date: Sat, 27 Jul 2019 23:26:25 -0700

Although it might seem like overkill, JSON HAL 

https://tools.ietf.org/html/draft-kelly-json-hal-08

seems like it’s intended as a way of avoiding having

the client do string-hacking of URL paths

(EXCEPT processing relative URLs and constructing
GET URLs on some kinds of form submissions).

The use of / in the path of URLs was supposed to

be restricted to hierarchical data, and yet CT doesn’t
do that.

http://masinter.blogspot.com/2019/05/on-nature-of-hierarchical-urls.html 

Now, why JSON-HAL is still an expired  Internet Draft 

is a puzzle.

--

https://LarryMasinter.net 

From: art <[email-masked]> On Behalf Of Jacob Hoffman-Andrews
Sent: Wednesday, July 24, 2019 10:49 AM
To: Mark Nottingham <[email-masked]>
Cc: ART Area <[email-masked]>; Devon O'Brien <[email-masked]>
Subject: Re: [art] On BCP 190

Andrew Ayer presented one concrete case where the use of ..well-known presented implementation difficulties for Google, a company that presumably has full control over its servers. I don't know the details of why, but I can guess: .well-known is dangerous. As a hosting provider, allowing users to upload abritrary files to /.well-known/acme-challenge means the users can get certificates for the hosted domain name. Probably there are other security-relevant things under /.well-known/. The safe and reasonable thing is to just block access to /.well-known/. I would guess that Google's security team has set a policy: All access to .well-known is blocked at the frontends unless it's gone through a detailed review.

Also, if the reasoning for 2.3b is that implementers might only be able to use query parameters, not paths, then specifying paths under .well-known doesn't solve that problem at all.

Thanks,

Jacob

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 28 Jul 2019 10:42:45 +0200

> Now, why JSON-HAL is still an expired  Internet Draft 

(Slightly, but not completely off-topic:)

Probably because there are multiple ways to skin this cat and we never tried to converge on one.

As a data point, for the applications in the CoRE working group, we have mostly been able to avoid BCP190-style arguments by using /.well-known, mainly because simple devices only tend to have one service offered directly under / and because IoT device platforms tend to provide the application developer full control over the URI space.  /.well-known/core provides a discovery mechanism for the entry point URIs actually offered by a server.

For where this is not enough, the WG has just last week adopted CoRAL (not yet resubmitted as draft-ietf, so you can find it at draft-hartke-t2trg-coral) as our idea of a hypermedia format like HAL.  Up to now, we tried to make everything work with RFC 6690 link format, but that has too many idiosyncrasies that started to get in the way of a long-term way forward.

Grüße, Carsten

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 31 Jul 2019 14:10:17 -0700

> http://masinter.blogspot.com/2019/05/on-nature-of-hierarchical-urls.html

CT and all prefix-using APIs do that, with a single level hierarchy. The
domain owner specifies a prefix, ending with a "/". All of the URLs that
are part of the API follow that prefix - they are subordinate in the
hierarchy.

Coming back to the main point: What remains in order to find consensus on
this issue?

Thanks,
Jacob