[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

core                                                             Shi. Li
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                              J. Hoebeke
Expires: December 26, 2013                             F. Van den Abeele
                                                       iMinds-IBCN/UGent
                                                                 A. Jara
                                                    University of Murcia
                                                           June 24, 2013


                      Conditional observe in CoAP
                  draft-li-core-conditional-observe-04

Abstract

   CoAP is a RESTful application protocol for constrained nodes and
   networks.  Through the Observe option, clients can observe changes in
   the state of resources and obtain a current representation of the
   last resource state.  This document defines a new mechanism in CoAP
   Observe so that a CoAP client can conditionally observe a resource on
   a CoAP server, only being informed about state changes meeting a
   specific condition or set of conditions.  This offers possibilities
   to extend network intelligence, enhance scalability, and optimize the
   lifetime and performance in order to address the requirements from
   the Constrained Nodes and Networks.

Note

   Discussion and suggestions for improvement are requested, and should
   be sent to core@ietf.org.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 26, 2013.




Li, et al.              Expires December 26, 2013               [Page 1]

Internet-Draft         Conditional observe in CoAP             June 2013


Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Justification . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Comparison to RESTful method  . . . . . . . . . . . . . .   5
   3.  The Condition Option  . . . . . . . . . . . . . . . . . . . .   5
   4.  Condition Types . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Using the Condition Option  . . . . . . . . . . . . . . . . .  11
   6.  Cancellation, updating and existence of conditional
       relationships . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  Cancellation and updating . . . . . . . . . . . . . . . .  12
     6.2.  Existence . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
     10.1.  Condition option registry  . . . . . . . . . . . . . . .  22
     10.2.  Condition type registry  . . . . . . . . . . . . . . . .  23
   11. Further considerations  . . . . . . . . . . . . . . . . . . .  23
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24
   13. Normative References  . . . . . . . . . . . . . . . . . . . .  24
   Appendix A.  OMA Information Reporting with CoAP Conditional
                Observe  . . . . . . . . . . . . . . . . . . . . . .  24
   Appendix B.  Alternative approaches . . . . . . . . . . . . . . .  27
     B.1.  Annex: Cancellation flag  . . . . . . . . . . . . . . . .  27
     B.2.  Annex: Logic flag . . . . . . . . . . . . . . . . . . . .  28
   Appendix C.  Change log . . . . . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction




Li, et al.              Expires December 26, 2013               [Page 2]

Internet-Draft         Conditional observe in CoAP             June 2013


   CoAP [I-D.ietf-core-coap] is an Application Protocol for Constrained
   Nodes/Networks.  The observe [I-D.ietf-core-observe] specification
   describes a protocol design so that a CoAP client and server can use
   the subject/observer design pattern to establish an observation
   relationship.  When observe is used, the CoAP client will get a
   notification response whenever the state of the observed resource
   changed.  However, in some scenarios, the CoAP client may only be
   interested in a subset of state changes of the resource, other state
   changes might be meaningless.  This inability to suppress additional
   notifications results in superfluous traffic.  This memo defines a
   new CoAP option "Condition" that can be used to allow the CoAP client
   to condition the observe relationship, and only when such condition
   is met, the CoAP server shall send the notification response with the
   latest state change.  When such a condition fails, the CoAP server
   does not need to send the notification response.

1.1.  Justification

   A GET request that includes an Observe Option creates an observation
   relationship.  When a server receives such a request, it first
   services the request like a GET request without this option and, if
   the resulting response indicates success, establishes an observation
   relationship between the client and the target resource.  The client
   is notified of resource state changes by additional responses sent in
   reply to the GET request to the client.

   CoAP is used for Constrained Networks, especially used for
   transporting sensor data.  Different sensor equipments have different
   properties, e.g. different change rates, data unit, different
   response time, etc. resulting in varying clients' interests that
   differ from mere state changes.  As such, when a client wants to
   collect information from a sensor, it does not want to receive
   useless information.  In addition, this would cause the transmission
   of irrelevant information in an already constrained network.

   Consider the following example.

      CLIENT                                                     SERVER
        |                                                          |
        | GET/temperature observe:0                     ------>    |
        |                                                          |
        | <------   2.05 Content observe:5 Payload:22              |
        |                                                          |
        |                                                          |
        |                                                          |
        | <------    2.05 Content observe:10 Payload:22.3          |
        |                                                          |
        |                                                          |



Li, et al.              Expires December 26, 2013               [Page 3]

Internet-Draft         Conditional observe in CoAP             June 2013


        |                                                          |
        | <------    2.05 Content observe:15 Payload:22.6          |
        |                                                          |

                         Figure 1: GET request with observe


   In this example, the sensor acts as a server, and it collects the
   resource data every 5 seconds.  When the client observes a resource
   on the server, it will receive a response whenever the server updates
   the resource, that is to say, mostly every 5 seconds the client will
   receive a notification response.  However, the client might be a
   quite simple equipment not too sensitive to the resource state
   change, so it may not want to receive notifications that often.  One
   possible solution could be to alter the sensor's configuration, e.g.
   to shorten the collecting frequency.  However, the sensor should be
   able to provide services to many other clients, making it hard to
   find the best configuration that fits all clients' requirements.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Motivation

   The CoAP Observe Option gives clients the ability to observe changes
   in the state of resources.  A notification relationship is
   established and whenever the state of the resource changes, the new
   representation is pushed to the observer.  In many cases, an observer
   will typically be interested in state changes that satisfy a specific
   condition.  In addition, similar conditional observations will prove
   useful for many different resources.  For example, being informed
   when the state of a resource exceeds a specific value.

   Defining an agreed set of commonly used conditional observations has
   a number of advantages.  In a well-defined way, clients can observe
   different resources conditionally.  At the same time, these resources
   can clearly announce how they can be observed, facilitating machine
   processing of this information.  Also, intermediaries can process
   multiple conditional observations, having as goal to alleviate the
   load on the constrained network and devices.  In the absence of such
   a set of commonly used conditional observations, where every
   application developer can specify its own mechanisms, these
   advantages are lost.





Li, et al.              Expires December 26, 2013               [Page 4]

Internet-Draft         Conditional observe in CoAP             June 2013


2.1.  Comparison to RESTful method

   In [I-D.shelby-core-interfaces] a simple RESTful mechanism is
   described to provide additional conditions to the Observe Option
   through the use of URI query parameters.  It proves that conditional
   observations are useful but begs the question how the two approaches
   stack up to each other.  The authors think that both approaches come
   with their advantages and disadvantages.  Here we try to give an
   overview for both approaches.  This short list of arguments for and
   against both approaches isn't meant to be exhaustive.  We as authors
   of this draft are aware that we are - by definition - biased and we
   welcome any feedback via our contact details and/or via the CoRE
   mailing list.

   When using the RESTful approach care should be given to avoid overlap
   with URI query parameters that a resource might want to use itself.
   Therefore a clear RESTful interface should define how all the
   possible condition type are mapped to said interface.  Specifying
   conditions via URI query parameters also requires a separate request
   for the conditions because - by default - all URI query parameters in
   a request are part of the Cache-Key. Furthermore, it makes
   identifying conditions harder when compared to a dedicated CoAP
   condition option.  The current approach also doesn't allow multiple
   clients observing the same resource with different conditions.
   Including this into the RESTful approach, while keeping caching in
   mind, has yet to be considered.  Another unspecified matter is
   signalling which condition types are supported by a resource.

   The main advantage of the approach proposed in the interfaces draft
   is that due to its RESTful design it doesn't rely on Application
   protocol specific mechanisms (like CoAP options).  This means that
   the interface can easily be supported by any other (application)
   protocol that supports the RESTful paradigm.  It also means that
   servers and clients can limit their implementation of CoAP to the
   basic building blocks of the protocol and use those to add additional
   logic (in the form of RESTful interfaces) as opposed to supporting
   yet another option.  Another - albeit a purist - argument is that
   CoAP options should limit themselves to controlling the CoAP protocol
   and should not influence the representations offered by a resource,
   as these should be defined within the REST interactions themselves.

3.  The Condition Option

           +------+-----+-----------+-----------+--------+---------------+
           | Type | C/E | Name      | Data type | Length | Default       |
           +------+-----+-----------+-----------+--------+---------------+
           |  18  |  E  | Condition | uint      | 1-5 B  | (none)        |
           +------+-----+-----------+-----------+--------+---------------+



Li, et al.              Expires December 26, 2013               [Page 5]

Internet-Draft         Conditional observe in CoAP             June 2013


                         Table 1: Condition Option number



   The Condition Option has the option number 18.  The last bit
   indicates it is an elective option and the second to last bit
   indicates that this is a Proxy Unsafe option (similar to the Observe
   Option).  The delta between the Condition Option and the Observe
   Option is 12.

   The Condition Option can be present in both request and response
   messages.  In both cases, it must be used together with the Observe
   Option, since it extends the meaning of the Observe Option.

   In a GET request message, the Condition Option represents the
   condition the client wants to apply to the observation relationship.
   It is used to describe the resource states the client is interested
   in.

   In the response to the initial GET request message, the Condition
   Option, together with the Observe Option, indicates that the client
   has been added to the list of observers and that notifications will
   be sent only when the resource state meets the condition specified in
   the Condition Option.  In all further notifications, the Condition
   Option identifies the condition to which the notification applies.

   Basically, a similar procedure as described in the observe draft
   [I-D.ietf-core-observe] is followed, but extended with additional
   behaviour by taking the Condition Option into account.  The exact
   semantics are defined in the sections below.

   The size of the Condition Option value is not fixed and can range
   from 1 to 5 bytes.  The value carried is in a specific format that
   consist of two parts: a mandatory condition header and an optional
   condition value.  The condition header has a fixed length of 1 byte
   and the condition value, when present, can range from 1 to 4 bytes.
   The condition header consists of 3 fields: the condition type (TYPE),
   reliability flag (R) and value type (V).

   The Condition Option may occur more than once.  If multiple Condition
   Options are present in a request, their relationship is "AND",
   meaning that the server will only send a notification when both
   conditions are fulfilled.  In the notifications to such a request,
   the same Condition Options are present.  The Figure 10 presents an
   example of a multiple condition with "AND" conjunction.

   Note that in order to establish an "OR" relationship between
   conditions, a client simply needs to send separate requests using



Li, et al.              Expires December 26, 2013               [Page 6]

Internet-Draft         Conditional observe in CoAP             June 2013


   different source endpoints.  The Figure 11 presents an example of OR
   condition with multiple requests, which are sent in two messages via
   different source transport ports.

   Since this solution could be considered as non-optimal, an
   alternative solution is proposed for discussion in the Annex "Logic
   flag", where multiple OR relationships with multiple conditional
   options can be defined, similar as has been presented for the "AND"
   conjunction.

   In case of multiple Condition options, the main reason for choosing
   "AND" semantics over "OR" semantics is motivated by the fact that in
   case of the "OR" semantics the notification must be send anyway (as
   opposed to the "AND" case).  This choice minimizes the amount of
   useless notifications that are sent over the network.  The authors
   foresee that for some constrained devices supporting more than 1
   condition per relationship might not be possible, in that case the
   client should try to establish the required behaviour using a minimal
   number of 1-condition relationships and filtering out unwanted
   notifications at the client-side.


               0
              0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+
             | TYPE    |R| V |
             +-+-+-+-+-+-+-+-+

               0               1
              0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE    |R| V |      VAL      |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               0               1               2
              0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 . . 7
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE    |R| V |          VAL          |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               0               1               2       3
              0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 . . 7 0 . . 7
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE    |R| V |                   VAL         |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               0               1               2       3       4
              0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 . . 7 0 . . 7 0 . . 7



Li, et al.              Expires December 26, 2013               [Page 7]

Internet-Draft         Conditional observe in CoAP             June 2013


             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE    |R| V |                          VAL          |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Condition Option value


   TYPE: The condition type is a 5 bit integer indicating the type of
   the condition in the observe request or in a notification.  Every
   value of TYPE represents the type ID of a specific condition type.
   Every condition type can be complemented by a condition value in the
   VAL field, further specifying the condition in more detail.  Below is
   the definition of identified condition types.

   R: In an observe request, the reliability flag indicates whether
   notifications for that condition need to be send non-confirmable (0)
   or confirmable (1).  In the initial response, this flag indicates the
   server's willingness or ability to send the notifications confirmable
   or non-confirmable, as requested by the client.  In all further
   notifications, this flag can be changed depending on the server's
   decision.  In case of a request containing multiple Condition
   Options, the client must use the same value of the R flag in all
   Condition Options.  If the server receives a request with multiple
   Condition Options, which do not all share the same value of the R
   flag, the server MUST respond with a 4.00 "Bad Request" response
   code.  Note that the observe draft states that the message type of a
   notification is independent from the type used for the request or any
   previous notification.  The R flag doesn't violate this behaviour and
   a client should expect that a CON notification might arrive without
   this being explicitly signalled by the server (as a NON-notification
   signalling this, might not arrive).

   V: The value type is a 2 bit field in a request or response that
   gives the data type of the condition value, when present in the
   Condition Option.  If no condition value is present, this field has
   no meaning and must be 0.  Table 2 gives an overview of all available
   value types.  The Duration data type is defined in Appendix C.2 of
   [I-D.bormann-coap-misc].  The representation of floating point
   numbers in a common format that is understandable by constrained
   devices is outside the scope of this document.

             +-----------------------+------+
             | Value type (2 bit)    | Id.  |
             +-----------------------+------+
             | Integer               |  0   |
             +-----------------------+------+
             | Duration (s)          |  1   |
             +-----------------------+------+



Li, et al.              Expires December 26, 2013               [Page 8]

Internet-Draft         Conditional observe in CoAP             June 2013


             | Float                 |  2   |
             +-----------------------+------+

                   Table 2: Value types


   VAL: The condition value is 1 to 4 byte value of the type indicated
   by the V flag.  The condition value is used to indicate the value
   that further specifies the condition type (e.g. a threshold).
   Condition types can require the presence of a condition value.  When
   a condition value is present in an observe request, the same value
   must be used in the initial response.  In all further notifications,
   the condition value can be left out to reduce the size of the option.

4.  Condition Types

   Table 3 gives an overview of all currently identified condition
   types.  If supported by the server, different condition types can be
   combined in a request to express a logical AND relationship.  By
   default, logical OR of condition types is always supported through
   sending separate requests using different source endpoints.

             +-----------------------+------+-----------------+
             | Condition type (5 bit)| Id.  | Condition Value |
             +-----------------------+------+-----------------+
             | Cancellation          |  0   |       no        |
             +-----------------------+------+-----------------+
             | Time series           |  1   |       no        |
             +-----------------------+------+-----------------+
             | Minimum response time |  2   |       yes       |
             +-----------------------+------+-----------------+
             | Maximum response time |  3   |       yes       |
             +-----------------------+------+-----------------+
             | Step                  |  4   |       yes       |
             +-----------------------+------+-----------------+
             | AllValues<            |  5   |       yes       |
             +-----------------------+------+-----------------+
             | AllValues>            |  6   |       yes       |
             +-----------------------+------+-----------------+
             | Value=                |  7   |       yes       |
             +-----------------------+------+-----------------+
             | Value<>               |  8   |       yes       |
             +-----------------------+------+-----------------+
             | Periodic              |  9   |       yes       |
             +-----------------------+------+-----------------+

                        Table 3: Condition types




Li, et al.              Expires December 26, 2013               [Page 9]

Internet-Draft         Conditional observe in CoAP             June 2013


   Time series: This condition indicates that a client wants to receive
   all state changes of a resource, but that it does not want to receive
   a notification in case the time since the last notification was sent
   became greater than the max-age of the resource and the resource did
   not change during this period.  --> This is a variant of the observe
   draft [I-D.ietf-core-observe] that deals with eventual consistency,
   which may result in notifications even if the resource did not change
   in order to ensure the observer has a fresh representation of the
   resource.  Note that the observe draft states that if the age of the
   latest notification becomes greater than its indicated Max-Age, then
   the client MUST NOT use the enclosed representation until it is
   validated or a new notification is received.  In case of the Time
   series condition a client might opt to divert from this behaviour and
   use these older notifications anyway.  The client signals this to the
   server by choosing a Time series condition value larger than the Max-
   Age of the resource and including this option in its observe request.
   In case the server thinks this behaviour isn't feasible, it signals
   this to the client by removing the time series Condition option from
   its response.  In case the server's response does echo the Time
   series condition, then the client is allowed to divert from the
   behaviour specified in the observe draft and use these 'older'
   notifications.  Similar considerations hold true for the other timing
   condition types that are defined in this draft.

   Minimum response time: For this condition, the value specified in the
   condition value field gives the minimum time in seconds the server
   should leave between subsequent notifications.

   Maximum response time: For this condition, the value specified in the
   condition value field gives the maximum time in seconds the server is
   allowed to leave between subsequent notifications.

   Step: For this condition, the value specified in the condition value
   field gives the minimum state change of a resource (since the last
   notification) before the server should send a new notification.

   AllValues<: This condition indicates that a client is only interested
   in receiving notifications whenever the state of the resource changes
   and the value is less than the value specified in the condition value
   field.

   AllValues>: This condition indicates that a client is only interested
   in receiving notifications whenever the state of the resource changes
   and the value is greater than the value specified in the condition
   value field.

   Value=: This condition indicates that a client is only interested in
   receiving notifications whenever the state of the resource changes



Li, et al.              Expires December 26, 2013              [Page 10]

Internet-Draft         Conditional observe in CoAP             June 2013


   and the value is equal to the value specified in the condition value
   field.

   Value<>: This condition indicates that a client is only interested in
   receiving a single notification whenever the state becomes higher or
   lower than the value specified in the condition value field.  Once
   the notification has been sent, no new notifications are sent for
   subsequent state changes where the value remains higher or lower.  As
   such, a single notifications is sent whenever a threshold is passed
   in either direction.

   Periodic: This condition indicates the periodic interval in seconds
   with which new notifications should be sent.

5.  Using the Condition Option

   Whenever a client wants to initiate a Conditional Observation
   relationship, it sends a GET request with both an Observe and at
   least one Condition Option.  The Condition Option extends the meaning
   of the Observe Option by including a condition that describes the
   resource states the client is interested in.  It represents the
   condition the client wants to apply to the observation relationship.

   When a server receives such a request, it first services the request
   the same way as described in [I-D.ietf-core-observe].  Next, if the
   server supports the Condition Option, it analyses the Condition
   Option to find the condition requested by the client.  If the
   condition is supported, the relationship is stored and the client is
   informed about the successful establishment of the conditional
   relationship.  This is done by sending a response containing both the
   Observe and Condition Option, which implies that the client has now
   been added to the list of observers and will only be informed about
   state changes or resource states satisfying the condition described
   in the Condition Option.

   Since the Condition Option is elective, an observe request that
   includes the Condition Option will automatically fall back to a basic
   observe request if the server does not support the Condition Option.
   There is no default value for the Condition Option.  Also, if the
   Condition Option is supported, but the requested condition is not
   supported by the resource, the request will also fall back to a basic
   observe request, resulting in a response only containing the Observe
   Option.  This implies that the client will now receive notifications
   as described in [I-D.ietf-core-observe] and that the client itself is
   responsible for processing the resource state in the notifications in
   order to identify whether the condition of interest is fulfilled.





Li, et al.              Expires December 26, 2013              [Page 11]

Internet-Draft         Conditional observe in CoAP             June 2013


   Whenever the state of a resource that supports conditional
   observations changes on the server, the server needs to check the
   established conditional relationships.  Whenever the relationship
   condition(s) is(are) met, the server sends the notification response
   to the client that has established the relationship.  In case the
   server is still waiting for a confirmable notification to be
   acknowledged or the 3 seconds on average for a non-confirmable
   notification to elapse, it MUST adhere to the behaviour specified in
   section 4.5 of [I-D.ietf-core-observe].  The response contains both
   the Observe Option and the Condition Option, where the latter option
   describes the condition that has been fulfilled.  If not met, the
   server does not send any response to the client.  Furthermore, the
   server also doesn't send a response when the last notification is
   older than Max-Age.

   A client is allowed to use multiple Condition Options in an observe
   request in order to express a logical AND relationship between
   different condition types.  When a server receives such a request and
   it does not support composed conditions, the request will also fall
   back to a basic observe request, resulting in a response only
   containing the Observe Option.  If the server supports this, it will
   store the relationship and send back a response echoing the same
   multiple Condition Options.

   In case a client wants to establish multiple different conditional
   relationships with the same server, it needs to use a different
   source endpoint for every conditional relationship.

6.  Cancellation, updating and existence of conditional relationships

6.1.  Cancellation and updating

   In case a client wants to cancel an existing conditional
   relationship, it has to perform a GET request to the target resource
   without Observe and Condition Option using the same source endpoint
   used to establish the conditional relationship (i.e. source endpoint
   of the original request).  Upon reception of such a GET request, the
   server will remove the client from the list of conditional observers
   for that resource.

   Alternatively, the client can also send a confirmable request
   containing a Condition Option with condition type _Cancellation_.
   The source endpoint used by the client together with the request URI
   uniquely identifies the conditional relationship the client has with
   the server.  Upon reception of such a message, the server knows that
   the client wants to terminate the relationship it has established.





Li, et al.              Expires December 26, 2013              [Page 12]

Internet-Draft         Conditional observe in CoAP             June 2013


   This cancellation mechanism implies that whenever a client wants to
   establish multiple different conditional relationships with the same
   resource on the same server, it needs to use a different source
   endpoint for every conditional relationship.

   When a client has established a conditional relationship and it sends
   a new conditional observe request using the same source endpoint to
   the same resource, the existing relationship is removed and the new
   relationship established.  This way, a client is able to update
   existing relationships.

   Apart from the cancellation through sending a GET request without
   Observe and Condition Option, a conditional relationship can also be
   cancelled by sending a RST message in response of a confirmable
   notification.  When a client rejects a non-confirmable notification
   with a RST, the server can remove the client from the list of
   observers interested in the specific condition of the resource in
   case the server maintains state information about non-confirmable
   notifications.

   Additionally, if the server is for whatever reason not able to
   further fulfill the conditional relationship of a client, the server
   can also send a confirmable notification containing a Condition
   Option with condition type 'Cancellation' (echoing the Token in the
   notification).  The client's endpoint and the request URI uniquely
   identify a conditional relationship with a server.  As such, upon
   reception of such a message, the client can infer the request URI
   from the request associated with the Token contained in the response
   and knows the relationship that has been terminated by the server.

   Finally, when a server sends a confirmable notification that is not
   acknowledged by the observer, the server may terminate the
   relationship after the last unsuccessful delivery attempt of said
   notification.

   Note: The possibilities to establish a Cancellation flag have also
   been evaluated, see Annex "Cancellation flag".  This has been
   discarded since, as it is too complex for processing, when multiple
   conditions are defined.

6.2.  Existence

   The observe draft [I-D.ietf-core-observe] specifies that at a minimum
   a server must send a notification in a confirmable message at least
   every 24 hours.  In case of monitoring critical events this 24-hour
   interval is most likely too short.  Therefore additional, more
   flexible mechanisms for checking the existence of a (conditional)
   relationship are needed.  This paragraph presents two ideas in the



Li, et al.              Expires December 26, 2013              [Page 13]

Internet-Draft         Conditional observe in CoAP             June 2013


   form of CoAP options that augment the default periodic confirmable
   message.

   A client has the possibility to establish and remove conditional
   relationships and a server can also inform a client about the removal
   of a conditional relationship.  Next to this, there is the issue of
   how long the relationship is guaranteed to exist in the absence of
   any explicit removal from either the client or server side (e.g. a
   client that wants to maintain the relationship for a very long time)
   or in the absence of frequent notifications.  To this end, a
   mechanism is needed for a client to know whether it is still on the
   list of observers and for a server to know whether a client is still
   an observer.

   In order for a client to know whether it is still on the list of
   observers after a long period without notifications or without
   confirmable notifications, the server can use the Pledge Option, as
   defined in [I-D.bormann-coap-misc].  By adding this option to its
   notifications, the server indicates how long it minimally promises to
   maintain that specific conditional relationship.  In case no new
   notifications or non-confirmable notifications are sent and the
   duration indicated in the Pledge Option is to expire, the client must
   renew the relationship by resending the same request, preferable as a
   confirmable message.

   In case the duration indicated in the Pledge Option expires at the
   server side and the client did not renew the relationship, the server
   must remove the relationship by sending an explicit cancellation
   message (a confirmable notification to the client's source endpoint
   containing a Condition Option with condition type 'Cancellation'.).
   As such, the use of the Pledge Option extends the establishment and
   removal mechanism with a server-initiated mechanism to realize
   intermediate refreshments of the relationship.

   The second mechanism, for a server to determine whether a client is
   still an observer, is realized by adding a Keep-Alive Option to the
   observe request.  The size of the Keep-Alive Option value is 1 byte
   and represents a duration in seconds, using the Duration data type as
   defined in Appendix C.2 of [I-D.bormann-coap-misc].

           +------+-----+------------+----------------+--------+---------+
           | Type | C/E | Name       | Format         | Length | Default |
           +------+-----+------------+----------------+--------+---------+
           |  30  |  E  | Keep-alive | Duration in s  |  1 B   | (none)  |
           +------+-----+------------+----------------+--------+---------+

                       Table 4: Keep-alive Option number




Li, et al.              Expires December 26, 2013              [Page 14]

Internet-Draft         Conditional observe in CoAP             June 2013


   The Keep-Alive Option has the option number 30, meaning that it is an
   elective, Proxy Safe option, but not a cache key.

   When the client adds the Keep-Alive option to its conditional observe
   request, it requests the server to confirm that the relationship is
   still alive every time the duration expires and no notifications or
   only non-confirmable notifications have been sent during that period.
   If the option is supported by the server, the option is echoed in its
   first response.  Every time the duration expires and no notifications
   or only non-confirmable notifications have been sent, the server
   sends a confirmable notification to the client with an empty payload
   (since the condition is not fulfilled).  As such, the use of the
   Keep-alive Option extends the establishment and removal mechanism
   with a client-initiated mechanism to realize intermediate
   refreshments of the relationship.  Furthermore it allows a client to
   explicitly specify the 24-hour interval mentioned in the observe
   draft.

   The Pledge Option allows a server to request a client to confirm its
   interest and the Keep-Alive option allows a client to request a
   server to confirm whether it is still an observer.  In case neither
   of the two options are supported, the only way for the client to
   ensure the relationship is still existing in the absence of incoming
   notifications is to periodically re-establish the relationship and
   the only way for the server to ensure the client is still interested
   is to send a confirmable notification from time to time.

7.  Discovery

   The Condition Option enables the establishment of well-defined set of
   conditional observations.  It is equally important for a resource to
   be able to announce in a well-defined way which conditional
   observations it supports.  Clients can then discover these
   capabilities and process them automatically.

   In [I-D.ietf-core-observe], the "obs" attribute is introduced as a
   target attribute.  It is used as a flag without any value, indicating
   that the resource is observable.  In order to describe the
   conditional observe capabilities of a resource, a value is added to
   the obs attribute.  To describe which of the 2^5 possible condition
   types a resource supports, a 32-bit value is used where a bit-value
   of 1 at position X (starting from 0 and from right to left) indicates
   that the condition type X is supported.  As such, by a client can
   discover the supported observe capabilities by parsing the value of
   the "obs" attribute.  In case no value is present, the "obs"
   attribute preserves its original meaning.





Li, et al.              Expires December 26, 2013              [Page 15]

Internet-Draft         Conditional observe in CoAP             June 2013


8.  Examples

   This section gives a number of short examples with message flows to
   illustrate the use of Condition Option in a observe GET request.
   Note that, in order to keep the figures readable, the Condition
   Option that is included in every notification is not shown.

   The first example (Figure 3) shows that the client sets the Condition
   Option to Type: 1 - No Value (1/-).  The condition is Time Series,
   meaning that the client wants to receive all state changes.  In case
   the state of the resource does not change, no notifications are sent,
   also not in case max-age expires.  We assume a max-age value of 60
   seconds.

      CLIENT                                                     SERVER
       |                                                          |
       |      GET/temperature,observe:0,Condition:1/- ----->    22|0s
       |                                                          |
       | <------ 2.05Content,observe:0,payload:22                 |
       |                                                          |
       |                                                          |
       | <------ 2.05Content,observe:10,payload:22.4          22.4|10s
       |                                                          |
       | <------ 2.05Content,observe:15,payload:23              23|15s
       |                                                          |
       | <------ 2.05Content,observe:20,payload:23.5          23.5|20s
       |                                                          |
       | <------ 2.05Content,observe:25,payload:24              24|25s
       |                                                          |
       | <------ 2.05Content,observe:30,payload:22              22|30s
       |                                                          |
       |                                                        22|35s
       |                                                          |
       |                                         [max-age exp.] 22|90s
       |                                                          |
       | <------ 2.05Content,observe:120,payload:22.2         22.2|120s
       |                                                          |

           Figure 3: Condition Option with value 1/- (Time Series)


   The following example (Figure 4) shows that the client sets the
   Condition Option to Type: 2 - Value: 10 (2/10), This means that the
   server shall wait at least 10s between sending notification
   responses, indicating changes in the state of the resource, to the
   client.





Li, et al.              Expires December 26, 2013              [Page 16]

Internet-Draft         Conditional observe in CoAP             June 2013


      CLIENT                                                     SERVER
       |                                                          |
       |      GET/temperature,observe:0,Condition:2/10 ----->   22|0s
       |                                                          |
       | <------ 2.05Content,observe:0,payload:22                 |
       |                                                          |
       |                                                          |
       | <------ 2.05Content,observe:10,payload:22.4          22.4|10s
       |                                                          |
       |                                                        23|15s
       |                                                          |
       | <------ 2.05Content,observe:20,payload:23.5          23.5|20s
       |                                                          |
       |                                                        24|25s
       |                                                          |
       | <------ 2.05Content,observe:30,payload:22              22|30s
       |                                                          |
       |                                                        22|35s
       |                                                          |
       |                                                        22|90s
       |                                                          |
       | <------ 2.05Content,observe:120,payload:22.2         22.2|120s
       |                                                          |

       Figure 4: Condition Option with value 2/10 (Minimum Response Time)


   The next example (Figure 5) shows that the client sets the Condition
   Option to Type: 3 - Value: 60 (3/60).  The server will send
   notifications upon every state change, but will leave maximally 60s
   between subsequent notifications, even if they do not incur a state
   change.

      CLIENT                                                     SERVER
       |                                                          |
       |      GET/temperature,observe:0,Condition:3/60 ----->   22|0s
       |                                                          |
       | <------ 2.05Content,observe:0,payload:22                 |
       |                                                          |
       |                                                          |
       | <------ 2.05Content,observe:10,payload:22.4          22.4|10s
       |                                                          |
       | <------ 2.05Content,observe:15,payload:23              23|15s
       |                                                          |
       | <------ 2.05Content,observe:20,payload:23.5          23.5|20s
       |                                                          |
       | <------ 2.05Content,observe:25,payload:24              24|25s
       |                                                          |



Li, et al.              Expires December 26, 2013              [Page 17]

Internet-Draft         Conditional observe in CoAP             June 2013


       | <------ 2.05Content,observe:30,payload:22              22|30s
       |                                                          |
       |                                                        22|35s
       |                                                          |
       | <------ 2.05Content,observe:90,payload:22              22|90s
       |                                                          |
       | <------ 2.05Content,observe:120,payload:22.2         22.2|120s
       |                                                          |

       Figure 5: Condition Option with value 3/60 (Maximum Response Time)


   Figure 6 shows a client setting the Condition Option to Type: 4 -
   Value: 1 (4/1).  The server will now send notifications every time
   the change in state of the resource is at least 1.

      CLIENT                                                     SERVER
       |                                                          |
       |      GET/temperature,observe:0,Condition:4/1 ----->   22|0s
       |                                                          |
       | <------ 2.05Content,observe:0,payload:22                 |
       |                                                          |
       |                                                          |
       |                                                      22.4|10s
       |                                                          |
       | <------ 2.05Content,observe:15,payload:23              23|15s
       |                                                          |
       |                                                      23.5|20s
       |                                                          |
       | <------ 2.05Content,observe:25,payload:24              24|25s
       |                                                          |
       | <------ 2.05Content,observe:30,payload:22              22|30s
       |                                                          |
       |                                                        22|35s
       |                                                          |
       |                                                        22|90s
       |                                                          |
       |                                                      22.2|120s
       |                                                          |

           Figure 6: Condition Option with value 4/1 (Step)


   The example in Figure 7 shows that the client sets the Condition
   Option to Type: 6 - Value: 23 (6/23).  The server will send
   notifications to the client only if the resource value is bigger than
   23.




Li, et al.              Expires December 26, 2013              [Page 18]

Internet-Draft         Conditional observe in CoAP             June 2013


      CLIENT                                                     SERVER
       |                                                          |
       |      GET/temperature,observe:0,Condition:6/23 ----->   22|0s
       |                                                          |
       | <------ 2.05Content,observe:0,payload:22                 |
       |                                                          |
       |                                                          |
       |                                                      22.4|10s
       |                                                          |
       |                                                        23|15s
       |                                                          |
       | <------ 2.05Content,observe:20,payload:23.5          23.5|20s
       |                                                          |
       | <------ 2.05Content,observe:25,payload:24              24|25s
       |                                                          |
       |                                                        22|30s
       |                                                          |
       |                                                        22|35s
       |                                                          |
       |                                                        22|90s
       |                                                          |
       |                                                      22.2|120s
       |                                                          |

           Figure 7: Condition Option with value 6/23 (AllValues>)


   Figure 8 is an example of a client setting the Condition Option to
   Type: 8 - Value: 23 (8/23).  The server will send a single
   notification whenever the state becomes higher or lower than 23.

      CLIENT                                                     SERVER
       |                                                          |
       |      GET/temperature,observe:0,Condition:8/23 ----->   22|0s
       |                                                          |
       | <------ 2.05Content,observe:0,payload:22                 |
       |                                                          |
       |                                                          |
       |                                                      22.4|10s
       |                                                          |
       |                                                        23|15s
       |                                                          |
       | <------ 2.05Content,observe:20,payload:23.5          23.5|20s
       |                                                          |
       |                                                        24|25s
       |                                                          |
       | <------ 2.05Content,observe:30,payload:22              22|30s
       |                                                          |



Li, et al.              Expires December 26, 2013              [Page 19]

Internet-Draft         Conditional observe in CoAP             June 2013


       |                                                        22|35s
       |                                                          |
       |                                                        22|90s
       |                                                          |
       |                                                      22.2|120s
       |                                                          |

           Figure 8: Condition Option with value 8/23 (Values<>)


   Figure 9 is an example of a client setting the Condition Option to
   Type: 9 - Value: 30 (9/30).  The server will send notifications every
   30 seconds, independent whether the resource has changed or not.

      CLIENT                                                     SERVER
       |                                                          |
       |      GET/temperature,observe:0,Condition:9/30 ----->   22|0s
       |                                                          |
       | <------ 2.05Content,observe:0,payload:22                 |
       |                                                          |
       |                                                          |
       |                                                      22.4|10s
       |                                                          |
       |                                                        23|15s
       |                                                          |
       |                                                      23.5|20s
       |                                                          |
       |                                                        24|25s
       |                                                          |
       | <------ 2.05Content,observe:30,payload:22              22|30s
       |                                                          |
       | <------ 2.05Content,observe:60,payload:22              22|60s
       |                                                          |
       | <------ 2.05Content,observe:90,payload:22              22|60s
       |                                                          |
       | <------ 2.05Content,observe:120,payload:22.2         22.2|120s
       |                                                          |

             Figure 9: Condition Option with value 9/30 (Periodic)


   In the following examples, we illustrate the combination of different
   conditions.  The example in Figure 10 shows the client adds two range
   Condition Options in the request, one set to 6/5, another one set to
   5/15.  It means that the range is within 5 and 15, i.e. value > 5 AND
   value < 15.  Since it is an AND condition, the two conditions can be
   specified in the same observe with multiple options.




Li, et al.              Expires December 26, 2013              [Page 20]

Internet-Draft         Conditional observe in CoAP             June 2013


      CLIENT                                                     SERVER
        |                                                          |
        | GET/temperature, observe:0,Condition:6/5,                |
                                     Condition:5/15          ----->|
        |                                                          |
        | <------ 2.05Content,observe:0,payload:4                 4|0s
        |                                                          |
        |                                                         3|5s
        |                                                          |
        |                                                         3|10s
        |                                                          |
        | <------ 2.05Content,observe:15,payload:12              12|15s
        |                                                          |
        |                                                        16|20s
        |                                                          |
        | <------ 2.05Content,observe:25,payload:14              14|25s

        Figure 10: Two Condition Options to define in-side a range option
                  6/5 AND 5/15 (AllValues> AND AllValues<)


   The last example (Figure 11) shows the client adds two Observe
   request messages to build a range, one sets to 6/22, another one sets
   to 5/16.  It means that the range is out of range between 16 and 22,
   i.e. value > 22 OR value < 16.  This requires two messages, since it
   is the OR option, which is defined with multiple observe messages.
   An example of the application for this option can be found in the
   implementation of the conditional observer [SENSORS].























Li, et al.              Expires December 26, 2013              [Page 21]

Internet-Draft         Conditional observe in CoAP             June 2013


      CLIENT                                                     SERVER
        |                                                          |
        | GET/temperature, observe:0,Condition:6/22 (PORT X) --->  |
        | GET/temperature, observe:0,Condition:5/16 (PORT Y) --->  |
        |                                                          |
        |                                                          |
        |                                                          |18
        |                                                          |
        | <------ 2.05Content,observe:10,payload:22,5              |22.5
        |                                                          |
        | <------ 2.05Content,observe:20,payload:23.2              |23.2
        |                                                          |
        |                                                          |19
        |                                                          |
        |  <------ 2.05Content,observe:35,payload:15               |15


       Figure 11: Two Observe requests to define out-side a range
                  6/22 OR 5/15 (Allvalues> OR Allvalues<)


   Further, in [CPSCOM], an evaluation can be found regarding the
   feasibility of implementing conditional observations on real
   constrained devices, together with a basic performance comparison
   between conditional observe (server-filtering) and normal observe in
   combination with client-side filtering.

9.  Security Considerations

   As the Condition Option is used together with the Observe option,
   when it is used it must follow the security considerations as
   described in Observe draft [I-D.ietf-core-observe].

10.  IANA Considerations

10.1.  Condition option registry

   This draft adds the following option numbers to the CoAP Option
   Numbers registry of [I-D.ietf-core-coap]

                   +--------+---------------+----------------+
                   | Number | Name          | Reference      |
                   +--------+---------------+----------------+
                   |  26    | Condition     | [RFCXXXX]      |
                   +--------+---------------+----------------+
                   |  28    | Keep-alive    | [RFCXXXX]      |
                   +--------+---------------+----------------+




Li, et al.              Expires December 26, 2013              [Page 22]

Internet-Draft         Conditional observe in CoAP             June 2013


                        Table 3: Condition and Keep-alive Option number


10.2.  Condition type registry

   The Condition types defined in this draft are identified by a string,
   such as "Step".  In order to minimize the overhead of using these
   condition types, this document defines a registry for the condition
   types to be used in CoAP and assigns each a numeric identifier.

   Each entry in the registry must include the condition type registered
   with IANA, the numeric identifier in the range 0-31 to be used for
   that condition type in CoAP, and a reference to a document defining
   the usage of that condition type.

   Initial entries in this registry are as follows:


             +-----------------------+------+-----------+
             | Condition type        | Id.  | Reference |
             +-----------------------+------+-----------+
             | Cancellation          |  0   | [RFCXXXX] |
             +-----------------------+------+-----------+
             | Time series           |  1   | [RFCXXXX] |
             +-----------------------+------+-----------+
             | Minimum response time |  2   | [RFCXXXX] |
             +-----------------------+------+-----------+
             | Maximum response time |  3   | [RFCXXXX] |
             +-----------------------+------+-----------+
             | Step                  |  4   | [RFCXXXX] |
             +-----------------------+------+-----------+
             | AllValues<            |  5   | [RFCXXXX] |
             +-----------------------+------+-----------+
             | AllValues>            |  6   | [RFCXXXX] |
             +-----------------------+------+-----------+
             | Value=                |  7   | [RFCXXXX] |
             +-----------------------+------+-----------+
             | Threshold             |  8   | [RFCXXXX] |
             +-----------------------+------+-----------+
             | Periodic              |  9   | [RFCXXXX] |
             +-----------------------+------+-----------+

                       Table 5: Condition Option type


11.  Further considerations

   Intermediaries, caching, retransmissions



Li, et al.              Expires December 26, 2013              [Page 23]

Internet-Draft         Conditional observe in CoAP             June 2013


12.  Acknowledgements

   Thanks to the IoT6 European Project (STREP) of the 7th Framework
   Program (Grant 288445).

13.  Normative References

   [CPSCOM]   Ketema, G., Hoebeke, J., Moerman, I., Demeester, P., Li,
              Shi., and A. Jara, "Efficiently observing Internet of
              Things Resources", The 2012 IEEE International Conference
              on Cyber, Physical and Social Computing November 20-23,
              2012, Besancon, France, Novemer 2012.

   [I-D.bormann-coap-misc]
              Bormann, C. and K. Hartke, "Miscellaneous additions to
              CoAP", draft-bormann-coap-misc-13 (work in progress),
              March 2012.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-17
              (work in progress), May 2013.

   [I-D.ietf-core-link-format]
              Shelby, Z., "CoRE Link Format", draft-ietf-core-link-
              format-14 (work in progress), June 2012.

   [I-D.ietf-core-observe]
              Hartke, K., "Observing Resources in CoAP", draft-ietf-
              core-observe-08 (work in progress), February 2013.

   [I-D.shelby-core-interfaces]
              Shelby, Z. and M. Vial, "CoRE Interfaces", draft-shelby-
              core-interfaces-05 (work in progress), March 2013.

   [OMADM]    Alliance, OMA., "Lightweight Machine to Machine Technical
              Specification", OMA-TS-LightweightM2M-V1_0-20130301-D Open
              Mobile Alliance (OMA), March 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SENSORS]  Castro, M., Jara, A., and A. Skarmeta, "Architecture for
              Improving Terrestrial Logistics Based on the Web of
              Things", Sensors 12, no. 5, 6538-6575, 2012, May 2012.

