You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During WoT Week, @mkovatsc brought up that the CoAP Binding Template currently does not provide a way to specify that requests sent to a Thing should be non-confirmable, e.g., because it is a sleepy device (see w3c/wot-thing-description#2059) that is only available within a certain time frame. This could be covered by a new boolean term (e.g., cov:confirmable), where the absence of the term would imply that the consumer is free to choose the kind of request it wants to send.
Related to that, it might be useful to be able to specify the pattern consumers should use when trying to reach the device in question, e.g., whether they should rather retry sending a non-confirmable request with a certain interval. This could be useful to have if the consumer is not able to determine the exact point in time when the Thing will be reachable again. Not only because I am not entirely sure how to model this vocabulary term exactly, this will probably require some discussion, though.
The text was updated successfully, but these errors were encountered:
While I think we have a use-case for CoAP, I am pretty sure other devices/protocols (that are designed to last for a long time, like LoRaWAN) would benefit from a similar term.
Hence, it makes me think whether we could introduce a more generic term to describe this aspect...
During WoT Week, @mkovatsc brought up that the CoAP Binding Template currently does not provide a way to specify that requests sent to a Thing should be non-confirmable, e.g., because it is a sleepy device (see w3c/wot-thing-description#2059) that is only available within a certain time frame. This could be covered by a new boolean term (e.g.,
cov:confirmable
), where the absence of the term would imply that the consumer is free to choose the kind of request it wants to send.Related to that, it might be useful to be able to specify the pattern consumers should use when trying to reach the device in question, e.g., whether they should rather retry sending a non-confirmable request with a certain interval. This could be useful to have if the consumer is not able to determine the exact point in time when the Thing will be reachable again. Not only because I am not entirely sure how to model this vocabulary term exactly, this will probably require some discussion, though.
The text was updated successfully, but these errors were encountered: