Subject: [core] draft-hartke-t2trg-coral-reef

From: Jim Schaad <[email-masked]>
Date: Tue, 16 Jul 2019 09:22:34 -0700

Looking at doing more implementation work on this - specific the
registration side rather than the retrieval side.

1.  Looking at section 5.2.5 - "Create Resource Registration"  I am going to
assume that you are keeping the same command line as what the current
document does, but I wonder if a better way to do it would be to use the
following as a resource

#using <http:/coreapps.org/reef#>
rd-unit <coap://[2001:db8:4::1]/> [
ep "node1"
domain "Floor 1"
lt 3600
et "LightBar"
rd-item <light/left> [rt "light" ct 0]
rd-item <light/middle> [rt "light" ct 0]
rd-item<light/middle> [rt "light" ct 0]
]

This has the advantage that all of the query parameters are moved into the
content which is going to make things easier to have new unknown items show
up.  I would think that it is just fine to restrict this to a single
rd-unit, but for third party registration it might be reasonable to allow
multiple rd-units to occur in a single body.

2.  A registration update could then have either the same as the content in
1 - or just an array of rd-items.  In the first case the attributes
associated with the endpoint would replaced - except for the ep and domain
attributes, in the second case just the items associated with it would be
replaced.

3.  If the CoRAL format is used, are the paging attributes still going to be
supported to keep the document size down?   Does not say anywhere.

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 16 Jul 2019 19:49:21 +0200

Hi Jim!

> Looking at doing more implementation work on this

> attributes, in the second case just the items associated with it would be

Moving query parameters into the content to make it easier to have new
unknown items seems like a good idea.

I'd have a more general question though: What are really trying to
model in our resource directories? Is it really that interesting to
model CoAP servers and the CoAP resources hosted by them? Or wouldn't
it be much more useful to model light bulbs, light switches and living
rooms, or coffee machines, coffee orders and coffee cups -- how they
relate to each other and how they can be interacted with using CoAP?

(See <https://mailarchive.ietf.org/arch/msg/t2trg/Q186viXtj0-r9vWEge31yuUm35c>
for related thoughts.)

> supported to keep the document size down?   Does not say anywhere.

If I remember correctly, there was a discussion on this a while ago
that came to the conclusion that block-wise transfers might be good
enough here. If that's not the case, let's have another discussion.

Klaus

---

From: Jim Schaad <[email-masked]>
Date: Tue, 16 Jul 2019 11:32:01 -0700

-----Original Message-----
From: Klaus Hartke <[email-masked]> 
Sent: Tuesday, July 16, 2019 10:49 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; core <[email-masked]>
Subject: Re: [core] draft-hartke-t2trg-coral-reef

Hi Jim!

❤️️:heart:

> 1.  Looking at section 5.2.5 - "Create Resource Registration"  I am 
> going to assume that you are keeping the same command line as what the 
> current document does, but I wonder if a better way to do it would be 
> to use the following as a resource
>
> rd-item <light/left> [rt "light" ct 0] rd-item <light/middle> [rt 
> "light" ct 0] rd-item<light/middle> [rt "light" ct 0] ]
>
> This has the advantage that all of the query parameters are moved into 
> the content which is going to make things easier to have new unknown 
> items show up.  I would think that it is just fine to restrict this to 
> a single rd-unit, but for third party registration it might be 
> reasonable to allow multiple rd-units to occur in a single body.
>
> associated with the endpoint would replaced - except for the ep and 
> domain attributes, in the second case just the items associated with 
> it would be replaced.

Moving query parameters into the content to make it easier to have new unknown items seems like a good idea.

I'd have a more general question though: What are really trying to model in our resource directories? Is it really that interesting to model CoAP servers and the CoAP resources hosted by them? Or wouldn't it be much more useful to model light bulbs, light switches and living rooms, or coffee machines, coffee orders and coffee cups -- how they relate to each other and how they can be interacted with using CoAP?

[JLS] I think that it may be true that we want to do this, but I think that means that we need to think about how that would work in a slightly different way for other things.  However, I think that what I proposed above is the first step to what you are looking for.     You are going to want to publish the "tree" view of the device to the server which is basically what I am doing.  Just how some of the query functions are going to work may be a bit different, but I don't know.  

[JLS]  I may just be completely off base however as I likely don't understand how all of this works with the depth of being able to think about all of the corner cases very well.

Jim

> supported to keep the document size down?   Does not say anywhere.

If I remember correctly, there was a discussion on this a while ago that came to the conclusion that block-wise transfers might be good enough here. If that's not the case, let's have another discussion.

Klaus

---

From: Jim Schaad <[email-masked]>
Date: Tue, 16 Jul 2019 12:08:48 -0700

One of the things we are going have to make sure is that if representations of data can be published to the RD that it does not become a pub/sub server.

Jim

-----Original Message-----
From: core <[email-masked]> On Behalf Of Jim Schaad
Sent: Tuesday, July 16, 2019 11:32 AM
To: 'Klaus Hartke' <[email-masked]>
Cc: 'core' <[email-masked]>; [email-masked]
Subject: Re: [core] draft-hartke-t2trg-coral-reef

-----Original Message-----
From: Klaus Hartke <[email-masked]>
Sent: Tuesday, July 16, 2019 10:49 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; core <[email-masked]>
Subject: Re: [core] draft-hartke-t2trg-coral-reef

Hi Jim!

Jim

Klaus

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