In our case it's more about letting the server decide what it wants to name the resources, rather than the client knowing them all in advance. We could list them in .well-known/core but that means maintaining observations on a collection of URLs, on a device for which retaining state on even one observation is a challenge.
Benjamin Damm
Platform Architect
O: 669-770-4000
E: ***@ssni.com www.ssni.com
________________________________________
From: Carsten Bormann <***@tzi.org>
Sent: Wednesday, June 7, 2017 11:07 PM
To: Benjamin Damm
Cc: ***@ietf.org
Subject: Re: [core] Indicating Location in Observe responses
Hi Benjamin,
I think this is a special case of a more general idea to allow a server to send a patch payload with an observe notification.
Obviously, your special case would have the advantage of being idempotent (at least to itself; see below).
I believe that the right way to approach those partial updates is to think about their payloads as specific media types (typically carrying other media types inside them). It probably would make sense to to define a CBOR-based media type for subtrees or combinations of subtrees, also for FETCH observes.
However, one problem that we need to address is what you do when one notification overtakes another.
If I get a notification after a GET /a with Observe serial 5, and then one with 4, I know I can discard the latter.
Now what exactly would it mean if I get a notification for /a/b/c with serial 5, and then one for /a/b with serial 4?
I do believe these problems can be solved, but it probably requires some more thinking.
Grüße, Carsten
> On Jun 8, 2017, at 01:14, Benjamin Damm <***@ssni.com> wrote:
>
> Core,
>
> We wish to assert a CoAP Observe on a resource on a server, and have the server return observations not only for the specific resource but for any sub-path of that resource.
>
> So if the observe is on /a the observe response might be for /a/x or /a/z.
>
> Is there any agreed semantic for how to express the resulting Location or Path? Both URI-Path and Location-Path seem unavailable for this purpose due to the RFC's specification of how these are to be used.
>
> Thanks,
> -Ben
> _______________________________________________
> core mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>