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]