Subject: [core] ue of resource type in collections

From: Peter van der Stok <[email-masked]>
Date: Mon, 09 Jul 2018 10:09:32 +0200

Dear CoRE,

In the coaps-est draft presented in ACE, I ran into the following
question:
The coaps-est server uses a collection of resources:
The collection resource has been assigned rt=ace.est
It is not clear what the resource types of the underlying resources
should be. 
Will they all have rt=ace.est as well
or will each underlying resource need a separate resource type

The choice for the est-coaps example is:

REQ: GET /.well-known/core?rt=ace.est
RES: 2.05 Content
</est>; rt="ace.est"
</est/crts>;rt="ace.est"
</est/sen>;rt="ace.est"
</est/sren>;rt="ace.est"
</est/att>;rt="ace.est"
</est/skg>;rt="ace.est"

OR an example alternative:
REQ: GET /.well-known/core?rt=ace.est.*
RES: 2.05 Content
</est>; rt="ace.est"
</est/crts>;rt="ace.est.crts"
</est/sen>;rt="ace.est.sen"
</est/sren>;rt="ace.est.sren"
</est/att>;rt="ace.est.att"
</est/skg>;rt="ace.est.skg"

Looking forward to your thoughts and ideas.

A volunteer that writes a draft about the structure of the rt= name
space would be welcome indeed.

Peter 
-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org [1]
tel NL: +31(0)492474673     F: +33(0)966015248 

Links:
------
[1] http://www.vanderstok.org

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 18 Jul 2018 14:00:09 +0000

Peter van der Stok wrote:
> It is not clear what the resource types of the underlying resources should
> be.

According to BCP 190 [1], the coaps-est draft should not mandate particular forms of URI substructure. So a server should be free to structure URIs as it sees fit, e.g.:

</a>;rt="ace.est"
</b>;rt="ace.est"
</c>;rt="ace.est"
</d>;rt="ace.est"
</e>;rt="ace.est"
</f>;rt="ace.est"

If a client has trouble selecting the right link from the above list (and they all look interchangeable to me), then you'd need to provide more specific link information, e.g.:

</a>;rt="ace.est.skg"
</b>;rt="ace.est.crts"
</c>; rt="ace.est"
</d>;rt="ace.est.att"
</e>;rt="ace.est.sren"
</f>;rt="ace.est.sen"

Klaus

[1] https://tools.ietf.org/html/bcp190

---

From: Michel Veillette <[email-masked]>
Date: Thu, 19 Jul 2018 13:54:53 +0000

The recommended list of CoAP resources listed in the original email conflict with current CoMI recommended resource (/c). To minimize the likelihood of conflicts, I recommend to define these resources under a single root resource.

For example:

Regards,
Michel

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: Wednesday, July 18, 2018 10:00 AM
To: [email-masked]; Core <[email-masked]>
Subject: Re: [core] ue of resource type in collections

Peter van der Stok wrote:
> The collection resource has been assigned rt=ace.est It is not clear 
> what the resource types of the underlying resources should be.

</a>;rt="ace.est"
</b>;rt="ace.est"
</c>;rt="ace.est"
</d>;rt="ace.est"
</e>;rt="ace.est"
</f>;rt="ace.est"

</a>;rt="ace.est.skg"
</b>;rt="ace.est.crts"
</c>; rt="ace.est"
</d>;rt="ace.est.att"
</e>;rt="ace.est.sren"
</f>;rt="ace.est.sen"

Klaus

[1] https://tools.ietf.org/html/bcp190
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 19 Jul 2018 14:13:53 +0000

Hi Michel,

the point is that a server is free to organize its URI space as it sees fit and link annotations are needed to find the right resource.

It's not possible to reserve URI paths for any purpose (with the exception of .well-known paths). You can use /c in your examples if you want, but you cannot mandate that implementations do the same or claim it for CoMI. And I don't think it's time well spent if we'd try to ensure that no example uses a path that already appears in another example.

Klaus