Appendix A.  OMA Information Reporting with CoAP Conditional Observe




Li, et al.              Expires December 26, 2013              [Page 24]

Internet-Draft         Conditional observe in CoAP             June 2013


   The Open Mobile Alliance (OMA) has defined the Lightweight Machine to
   Machine (LWM2M) Technical Specification [OMADM].  This specification
   uses CoAP as the transport for the device management in terms of
   registration, service discovery, bootstrapping, service enablement,
   and information reporting.

   Information reporting presents a similar philosophy that CoAP
   conditional observe.  In details, it is defined for the periodic
   reporting of data, or an event-triggered reporting based on changes
   in some of the resource values.

   Information reporting allows to send an Observe GET request for an
   Object Instance (Objects is the organization of resources in OMA
   LWM2M), which results in asynchronous notifications whenever that
   Object Instance changes (periodically or as a result of an event).
   The minimum and maximum period of notifications can be controlled by
   including the minimum (pmin) and/or maximum (pmax) period for
   notifications to be sent in seconds.

   An example of the logical operation defined by OMA LWM2M is a GET
   with Observe option:

            /{Object ID}/{Object Instance ID}/{Resource ID}
            ?pmin={minimum period}&pmax={maximum period}


   The answer is a 2.05 Content with Observe option, 4.00 Bad Request,
   4.04 Not Found, 4.05 Method Not Allowed, or in case of Asynchronous
   Response 2.04 Changed.

   Note, that the resources are logically organized into Objects.
   Thereby, multiple resources are defined per Object, and each resource
   is given a unique identifier within that Object.  Each Resource is
   defined to have one or more Operations that it supports.  A Resource
   MAY contain multiple instances as defined in Object specification.
   An Object defines a grouping of Resources.  Object MUST be
   instantiated, which is called Object Instance before using the
   functionality of an Object.  After Object Instance is created, that
   Object Instance and Resources which belong to that Object Instance.
   As a result, it is required to reference the Object ID, Object
   Instance ID, and finally Resource ID.

   The operations defined for the information reporting interface are:
   observe, notify, and cancel observation.

   First, the observe interface, following the OMA LWM2M requirements,
   needs to define the Minimum and Maximum period parameters.




