Subject: [core] CRI Extension for multiple schemes

From: Jim Schaad <[email-masked]>
Date: Sat, 13 Jun 2020 10:21:59 -0700

I had a strange idea which both violates the entire concept of what CRI was
designed to do, but has the potential to solve some problems that have been
pushed onto the back burner.  

Given that we have broken down a URI into an array of items, and there has
been some desire to allow for some type of multiple schemes to be specified
for a URI, what happens if we put an array of schemes into a CRI.  This
would allow for something like the following:

[ ["coap", "coap+tls"], "example.com", ".well-known", "core"]

While one could additionally allow for an array of host/port information I
think that this would be a step to far.  One would need to "resolve" the
array of schemes down to a single item before it could be used as if it were
a URI but the ability to carry this information might be something very
useful.

Jim

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 17 Jun 2020 22:38:16 +0200

Hi Jim,

> [ ["coap", "coap+tls"], "example.com", ".well-known", "core"]

The protocol negotiation work has seen less activity than I'd like to
have put into it, but the latest proposals go in the direction of
avoiding URI aliasing altogether:

Even though a TLS transport is offered, the server would be addressed as
'coap://server/path' by virtue of an (explicit or, later, implied /
compressed) Proxy-Scheme option; links there would use the canonical
form and may contain hints in attributes expressing that "the target's
server is also accepting connections using this or that protocol".

Having a shortcut in CRIs sounds tempting, but I dread the
translatability to the rest of the web ecosystem where those are
unavailable, and the need to deal with aliased URIs in general.

KR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jun 2020 23:00:16 +0200

> unavailable, and the need to deal with aliased URIs in general.

Right.

So the question really is:

If we do our own URI variant, do we go all the way and exploit the benefits of having our own variant, even as a superset of URIs, or do we remain stuck with the URIs as they have been for a quarter century?

I’m maybe a bit more on the audacious side here, as long as we can keep the subset of CRIs that maps 1:1 to URIs large enough.  Apart from transport (really: plumbing) hints in URIs, we have always missed security hints (beyond the coaps bit) there.  I think if we could solve this problem, the divergence from URIs might be worth it — that is much less certain just for the plumbing.

The way these security hints could look like is of course way out in research land; if we want to explore this, we should have an extensible base architecture for CRIs and layer on that.

On the plumbing side, I think we already have seen that we need to associate at least a port number with a transport alternative, so we would not just enumerate URI schemes.

In the end, this could solve the aliasing issue as well, albeit only on the CRI side.

Grüße, Carsten