Do we need dedicated URIs for "the endpoint behind a CoAP URI"?

[chrysn]

Currently we can identify arbitrary resources on a CoAP server (coap://address/path), but not the CoAP server behind that address itself.

This will hit us when we want to express a statement like HTTP's Alt-Svc: coap+tcp=:5683 in a Web Link like <coap+tcp://same-host:5683>;rel=alt-svc

It'd be possible to use plain coap://address there, but that already means "the resource at path / on that server" as well, and using the same term for different things can be confusing.

Other areas where the same question comes up:

• CoRE RD's endpoint addresses: circumvented there by only talking about base URIs against which to resolve relative references
• Identifying proxy servers: This is particularly relevant to our use case, as treating an alternative transport like a single-route proxy is an option (cf. https://github.com/t2trg/transports/issues/5#issuecomment-511742499). Proxies in HTTP have traditionally been identified by just telling the URI of their empty path.

[chrysn]

I think that with good wording of the relation types, we can just use coap+x URIs without paths. Even though we'd probably recommend it, terms like in the strawman proposal could even be used with paths (think of the proxy as a "function set" that defines all resources "under" it, and that could run on a sub-path or even proxy only the things behind a sub-path).

Keeping this open for further consideration, but I'd stick with "we can just use the URIs as they are".