Li, et al.              Expires December 26, 2013              [Page 25]

Internet-Draft         Conditional observe in CoAP             June 2013


   Minimum period indicates the minimum time in seconds the device
   SHOULD wait between sending a new notification.

   Maximum period indicated the maximum time in seconds the device
   SHOULD wait between sending the next notification (regardless if the
   value has changed).

   These options correspond with the Minimum response time (option 2),
   and Maximum response time (option 3) of the presented Conditional
   Observe.

   Second, the cancel observation interface of the OMA LWM2M for the
   information reporting corresponds with the Cancellation (option 0).

   Finally, the notification interface is similar.

   Therefore, OMA LWM2M Information Reporting can be implemented with
   the Conditional Observe.  In addition, Conditional Observe offers a
   set of extra features in order to set up more complex logic for the
   observation (subscription).

   The main difference and advantage of using Conditional Observe is
   that the minimum and maximum period options will be defined as part
   of the condition, since they are two options offered by conditional
   observe.  Thereby, it is not required the definition of minimum and
   maximum period by parameters (i.e., using the ?pmin={minimum period}
   and pmax={maximum period}).

   The Figure 12 presents an example to conditional observe the OMA
   Object 106 (which is an IPSO Sensor), Object instance 0, and the
   resource ID 4 (which is, for this example, a temperature value).
   This carries out a registration with a minium period of 30 seconds
   and a maximum period of 120 seconds.

      CLIENT                                                     SERVER
        |                                                          |
        | GET /106/0/4 observe:0,Condition:2/30,                   |
        |                             Condition:3/120        ----->|
        |                                                          |
        | <------ 2.05Content,observe:0,payload:4    (Sucess)     4|1s
        |                                                          |
        |                                                         3|5s
        |                                                          |
        |                                                         3|10s
        |                                                          |
        | <------ 2.04 Changed,observe:15,payload:12  (Notify)   12|15s
        |                                                          |
        |                                                        16|20s



