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

Discussion:

Jim Schaad

2017-08-31 01:59:44 UTC

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

peter van der Stok

2017-09-04 08:45:35 UTC

Permalink

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

Post by Jim Schaad
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

Jim Schaad

2017-09-04 15:27:00 UTC

Permalink

Yes that is what I had in mind. It would be useful to add a ttl attribute
as well.

Jim

-----Original Message-----
Sent: Monday, September 4, 2017 1:46 AM
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

Post by Jim Schaad
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

Michael Koster

2017-09-05 06:27:54 UTC

Permalink

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.

peter van der Stok

2017-09-05 06:37:24 UTC

Permalink

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

Post by Michael Koster
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.

Post by Jim Schaad
Yes that is what I had in mind. It would be useful to add a ttl attribute
as well.
Jim

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

Post by Jim Schaad
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

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

Michael Koster

2017-09-05 18:37:30 UTC

Permalink

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"
}
]

Post by Jim Schaad
Yes that is what I had in mind. It would be useful to add a ttl attribute
as well.
Jim

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

Post by Jim Schaad
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

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

Jim Schaad

2017-09-06 01:12:31 UTC

Permalink

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:***@gmail.com]
Sent: Tuesday, September 5, 2017 11:38 AM
To: ***@vanderstok.org
Cc: Jim Schaad <***@augustcellars.com>;
draft-ietf-core-resource-***@ietf.org; ***@ietf.org
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).

[

{

"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 <***@xs4all.nl
<mailto:***@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 <***@augustcellars.com
<mailto:***@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:***@xs4all.nl]
Sent: Monday, September 4, 2017 1:46 AM
To: Jim Schaad <***@augustcellars.com <mailto:***@augustcellars.com> >
Cc: draft-ietf-core-resource-***@ietf.org
<mailto:draft-ietf-core-resource-***@ietf.org> ; ***@ietf.org
<mailto:***@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

peter van der Stok

2017-09-08 07:25:25 UTC

Permalink

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

Post by Michael Koster
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"
}
]

Post by peter van der Stok
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
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.
Yes that is what I had in mind. It would be useful to add a ttl attribute
as well.
Jim
-----Original Message-----
Sent: Monday, September 4, 2017 1:46 AM
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
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

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

Michael Koster

2017-09-08 08:08:29 UTC

Permalink

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"
}
]

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

peter van der Stok

2017-09-08 09:46:49 UTC

Permalink

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

Post by Michael Koster
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.
[
{
"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"
}
]

Post by peter van der Stok
Hi Michael,
[
{
"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
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"
}
]
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
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.
Yes that is what I had in mind. It would be useful to add a ttl attribute
as well.
Jim
-----Original Message-----
Sent: Monday, September 4, 2017 1:46 AM
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
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
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

Michael Koster

2017-09-08 13:58:27 UTC

Permalink

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

Post by peter van der Stok
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

Post by peter van der Stok
Hi Michael,
[
{
"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
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"
}
]
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
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.
Yes that is what I had in mind. It would be useful to add a ttl attribute
as well.
Jim
-----Original Message-----
Sent: Monday, September 4, 2017 1:46 AM
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
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
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

Christian Amsüss

2017-09-21 13:05:15 UTC

Permalink

Hello Jim, Peter and Michael,

sorry for being late to the party.

Post by Michael Koster
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