[core] sleepy to sleepy communication I-Ds

[Thomas Fossati <[e-mail]>]

Hello all,

today we have submitted a couple of I-Ds proposing three new CoAP Options that try dealing with the requirement REQ3 of draft-shelby-core-coap-req-04

    The ability to deal with sleeping nodes.  Devices may be
    powered off at any point in time but periodically "wake up"
    for brief periods of time.

leveraging on different techniques, i.e. store-and-forward, explicit origin delegation, REST interface to carbon-copy an observed resource.


Their URIs and respective abstracts are given in the following for convenience:

(1) "Sleepy Option for CoAP" (see http://tools.ietf.org/html/draft-giacomin-core-sleepy-option-00)

This draft defines a new CoAP elective option, Sleepy, targeted specifically at proxies and used to signal a proxy the will to initiate an asynchronous request/response exchange.  The Sleepy option is partitioned in 2/3 subfields indicating: the remaining time before sleep, the expected sleep interval, and (optionally) the on-duty interval.


(2) "Publish and Monitor Options for CoAP" (see http://tools.ietf.org/html/draft-fossati-core-publish-monitor-options-00)

This draft defines two additional Options for the Constrained Application Protocol (CoAP) especially targeted at sleepy sensors: Publish and Monitor.

The Publish Option enables opportunistic updates of a given resource state, by temporarily delegating the authority of the Publish'ed resource to a Proxy node.  The whole process is driven by the (sleepy) origin -- which may actually never need to listen.

The Monitor Option complements the typical Observe pattern, enabling the tracking of a resource hosted by a node sleeping most of the time, by taking care of establishing and maintaining an Observe relationship with the (sleepy) origin on behalf of the (sleepy) client.


We look forward for receiving comments and suggestions to the proposed solutions.