Li, et al.              Expires December 26, 2013              [Page 26]

Internet-Draft         Conditional observe in CoAP             June 2013


        |                                                          |
        | <------ 2.04 Changed,,observe:25,payload:14 (Notify)   14|25s

        Figure 12: Example of conditional observe following the
            OMA LWM2M Information Reporting requirement.
            This example is observing the OMA Object 106,
            Object Instance ID 0, and Resource ID 4.
            This is defining a minimum period of 30 seconds
            and maximum period of 120 seconds.


Appendix B.  Alternative approaches

   In this appendix, we include some alternative solutions the authors
   have discussed regarding cancellation of relationships and the
   logical combination of different relationships.  The mechanisms
   described here allow more flexibility, but introduce additional
   (undesired?) complexity.  We put their description in this appendix
   to trigger further discussion and provide more background.

B.1.  Annex: Cancellation flag

   An alternative way to allow the explicit establishment and removal of
   conditional relationships and to allow the establishment of multiple
   conditional relationships to the same server using the same source
   transport address, is through the introduction of a 1 bit
   cancellation flag (C) as part of the 1 byte condition header.  The
   following paragraphs describe how this flag would change this
   behaviour.

   C: The cancellation flag, when used in an observe request, indicates
   whether the client wants to establish a conditional observation
   relationship (0) or cancel an existing conditional relationship (1).
   In the initial response, the server uses the same value as in the
   request.  In all further notifications, this flag has no meaning and
   must be 0.  In case of a request containing multiple Condition
   Options, the client must use the same value of the C flag in all
   Condition Options.  The cancellation flag allows a client to
   establish multiple conditional observation relationships and remove
   individual relationships from the same address and port.

   When using this cancellation flag, a client is able to establish
   multiple conditional relationships using the same source transport
   address.  Different from [I-D.ietf-core-observe] a GET without
   observe issued by a client, will not result in the removal of
   established conditional relationships.  Instead the client has the
   possibility to explicitly terminate any established conditional
   relationship by sending the same observe request, but with the



