[core] Resource Directory - Returned items from Lookup resources

[Jim Schaad]

I am trying to figure out what items are going to be returned from a lookup
query and I do not believe that the set of items in the examples is what
should be followed.

1. I am going to assume that all attributes registered with a resource are
going to be returned with the resource.

2. I am unclear if the context is what should be returned as the link
address for an endpoint or if it is just the scheme + authority (i.e. omit
any path portion).

3. For the domain and group lookups, is the href an empty string or is it
absent? This does not make a different for the standard link formation, but
it does make a difference for the cbor and json formats.

4. I assume that the 'et' parameter should be returned on all end points.

5. How would an empty domain name be returned (this is my current
pre-configured default domain) - as an empty string or as just the attribute
name - i.e d or d="" ?

Jim

[peter van der Stok]

Hi Jim,

Again thanks. You mention controversial subjects; and I am going to
present my opinion.
These issues are also related with the properties of the anchor
parameter.
I am looking forward to reasoned alternatives by co-authors.

Post by Jim Schaad
I am trying to figure out what items are going to be returned from a lookup
query and I do not believe that the set of items in the examples is what
should be followed.
1. I am going to assume that all attributes registered with a resource are
going to be returned with the resource.

An attribute can have zero values. In that case (IMO) I assume nothing
is returned.

Post by Jim Schaad
2. I am unclear if the context is what should be returned as the link
address for an endpoint or if it is just the scheme + authority (i.e. omit
any path portion).

I find the concatenation of "con" and "href" values, as currently
suggested in the examples, also difficult to understand.
IMO the href value should be returned between <> brackets, and the con
as an additional attribute.

Post by Jim Schaad
3. For the domain and group lookups, is the href an empty string or is it
absent? This does not make a different for the standard link
formation, but
it does make a difference for the cbor and json formats.

@ Michael can you answer, being involved in the link-json document

Post by Jim Schaad
4. I assume that the 'et' parameter should be returned on all end points.

et can have no value; IMO do not return anything.

Post by Jim Schaad
5. How would an empty domain name be returned (this is my current
pre-configured default domain) - as an empty string or as just the attribute
name - i.e d or d="" ?

Actually the d= can have no value, and IMO like et, do not return
anything when there is no value.

Post by Jim Schaad
Jim

cheerio,

peter

Post by Jim Schaad
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Jim Schaad]

See inline

-----Original Message-----
Sent: Friday, September 15, 2017 2:49 AM
Subject: Re: [core] Resource Directory - Returned items from Lookup
resources
Hi Jim,
Again thanks. You mention controversial subjects; and I am going to

present

my opinion.
These issues are also related with the properties of the anchor parameter.
I am looking forward to reasoned alternatives by co-authors.

Post by Jim Schaad
I am trying to figure out what items are going to be returned from a
lookup query and I do not believe that the set of items in the
examples is what should be followed.
1. I am going to assume that all attributes registered with a
resource are going to be returned with the resource.

An attribute can have zero values. In that case (IMO) I assume nothing is
returned.

I don't understand what you mean by an attribute which has zero values. Do
you consider presence to be a value? I.e. consider the "obs" attribute, it
has no value but it can either be present or absent.

This was just a statement say that if an attribute was set when it was
registered, then it should also be returned as part of the data for the
resource. I don't think this is a very exciting idea, just common sense.

Post by Jim Schaad
2. I am unclear if the context is what should be returned as the link
address for an endpoint or if it is just the scheme + authority (i.e. omit
any path portion).

I find the concatenation of "con" and "href" values, as currently

suggested in

the examples, also difficult to understand.
IMO the href value should be returned between <> brackets, and the con as
an additional attribute.

I would find that logical, even if it makes the client side more difficult
to build the entire URI.

Post by Jim Schaad
3. For the domain and group lookups, is the href an empty string or
is it absent? This does not make a different for the standard link
formation, but it does make a difference for the cbor and json
formats.

@ Michael can you answer, being involved in the link-json document

Post by Jim Schaad
4. I assume that the 'et' parameter should be returned on all end points.

et can have no value; IMO do not return anything.

Do you mean, do not synthesis a value from the registration and add it?
That would be fine with me.

Post by Jim Schaad
5. How would an empty domain name be returned (this is my current
pre-configured default domain) - as an empty string or as just the
attribute name - i.e d or d="" ?

Actually the d= can have no value, and IMO like et, do not return anything
when there is no value.

I think I understand this.

