chrysn
commented
6 years ago 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
Hi Peter,
Sounds like we are basically on the same page.
In RFC6690 links, "href" always points to the target of the link, and "rel" describes the relationship between the parent resource that holds the link and the target resource. The other items are all attributes of the target resource.
So "con" refers to the registration resource, and reflects the "con" parameter that was supplied during registration.
Likewise, "ct" refers to the ct of the registration resource, that is the format that the registered links are returmed in. Anything that returns a payload has a ct.
Does it all make sense?
Best regards,
Michael
On Sep 8, 2017, at 2:46 AM, peter van der Stok stokcons@xs4all.nl wrote:
HI Michael,
For me it looks OK. A few reflections: It must be clear in accompanying text, that "href" refers to the registration and "con" to the links of the registration. And core-rd.endpoint needs to be explained in text, and registered in core registry. Further, "ct" is an attribute of the links in all RD examples and not of the registration.
Cheerio, Peter
Michael Koster schreef op 2017-09-08 10:08: Hi Peter, In your example, "loc" I presume is "location" which is how this is returned in the response header when the registration resource is created. In my example, I propose a hyperlink to a resource, so "href" is the usual key for this in a link JSON. I also propose to include all of the link attributes including rt and ct, so the client knows what it is without needing to infer anything. So your example would look like this: [ { "href" : "/rd/541", "con": "coap://[fdfd::12]:17072", "ep": "example-endpoint-name", "et": "ocf-device", "rt": "core.rd-endpoint", "ct": 40, "lt": 600, "d": "floor-3" } ] On Sep 8, 2017, at 12:25 AM, peter van der Stok stokcons@xs4all.nl wrote: Hi Michael, I would have expected: [ { "con": "coap://[fdfd::12]:17072", "loc" : "/rd/541", "ep": "example-endpoint-name", "et": "ocf-device", "lt": 600, "d": "floor-3" } ] and may be only ep and loc attributes; With this information the rest of the link information can be inferred. cheerio, Peter Michael Koster schreef op 2017-09-05 20:37: Hi Peter, The representation on slide 4 is not a complete dump, but exactly what you say; it's the locations and the registration parameters, exposed as link target attributes. The example has one "self" link for the RD itself, and one link for each registration resource (only one is shown). [ { "href": "/registration/", "rel": "self", "rt": "core.rd", "ct": 40 }, { "href": "/registration/f3cca57e/", "con": "coap://[fdfd::12]:17072" "rt": "core.rd-endpoint", "ct": 40, "ep": "example-endpoint-name", "et": "ocf-device", "lt": 600, "d": "floor-3" } ] On Sep 4, 2017, at 11:37 PM, peter van der Stok stokcons@xs4all.nl wrote: Hi Michael, Originally, I thought the same, but the packets get really large by doing a complete dump. The compromise is just sending the (endpoint names/ registration resource location) with its registration attributes. Peter Michael Koster schreef op 2017-09-05 08:27: I would propose returning links for all registration resources in the RD as shown in slide 4 of the attached deck (JSON format shown). This would include the most recent setting of the "lt" or lifetime parameter as a link target attribute as shown. On Sep 4, 2017, at 8:27 AM, Jim Schaad ietf@augustcellars.com wrote: Yes that is what I had in mind. It would be useful to add a ttl attribute as well. Jim -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: Monday, September 4, 2017 1:46 AM To: Jim Schaad ietf@augustcellars.com Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org Subject: Re: draft-ietf-core-resource-directory = GET /rd Hi Jim, Personally, I like the idea. That would mean that all registration resources are returned. In the next version of the RD, location or endpoint identifies the registration. Uniqueness of links is specified in section 5.3.4, already commented on by you. Your request means returning all locations with the ep, lt, d, and et attributes and the associated scheme://authority:port value. Correct? Peter Jim Schaad schreef op 2017-08-31 03:59: I am wondering if there should be a GET action defined against the resource directory object. Currently, if an entity does a registration for an endpoint it gets back a location for that registration. If a second entity modifies the endpoint and wants to update the registration, it currently has no method to get the location associated with the endpoint and cannot make a second new registration since the <domain, endpoint> pair is required to be unique. Thus Interaction: EP -> RD Method: GET URI Template: {+rd}{?ep,d} Content-Format: application/link-format (or variants) <rd/0099>;ep=endpoint1,<rd/0098>;ep=endpoint1;domain=beta, ... Jim