Li, et al.              Expires December 26, 2013              [Page 27]

Internet-Draft         Conditional observe in CoAP             June 2013


   Condition Option having the C flag set in order to trigger the
   cancellation of the request.  This way, the same end point can manage
   multiple conditional observation relationships without the risk of
   accidentally removing them.

   When a server receives a cancellation request, it removes the
   relationship indicated by the Condition Option and sends back a
   response containing both the Observe and the Condition Option with
   the cancellation flag set to 1.

   In case a client wants to terminate all existing conditional
   observation relationships with a server, it should send a request
   with Condition Option, where the Condition Type is set to the
   reserved value 0 and the cancellation flag to 1.  Upon reception of
   this message, the server removes all existing relationships and sends
   back a response containing the same Condition Type.

   In case a client has established a conditional relationship that is
   the result of a request with multiple Condition Options, the client
   can cancel this relationship by sending the same request, but now
   with all cancellation flags set to 1.

   If the server is for whatever reason not able to further fulfil the
   conditional relationship of a client, the server can also send a
   confirmable notification containing the Condition Option with the C
   flag set to 1 in order to terminate the observation relationship.

B.2.  Annex: Logic flag

   Different condition types can be combined in a request to express a
   logical AND relationship.  By default, logical OR of condition types
   is always supported through sending separate requests.  In order to
   express an out-of-range condition (notification when value is lower
   than X OR higher than Y), two separate conditional observe requests
   have to be sent.  Through the introduction of a 1 bit logic flag (L)
   as part of the 1 byte condition header, this can be avoided.

   L: The logic flag in a Condition Option indicates how the condition
   should be combined logically with the condition in the next Condition
   Option.  A value of 0 means AND and a value of 1 means OR.  The flag
   has no meaning if the Condition Option is the only or last Condition
   Option in the request.  Through the use of the L flag it is possible
   to logically combine different conditions in a single request (e.g.
   C1 AND C2 OR C3 AND C4).  As a drawback, when used, it complicates
   processing at the server side.

   This example (Figure 12) shows the same example from the (Figure 11)
   but with this alternative.  This example presents as the client adds