> From: Michel Veillette <[email-masked]>
> Sent: Thursday, 19 July, 2018 15:55
> To: Klaus Hartke <[email-masked]>;
> [email-masked]; Core <[email-masked]>
> Subject: RE: [core] ue of resource type in collections
> 
> The recommended list of CoAP resources listed in the original email conflict
> with current CoMI recommended resource (/c). To minimize the likelihood of
> conflicts, I recommend to define these resources under a single root
> resource.
> 
> For example:
> According to BCP 190 [1], the coaps-est draft should not mandate particular
> forms of URI substructure. So a server should be free to structure URIs as it
> sees fit, e.g.:
> 
> </a>;rt="ace.est"
> </b>;rt="ace.est"
> </c>;rt="ace.est"
> </d>;rt="ace.est"
> </e>;rt="ace.est"
> </f>;rt="ace.est"
> 
> If a client has trouble selecting the right link from the above list (and they all
> look interchangeable to me), then you'd need to provide more specific link
> information, e.g.:
> 
> </a>;rt="ace.est.skg"
> </b>;rt="ace.est.crts"
> </c>; rt="ace.est"
> </d>;rt="ace.est.att"
> </e>;rt="ace.est.sren"
> </f>;rt="ace.est.sen"
> 
> Klaus
>

---

From: Michel Veillette <[email-masked]>
Date: Thu, 19 Jul 2018 14:48:10 +0000

Hi Klaus

I understand that resource assignments are not compulsory, only recommended. Avoiding conflicts between these recommendations within IETF and with other well known ecosystems should just benefit the CoAP community.

Michel

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Thursday, July 19, 2018 10:14 AM
To: Michel Veillette <[email-masked]>; [email-masked]; Core <[email-masked]>
Subject: RE: [core] ue of resource type in collections

Hi Michel,

Klaus

> The recommended list of CoAP resources listed in the original email 
> conflict with current CoMI recommended resource (/c). To minimize the 
> likelihood of conflicts, I recommend to define these resources under a 
> single root resource.
> 
> For example:
> According to BCP 190 [1], the coaps-est draft should not mandate 
> particular forms of URI substructure. So a server should be free to 
> structure URIs as it sees fit, e.g.:
> 
> </a>;rt="ace.est"
> </b>;rt="ace.est"
> </c>;rt="ace.est"
> </d>;rt="ace.est"
> </e>;rt="ace.est"
> </f>;rt="ace.est"
> 
> If a client has trouble selecting the right link from the above list 
> (and they all look interchangeable to me), then you'd need to provide 
> more specific link information, e.g.:
> 
> </a>;rt="ace.est.skg"
> </b>;rt="ace.est.crts"
> </c>; rt="ace.est"
> </d>;rt="ace.est.att"
> </e>;rt="ace.est.sren"
> </f>;rt="ace.est.sen"
> 
> Klaus
>

---

From: Peter van der Stok <[email-masked]>
Date: Fri, 20 Jul 2018 08:56:10 -0300

Thanks Klaus for the comments.
The new resource types have to be registered, and can then be used in an
interoperable way for discovery.
That makes it difficult to not prescribe them in the draft.
Given that some of the resources in the collection are not compulsory to
have,
I will provide the more extensive example no 2 in est-coaps.

Greetings,

Peter
Klaus Hartke schreef op 2018-07-18 11:00:

> According to BCP 190 [1 [1]], the coaps-est draft should not mandate particular forms of URI substructure. So a server should be free to structure URIs as it sees fit, e.g.:
> 
> </a>;rt="ace.est"
> </b>;rt="ace.est"
> </c>;rt="ace.est"
> </d>;rt="ace.est"
> </e>;rt="ace.est"
> </f>;rt="ace.est"
> 

Links:
------

---

From: Bill Silverajan <[email-masked]>
Date: Mon, 23 Jul 2018 11:50:44 +0300

Hi Peter,

I have admittedly not gone through the coaps-est draft in detail, but 
draft-ietf-core-interfaces-12 provides a way to define and use resource 
collections, as well as items in the collections. Additionally both RFC 
6573 as well as RFC 6690 discuss resource collections to a certain point.

The resource collection in draft-ietf-core-interfaces-12 provides a 
flexible entry point, and each item in the collection can still retain 
the resource type "ace.est"

Best regards,
Bill

On 20/07/18 14:56, Peter van der Stok wrote:
> The new resource types have to be registered, and can then be used in 
> an interoperable way for discovery.
> Given that some of the resources in the collection are not compulsory 
> to have,
>>> should
>> According to BCP 190 [1 <https://tools.ietf.org/html/bcp190>], the 
>> coaps-est draft should not mandate particular forms of URI 
>> substructure. So a server should be free to structure URIs as it sees 
>> fit, e.g.:
>>
>> </a>;rt="ace.est"
>> </b>;rt="ace.est"
>> </c>;rt="ace.est"
>> </d>;rt="ace.est"
>> </e>;rt="ace.est"
>> </f>;rt="ace.est"
>>