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
>>    (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


You receive all messages sent to this group.

View/Reply Online (#9588): 
View All Messages In Topic (5): 
Mute This Topic: https://lists.iotivity.org/mt/19267974/21656
New Topic: https://lists.iotivity.org/g/iotivity-dev/post

Change Your Subscription: 
Group Home: https://lists.iotivity.org/g/iotivity-dev
Contact Group Owner: iotivity-dev+ow...@lists.iotivity.org
Terms of Service: https://lists.iotivity.org/static/tos
Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub

Reply via email to