Li, et al.              Expires December 26, 2013              [Page 28]

Internet-Draft         Conditional observe in CoAP             June 2013


   two Observe options to build a range, one set to 6/22, another one
   set to 5/16.  It means that the range is out of range between 16 and
   22, i.e. value > 22 OR value < 16.  The first option is defined by
   default with the Logic flag equal to 0.  The second option is defined
   with the Logic flag equal to 1, since it is the OR option.  Note as
   it has been simplified from two messages to only one message with two
   options, and the most important, it has avoided the management of
   multiple ports.

      CLIENT                                                     SERVER
        |                                                          |
        | GET/temperature, observe:0,Condition:6/22 (L=0) --->     |
        |                            condition:5/16 (L=1) --->     |
        |                                                          |
        |                                                          |
        |                                                          |18
        |                                                          |
        | <------ 2.05Content,observe:10,payload:22,5              |22.5
        |                                                          |
        | <------ 2.05Content,observe:20,payload:23.2              |23.2
        |                                                          |
        |                                                          |19
        |                                                          |
        |  <------ 2.05Content,observe:35,payload:15               |15

                 Figure 13: Two Observe options with Logic flag to define
                 out-side a range 6/22 OR 5/15.


Appendix C.  Change log

   Changes in v04

   o  Updated draft to be consistent with updated observe draft:

      *  Took request URI into consideration for Cancellation.

      *  Explicitly stated that the timing conditions allow a client to
         use a representation that is older than Max-Age without
         verifying the representation first.  This collides with a MUST
         NOT from the observe draft.

      *  Stated that a server should follow the text from the observe
         draft for an unacknowledged notification in regards to the
         transmission of new notifications and the cancellation of
         existing relationships.





