Subject: [core] Resource Directory - Returned items from Lookup resources

From: Jim Schaad <[email-masked]>
Date: Fri, 8 Sep 2017 13:47:57 -0700

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

---

From: peter van der Stok <[email-masked]>
Date: Fri, 15 Sep 2017 11:48:45 +0200

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.

> going to be returned with the resource.

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

> address for an endpoint or if it is just the scheme + authority (i.e. 

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.

> it does make a difference for the cbor and json formats.

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

> 4.  I assume that the 'et' parameter should be returned on all end 
et can have no value; IMO do not return anything.
> pre-configured default domain) - as an empty string or as just the 

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

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

---

From: Jim Schaad <[email-masked]>
Date: Fri, 15 Sep 2017 16:14:51 -0700

See inline

> -----Original Message-----
> From: peter van der Stok [mailto:[email-masked]]
> Sent: Friday, September 15, 2017 2:49 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [core] Resource Directory - Returned items from Lookup
> resources
> 
> Hi Jim,
> 
present
> my opinion.
> These issues are also related with the properties of the anchor parameter.
> > 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.

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

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

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

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

---

From: peter van der Stok <[email-masked]>
Date: Wed, 20 Sep 2017 10:00:22 +0200

Hi Jim,

just to check our agreement.

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Sep 2017 10:12:25 -0700

See below.

> Sent: Wednesday, September 20, 2017 1:00 AM
> Cc: [email-masked]; draft-ietf-core-resource-
> [email-masked]; [email-masked]
> >> An attribute can have zero values. In that case (IMO) I assume
> >> nothing is returned.
> >
> > 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.
> >
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="

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

---

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

Hello Jim and Peter,

On Fri, Sep 15, 2017 at 04:14:51PM -0700, Jim Schaad wrote:
> > > 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).
> > 
> > suggested in the examples, also difficult to understand.  IMO the
> > href value should be returned between <> brackets, and the con as an
> > additional attribute.
> 

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

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn

---

From: chrysn <[email-masked]>
Date: Thu, 21 Sep 2017 16:20:56 +0200

Hello Jim, hello Peter,

On Wed, Sep 20, 2017 at 10:12:25AM -0700, Jim Schaad wrote:
> 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

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom