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

From: peter van der Stok <[email-masked]>
Date: Mon, 04 Sep 2017 10:45:35 +0200

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 4 Sep 2017 08:27:00 -0700

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:[email-masked]]
> Sent: Monday, September 4, 2017 1:46 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-ietf-core-resource-directory = GET /rd
> 
> Hi Jim,
> 
registration.
> Uniqueness of links is specified in section 5.3.4, already commented on by
> you.
attributes
> and the associated scheme://authority:port value.
> 
> Correct?
> 
> Peter
> 
> > 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

---

From: Michael Koster <[email-masked]>
Date: Mon, 4 Sep 2017 23:27:54 -0700

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 <[email-masked]> wrote:
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: peter van der Stok <[email-masked]>
Date: Tue, 05 Sep 2017 08:37:24 +0200

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.
> 
> 
> 
>

---

From: Michael Koster <[email-masked]>
Date: Tue, 5 Sep 2017 11:37:30 -0700

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 <[email-masked]> 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
> 
>

---

From: Jim Schaad <[email-masked]>
Date: Tue, 5 Sep 2017 18:12:31 -0700

I think that Michael and I are saying the same thing in terms of what the
"content" of the resource is.  

I am not sure that I think that having the "self" node in the registration
is useful, but that would be a different issue.

Jim

From: Michael Koster [mailto:[email-masked]] 
Sent: Tuesday, September 5, 2017 11:38 AM
To: [email-masked]
Cc: Jim Schaad <[email-masked]>;
[email-masked]; [email-masked]
Subject: Re: [core] draft-ietf-core-resource-directory = GET /rd

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).

[

  {

    "rel": "self",

    "rt": "core.rd",

    "ct": 40

  },

  {

    "ct": 40,

    "et": "ocf-device",

    "lt": 600,

    "d": "floor-3"

  }

]

On Sep 4, 2017, at 11:37 PM, peter van der Stok <[email-masked]
<mailto:[email-masked]> > 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

On Sep 4, 2017, at 8:27 AM, Jim Schaad <[email-masked]
<mailto:[email-masked]> > 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:[email-masked]]
Sent: Monday, September 4, 2017 1:46 AM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked]
<mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 

registration.

attributes

_______________________________________________
core mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/core

---

From: peter van der Stok <[email-masked]>
Date: Fri, 08 Sep 2017 09:25:25 +0200

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).
> 
> [
>   {

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Sep 2017 01:08:29 -0700

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 <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 <[email-masked]> wrote:
> 
> Hi Michael,
> 
> I would have expected:
> 
> [
>   {

---

From: peter van der Stok <[email-masked]>
Date: Fri, 08 Sep 2017 11:46:49 +0200

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.
> 
> 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.
>

---

From: Michael Koster <[email-masked]>
Date: Fri, 8 Sep 2017 06:58:27 -0700

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 <[email-masked]> wrote:
> 
> HI Michael,
> 
> 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
>

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 21 Sep 2017 15:05:15 +0200

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