Comments below. On Thu, May 17, 2018, 4:54 PM Mats Wichmann <m...@wichmann.us> wrote:
> On 05/17/2018 03:14 PM, Gregg Reynolds wrote: > > On Thu, May 17, 2018, 8:23 AM Mats Wichmann <m...@wichmann.us> wrote: > > > >> On 05/17/2018 12:03 AM, Max wrote: > >>> Hi, > >>> > >>> I wonder what should happen in the following scenario: > >>> > >>> > >>> - A client registered an observer for a server resource. > >>> - That server resource is gracefully terminated by the server, for > >>> example using OcPlatform.unregisterResource() of Java API. > >>> > >>> Questions: > >>> > >>> - Does the spec require the server to notify the "observing" client? > >> > >> It's a little fuzzy, unfortunately. The OCF spec leaves the conditions > >> that generate a notification entirely to the server, so a strict reading > >> says it could choose not to bother in this case and it would still be > >> correct operation. I'm not entirely happy about that (I worked a bit on > >> this part of the spec, back in the day): Observe RFC, on which the OCF > >> work is largely based, > >> is not definitive that a notification must be sent - notice the word > >> SHOULD: > >> > >> (RFC 7641, section 4.2): > >> However, in the event that the state of a resource changes in > >> a way that would cause a normal GET request at that time to return a > >> non-2.xx response (for example, when the resource is deleted), the > >> server SHOULD notify the client by sending a notification with an > >> appropriate response code (such as 4.04 Not Found) and subsequently > >> MUST remove the associated entry from the list of observers of the > >> resource. > >> > > > > Makes perfect sense to me. It's one thing to "observe" temperature; it's > a > > whole 'nother thing to observe the temperature instrument. > > > > If you observe the temperature, and the instrument goes down, you don't > get > > any more notifications. > > > > "...the underlying intent was that > > each notification would be sent as if a resource retrieve had been sent > > just that moment..." > > > > That does not make sense to me. You send a notification when resource > state > > changes. If the temp resource goes down, that is not a change of temp > > state. So ".. as if.. " only makes sense when the resource is up. > > well, we can swing back to that discussion of "what is a resource" - if > it's conceptually fairly close to what you think about as Things in IoT, > then create and delete resources aren't that obviously useful, but if > they're more abstract, they could be. The C++ (and thus Java) APIs do > let you do things in that area so we have to think about it. But putting > that aside... > > all I was saying was, if you asked to GET on a resource that doesn't > exist, then you'd expect to get back a "resource not found". so > therefore *if* a server chooses to notify you that a resource went away, > the way to do that in the observe scenario is send a message that says > "not found" - just as if someone had just asked, rather than having > asked seconds, minutes or hours ago to observe the resource, when it did > exist. Ok, that makes sense, except for the "not found" bit. 3 scenarios: 1. The resource was unregistered. The application code never even gets a chance, the stack just says not found, or something. The sensor instrument might still be there, but iotivity doesn't know about it. 2. The resource remains registered, but was disabled. "Not found" would be incorrect: the resource is still there, it's just disabled. The application code must deal with this; there is no "found but disabled" response code AFAIK. This is problematic since it is not standardized. A client expecting a temperature reading must be prepared to handle a non-standard "disabled" message. 3. Somebody unplugged the resource without bothering to tell iotivity. Maybe for maintenance, maybe to swap in an upgraded instrument. It remains registered and enabled, but the server errors when it tries to read it in response to a GET. I don't think the 500 codes handle this. It's not really an iotivity server error. Again "not found"seems wrong. We can find the iotivity "resource", we just can't access the underlying physical instrument. "Found but broken" seems more appropriate. Or maybe, in so many words, "OCF resource found and enabled, but backing instrument offline"? Should OCF define an "enabled" boolean flag for resources, to handle scenario 2? For scenario 3, maybe an "online/offline" flag? g
