Re: [core] draft-ietf-core-resource-directory = GET /rd

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

Hello Jim, Peter and Michael,

sorry for being late to the party.

On Fri, Sep 08, 2017 at 06:58:27AM -0700, Michael Koster wrote:
> So "con" refers to the registration resource, and reflects the "con"
> parameter that was supplied during registration.

What is being proposed here looks an awful lot like the endpoint lookup
with slightly different data. To compare, the latest example from this
thread was (in RFC9960 link-format):

GET /registration/?ep=example-endpoint-name

</rd/541>;con="coap://[rdrd::12]:17072";ep=example-endpoint-name;
  et=ocf-device;rt=core-rd.endpoint;ct=40;lt=600;d=floor-3

while for such a registration, the existing lookup would be

GET /rd-lookup/ep?ep=example-endpoint-name

<coap://[rdrd::12]:17072>;ep=example-endpoint-name;
  et=ocf-device;d=floor-3


From a pure data point of view (disregarding the semantics), all that is
shown (and can be queried) from the existing lookup interface is a
subset of the proposed registrations interface.

From the semantic point of view, the former has the advantage of having
an accurate rel (the implied `hosts`, in that the resource directory
hosts the registration resource). Moreover, the target attributes are
clearer: "endpoint type" and "d" do kind of relate to the base address,
but `<coap://[rdrd::12]:17072>;ep=example-endpoint-name` is a statement
about a resource too, and that is (contrary to what we say in the
principles) not backed by the origin.

The former form is also more painless to extend to alternative
transports (protocol-negotiation could add more than one con= without it
becoming a second-class citizen, which all those would be with the
latter).


As we're reworking the lookup interface anyway, can we just use the
former representations in the endpoint lookup? It'd keep the
registration and lookup interfaces neatly separated as they are, be more
precise about target attributes and more discoverable in a hypertext
sense.

Best regards
Christian

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn