[core] protocol-negotiation and web linking

[Christian Amsüss <[e-mail]>]

Hello Bill and Mert,

during the review of protocol-negotiation, I came up with an idea that
is too far off from the document to go directly into a review. It might
be an overdose of web-linking talking here, so feel free to dismiss it
if need be, but maybe there are ideas in it that can help bring on p-n.

Let me start with examples and then explain what they should mean:

| Req: GET coap://node1/.well-known/core
| Res: 2.05 Content, Payload:
| <>;alt-base="coap+tcp://node1",
| </sensor/temp>;if="core.s"

or when registering at the RD:

| Req: POST /rd?ep=node1&con=coap://node1
| <>;alt-base="coap+tcp://node1",
| </sensor/temp>;if="core.s"
| Res: 2.01 Created, Location: /reg/1234

The endpoint registering at the RD could update the alt-base value(s) of
the link like it would update any other link it manages. (Admittedly,
that part of RD got postponed; might look like PATCH /reg/1234, Payload
{"1": {"href": "", "alt-base": ["coap+tcp://node1:1234"]}} in some
upcoming JSON link patch format).

Resource lookups would stay the same. Asking a server directly for
alternative transports could be done with GET
/.well-known/core?alt-base=* or /.well-known/core?alt-base=coap+ws://*.
This would be a dedicated request rather than piggy-backing onto any
existing one with a new option, but we're doing the same with any of the
other resource metadata as well, and a .well-known/core discovery is
often the first step in interaction anyway.

One way to give the protocol negotiation meaning to this would be only
two normative sentences:

| An "alt-base" attribute on a link means that representations of the link
| target are equally valid if the attribute's value were assigned as Base
| URI of the encapsulating entity (RFC3986 Section 5.1.2) for the purpose
| of resolving relative references in the document. URIs obtained from the
| representation using any alt-base value are all related to the URI
| obtained from the same reference without considering the alt-base
| attribute by the "alternative" relation (and therefore to each other, as
| that relation is transitive).

(I've picked the "alternative" relation here; see my review comments on
the `ol` attribute. If no link relation is deemed suitable and you stay
with `ol`, the second sentence would need to say that they are
"equivalent for all REST operations supported by their protocols".)


The approach of transmitting the URI data in link attributes is
motivated by the RD's desire to not be anything more than a cache of
what can be discovered using .well-known/core discovery.


The explanation of being an "alternative Base URI" rather than a generic
alternative transport could be a middle ground between saying that only
a single URI is available somewhere else and saying that everything on
this address is available there: It only makes statements about the
links in the presented document. This would allow groups of resources to
state their equivalences.


The approach suggested here has some drawbacks: It is a bit more verbose
in terms of transmitted bytes, and requires constrained nodes to
synthesize variable data into payload that we usually take pride in
being able to assemble at build time. If there is interest in the
approach at all, I think we can overcome those.


Best regards
Christian

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