Li, et al.              Expires December 26, 2013              [Page 29]

Internet-Draft         Conditional observe in CoAP             June 2013


   o  Added section 2.1 comparing the RESTful approach from draft-
      shelby-core-interfaces to our approach for conditional
      observations.

   o  Clarified why "AND" semantics are preferred over "OR" semantics in
      case of multiple Condition options.

   o  Clarified that the R flag doesn't violate the behaviour defined in
      the Observe draft.

   o  Clarified that a client might opt to use representations older
      than Max-Age without validating these first in case of most of the
      timing conditions.  A server has the ability to deny the client
      this sort of behaviour however.

   o  Updated source endpoint terminology.

   Changes in v03

   o  Examples for most condition types

   o  Update the option number according to the new numbering scheme

   o  Added reference to paper validating implementation on constrained
      device

   Changes in v02

   o  Restructured entire document

   o  Detailed description of the Condition Option and updated format of
      the Condition Option value

   o  Added more Condition Types

   o  New section on cancellation, updating and existence of conditional
      relationships

   o  New section on discovery

Authors' Addresses










Li, et al.              Expires December 26, 2013              [Page 30]

Internet-Draft         Conditional observe in CoAP             June 2013


   Shitao Li
   Huawei Technologies
   Huawei Base
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Phone: +86-25-56624157
   Email: lishitao@huawei.com


   Jeroen Hoebeke
   iMinds-IBCN/UGent
   Department of Information Technology
   Internet Based Communication Networks and Services (IBCN)
   Ghent University - iMinds
   Gaston Crommenlaan 8 bus 201
   Ghent  B-9050
   Belgium

   Phone: +32-9-3314954
   Email: jeroen.hoebeke@intec.ugent.be


   Floris Van den Abeele
   iMinds-IBCN/UGent
   Department of Information Technology
   Internet Based Communication Networks and Services (IBCN)
   Ghent University - iMinds
   Gaston Crommenlaan 8 bus 201
   Ghent  B-9050
   Belgium

   Phone: +32-9-3314946
   Email: floris.vandenabeele@intec.ugent.be


   Antonio J. Jara
   University of Murcia
   Department of Information Technology and Communications
   Computer Science Faculty
   Campus de Espinardo
   Murcia  ES-30100
   Spain

   Phone: +34-868-88-8771
   Email: jara@um.es




Li, et al.              Expires December 26, 2013              [Page 31]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/