Hi Zoltan,
I also proposed the solution for device entry and exist by sending /oic/res with only /oic/d and /oic/p at least once as soon it joins the network. And on exit it shall send same response with MAX-AGE=0. This proposal is under review and shall resolve the requirement of entry and exit as well. Regards Dwarka ---------------------------------------------------------------------------------- Software R&D Center | Convergence Team | IoT Lab Open Connectivity Foundation ? OSWG ? Spec Coordination TG Chair Iotivity Steering Group ? Advisory Committee From: architecture_tg at openconnectivity.org [mailto:[email protected]] On Behalf Of Kis, Zoltan Sent: Wednesday, November 30, 2016 6:45 PM To: Dwarkaprasad Dayama; iotivity-dev Cc: Mitch Kettrick; coretech_wg at openconnectivity.org; architecture_tg at openconnectivity.org Subject: [architecture_tg] Re: [coretech_wg] Fwd: presence? Hello, Thank you for the responses so far. On Wed, Nov 30, 2016 at 6:49 AM, Dwarkaprasad Dayama <dwarka.dayama at samsung.com <mailto:dwarka.dayama at samsung.com> > wrote: This requirement has been handled in form of observable /oic/res and it is part of OCF 1.0. /oic/ad was removed from Spec because it was underspecified and there was better way to do same using /oic/res and avoiding new resource creation. Thank you, that clarifies. Observing /oic/res will give client apps notifications when resources appear and disappear. Also, the CoAP way Mats mentioned solves this case: if the observing client stack gets a retrieve response with a 4.04 error, the client app will know it has to re-discover. However, I like more the solution with observing /oic/res, since clients don't need to rediscover. I also fully agree with Thiago Macieira that a resource directory should be mandatory in an OCF network. However, none of these solve the problem when the device is gone and there is no one to run /oic/res (or resource directory). For solving that on protocol level, we'd need a network entity that monitors devices in a network and provides notifications to observers when devices disappear and re-appear. That would make this entity (and resource directory) mandatory in the network, with backups, sync and failover mechanisms needed. Alternatively, device implementations could keep /oic/res observers in a persistent state that survives device reboots, so that the device could resume sending /oic/res related notifications after rebooting. The goal is that clients don't need to re-discover. This is an implementation detail, but the Spec should formulate a wording for the recommended way to handle the use case. We really want to avoid client apps solving this problem by polling. Also, we want to keep servers efficient: any observe subscription should expire after a timeout, or when the server max capacity is reached. There should be an error code with retrieve responses for that ("this was the last update, please renew subscription"). This would help keeping servers clean from disappearing clients. Best regards, Zoltan From: coretech_wg at openconnectivity.org <mailto:coretech_wg at openconnectivity.org> [mailto:coretech_wg at openconnectivity.org <mailto:[email protected]> ] On Behalf Of Mitch Kettrick Sent: Wednesday, November 30, 2016 1:37 AM To: 'Kis, Zoltan'; coretech_wg at openconnectivity.org <mailto:coretech_wg at openconnectivity.org> ; architecture_tg at openconnectivity.org <mailto:architecture_tg at openconnectivity.org> Subject: RE: [coretech_wg] Fwd: presence? Hi Zoltan, Several Resources were removed from the core spec because a) they weren?t included in IoTivity and b) we didn?t have any test cases written to validate them. If this feature and the ?rt? oic.wk.ad <http://oic.wk.ad> are in fact supported in IoTivity then we need to add them back into the core spec and write test cases that will validate proper behavior. Would you be able to write a submission/CR to add this functionality back to the core spec to align with what is implemented in IoTivity? I can work with you to develop corresponding test coverage to validate it. Thanks, Mitch From: coretech_wg at openconnectivity.org <mailto:coretech_wg at openconnectivity.org> [mailto:[email protected]] On Behalf Of Kis, Zoltan Sent: Tuesday, November 29, 2016 3:46 AM To: coretech_wg at openconnectivity.org <mailto:coretech_wg at openconnectivity.org> Subject: [coretech_wg] Fwd: presence? Hello, It seems the OCF Core spec 1.1 does not deal with presence any more: the "oic.wk.ad <http://oic.wk.ad> " resource type and the "/oic/ad" resource are not specified any more - or then it's just me who doesn't find them. iotivity still seems to support "enablePresence()" and "disablePresence()" that are based on the "/oic/ad" resource. That sounds obsolete now. I wonder what are the current mechanisms in OCF that support the following use cases: - when a server deletes/unregisters a resource, observers of that resource SHOULD get delete notifications - [sub-case] when a client deletes a remote resource, observers of that resource SHOULD get delete notifications - when a server device goes down, observers for that should get notification instead of trying to fetch resources of that device in vain. Without these, client applications need to do periodic discovery and maintain their own lists of resources and devices. This is catastrophic for network and battery efficiency when we scale it up to the projected number of IoT devices. A resource/device directory should be able to encapsulate this - is a resource directory guaranteed to be in the OCF network nowadays? I wonder what are the recommended client work flows the current OCF Core spec is supporting. Right now it seems that a client first needs to look for a resource directory; if there is one, use it. Otherwise set up periodic discovery and maintain own resource/device list. Thanks, Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161130/c2175a9a/attachment.html>