Jim

Post by Jim Schaad
Jim

cheerio,
peter

Post by Jim Schaad
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[peter van der Stok]

Hi Jim,

just to check our agreement.

Post by Jim Schaad

Post by Jim Schaad
1. I am going to assume that all attributes registered with a
resource are going to be returned with the resource.

An attribute can have zero values. In that case (IMO) I assume nothing is
returned.

I don't understand what you mean by an attribute which has zero values.
Do
you consider presence to be a value? I.e. consider the "obs"
attribute, it
has no value but it can either be present or absent.
This was just a statement say that if an attribute was set when it was
registered, then it should also be returned as part of the data for the
resource. I don't think this is a very exciting idea, just common sense.

When creating a link registration, some attributes must have a value.
There are attributes which may have no value.
When such an attribute value has not been specified in the link
registration process, the attribute has zero values in my words.
I that case the lookup, query does not return anything for that
attribute, not even "att="

Does that make sense?

Peter

[Jim Schaad]

See below.

-----Original Message-----
Sent: Wednesday, September 20, 2017 1:00 AM
Subject: Re: [core] Resource Directory - Returned items from Lookup
resources
Hi Jim,
just to check our agreement.

Post by Jim Schaad

Post by peter van der Stok

Post by Jim Schaad
1. I am going to assume that all attributes registered with a
resource are going to be returned with the resource.

An attribute can have zero values. In that case (IMO) I assume
nothing is returned.

I don't understand what you mean by an attribute which has zero values.
Do
you consider presence to be a value? I.e. consider the "obs" attribute, it
has no value but it can either be present or absent.
This was just a statement say that if an attribute was set when it was
registered, then it should also be returned as part of the data for
the resource. I don't think this is a very exciting idea, just common
sense.

When creating a link registration, some attributes must have a value.
There are attributes which may have no value.
When such an attribute value has not been specified in the link

registration

process, the attribute has zero values in my words.
I that case the lookup, query does not return anything for that attribute,

not

even "att="
Does that make sense?

I think that I agree with the principle, but not the words you are using. I
do wonder if there are cases where an RD will synthesis attributes based on
other registrations or pre-configuration. As an example, it might return
the "gp" attribute on an endpoint based on known group memberships.

Jim

Peter

[chrysn]

Hello Jim, hello Peter,

I do wonder if there are cases where an RD will synthesis attributes
based on other registrations or pre-configuration. As an example, it
might return the "gp" attribute on an endpoint based on known group
memberships.

From my understanding and the current examples, no attributes are ever
synthesized into resource lookups.

(The anchor values from the other half of the thread are no exception
here; they are not synthesized, but just defaults that need to be spellt
out because otherwise the meaning would change.)

As for non-resource lookups (endpoint and group), I can't answer that,
but I'd assume that it's up to the implementation whether absent
attributes are left absent or shown with a default or configured value.

Best regards
Christian

[Christian Amsüss]

Hello Jim and Peter,

Post by Jim Schaad

Post by peter van der Stok

Post by Jim Schaad
2. I am unclear if the context is what should be returned as the
link address for an endpoint or if it is just the scheme +
authority (i.e. omit any path portion).

I find the concatenation of "con" and "href" values, as currently
suggested in the examples, also difficult to understand. IMO the
href value should be returned between <> brackets, and the con as an
additional attribute.

I would find that logical, even if it makes the client side more difficult
to build the entire URI.

as I view the resource lookup, that interface should be usable for
clients without awareness of what a resource directory is. (For example,
a temperature display that is used to fetch all temperatures from a
given device should be able to use
`coap://configued-rd/lkp/res?d=my-domain` as its configured address and,
by the same rules by which it'd discover a single device's temperatures,
display all the domains').

For that, and to faithfully represent not only the links but also the
link relations, a lookup result should be

</temp/1>;rt="temp.inside";anchor="coap://first-device",
</temp/1>;rt="temp.inside";anchor="coap://second-device"

Thus, href stays as it was registered, all attributes stay as they are
(including the implied rel="hosts"), but the implicit
anchor="coap://first-device";rel="hosts" that all lines from a lookup to
coap://first-device/.well-known/core would carry is made explicit where
different defaults would take over otherwise.

In other words, the con= value of the registered endpoint is expressed
as anchor in the EP lookup because that precisely fits its meaning.

(AFAIR this is something we've also talked about in Prague, and I should
probably write a pull request that brings the examples in line).

Best regards
Christian