Subject: [core] CoRE link-format href relation duplication?

From: Michael Koster <[email-masked]>
Date: Fri, 3 Jul 2015 18:41:31 -0700

Hi,

I can’t find where we prohibit link-format collections from having duplicate href values as per the following example:

</3/0/7>;ep=1;dim=8;gt=50;lt=42.2,
</3/0/7>;ep=2;dim=8;pmax=300;gt=80;lt=75.5
What happens if, for example, an endpoint creates these two links in it’s .well-known/core resource or registers these two links in a resource directory? 

Michael

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 04 Jul 2015 06:53:39 +0200

Right.  Generally speaking, multiple links can have the same href.  That
is the reason links-json is not a map from href values to attributes,
but an array of objects where href is treated as if it were another
attribute.

Now the specific example has a problem because the attributes there are
meant to have a single value per resource.  But that is a property of
the attribute.  The below would not exhibit this problem:

</3/0/7>;ep=1;dim=8,
</3/0/7>;pmax=300;gt=80;lt=75.5

Grüße, Carsten

Michael Koster wrote:
> Hi,
> 
> I can’t find where we prohibit link-format collections from having
> duplicate href values as per the following example:
> 
> |</3/0/7>;ep=1;dim=8;gt=50;lt=42.2,
> </3/0/7>;ep=2;dim=8;pmax=300;gt=80;lt=75.5|
> 
> What happens if, for example, an endpoint creates these two links in
> it’s .well-known/core resource or registers these two links in a
> resource directory? 
> 
> Michael
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Michael Koster <[email-masked]>
Date: Sat, 4 Jul 2015 10:28:27 -0700

Thanks, that’s what I would expect. 

The example, from LWM2M, is meant to provide for discovery of multiple observers on a resource, each with different notification attributes. This is an example of multiple values for an attribute of a given resource. 

In this example, there re 2 LWM2M servers (as CoAP clients) observing the resource. ep=1 means "short server ID “ and ep=2 is for short server ID 2

To interpret this, I need to group href and ep as a tuple and associate the following relations with each tuple of (href, ep). This seems strange to me and I’d like to think of a better way. 

On a related subject, I’m updating the CoRE Interfaces draft, and in particular cleaning up the specification around binding attributes in 4.1 and resource observation attributes in 5.9 (pmin, pmax,lt, gt, st). In section 5.9 it states that the query parameters MUST be treated as resources that are read using GET and set using PUT.

I am proposing to add GET link-format to the function set of observable interfaces for reading the attributes back from a resource. But this introduces a question when there is more than one CoAP client observing a resource and each is allowed to set the attributes. Should we constrain to just one set of attributes per resource and define some rules for what happens when multiple clients set attributes differently? Or should we try to provide for multiple sets of attributes to be concurrently active. If so, should we provide a discovery or read method?

Michael