Re: [core] protocol-negotiation and web linking

Just a tourist, but can someone explain why this design needs to be so
fundamentally different to RFC 7838?

Making the means by which a resource is identified differ based on the
means of interaction is something we have tried hard to avoid in HTTP.
Or maybe this is the key point of divergence between HTTP and COAP and
any attempt to address this is a lost cause.

On Sat, Feb 24, 2018 at 10:40 PM, Christian Amsüss
<c.amsuess@energyharvesting.at> wrote:
> 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
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>