idnits 2.17.1 draft-li-core-conditional-observe-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 24, 2013) is 3960 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1053, but not defined == Unused Reference: 'I-D.ietf-core-link-format' is defined on line 1085, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CPSCOM' == Outdated reference: A later version (-27) exists of draft-bormann-coap-misc-13 ** Downref: Normative reference to an Informational draft: draft-bormann-coap-misc (ref. 'I-D.bormann-coap-misc') == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-17 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'OMADM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SENSORS' Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core Shi. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track J. Hoebeke 5 Expires: December 26, 2013 F. Van den Abeele 6 iMinds-IBCN/UGent 7 A. Jara 8 University of Murcia 9 June 24, 2013 11 Conditional observe in CoAP 12 draft-li-core-conditional-observe-04 14 Abstract 16 CoAP is a RESTful application protocol for constrained nodes and 17 networks. Through the Observe option, clients can observe changes in 18 the state of resources and obtain a current representation of the 19 last resource state. This document defines a new mechanism in CoAP 20 Observe so that a CoAP client can conditionally observe a resource on 21 a CoAP server, only being informed about state changes meeting a 22 specific condition or set of conditions. This offers possibilities 23 to extend network intelligence, enhance scalability, and optimize the 24 lifetime and performance in order to address the requirements from 25 the Constrained Nodes and Networks. 27 Note 29 Discussion and suggestions for improvement are requested, and should 30 be sent to core@ietf.org. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 26, 2013. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. Comparison to RESTful method . . . . . . . . . . . . . . 5 71 3. The Condition Option . . . . . . . . . . . . . . . . . . . . 5 72 4. Condition Types . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Using the Condition Option . . . . . . . . . . . . . . . . . 11 74 6. Cancellation, updating and existence of conditional 75 relationships . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. Cancellation and updating . . . . . . . . . . . . . . . . 12 77 6.2. Existence . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 10.1. Condition option registry . . . . . . . . . . . . . . . 22 83 10.2. Condition type registry . . . . . . . . . . . . . . . . 23 84 11. Further considerations . . . . . . . . . . . . . . . . . . . 23 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 86 13. Normative References . . . . . . . . . . . . . . . . . . . . 24 87 Appendix A. OMA Information Reporting with CoAP Conditional 88 Observe . . . . . . . . . . . . . . . . . . . . . . 24 89 Appendix B. Alternative approaches . . . . . . . . . . . . . . . 27 90 B.1. Annex: Cancellation flag . . . . . . . . . . . . . . . . 27 91 B.2. Annex: Logic flag . . . . . . . . . . . . . . . . . . . . 28 92 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 29 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 95 1. Introduction 96 CoAP [I-D.ietf-core-coap] is an Application Protocol for Constrained 97 Nodes/Networks. The observe [I-D.ietf-core-observe] specification 98 describes a protocol design so that a CoAP client and server can use 99 the subject/observer design pattern to establish an observation 100 relationship. When observe is used, the CoAP client will get a 101 notification response whenever the state of the observed resource 102 changed. However, in some scenarios, the CoAP client may only be 103 interested in a subset of state changes of the resource, other state 104 changes might be meaningless. This inability to suppress additional 105 notifications results in superfluous traffic. This memo defines a 106 new CoAP option "Condition" that can be used to allow the CoAP client 107 to condition the observe relationship, and only when such condition 108 is met, the CoAP server shall send the notification response with the 109 latest state change. When such a condition fails, the CoAP server 110 does not need to send the notification response. 112 1.1. Justification 114 A GET request that includes an Observe Option creates an observation 115 relationship. When a server receives such a request, it first 116 services the request like a GET request without this option and, if 117 the resulting response indicates success, establishes an observation 118 relationship between the client and the target resource. The client 119 is notified of resource state changes by additional responses sent in 120 reply to the GET request to the client. 122 CoAP is used for Constrained Networks, especially used for 123 transporting sensor data. Different sensor equipments have different 124 properties, e.g. different change rates, data unit, different 125 response time, etc. resulting in varying clients' interests that 126 differ from mere state changes. As such, when a client wants to 127 collect information from a sensor, it does not want to receive 128 useless information. In addition, this would cause the transmission 129 of irrelevant information in an already constrained network. 131 Consider the following example. 133 CLIENT SERVER 134 | | 135 | GET/temperature observe:0 ------> | 136 | | 137 | <------ 2.05 Content observe:5 Payload:22 | 138 | | 139 | | 140 | | 141 | <------ 2.05 Content observe:10 Payload:22.3 | 142 | | 143 | | 144 | | 145 | <------ 2.05 Content observe:15 Payload:22.6 | 146 | | 148 Figure 1: GET request with observe 150 In this example, the sensor acts as a server, and it collects the 151 resource data every 5 seconds. When the client observes a resource 152 on the server, it will receive a response whenever the server updates 153 the resource, that is to say, mostly every 5 seconds the client will 154 receive a notification response. However, the client might be a 155 quite simple equipment not too sensitive to the resource state 156 change, so it may not want to receive notifications that often. One 157 possible solution could be to alter the sensor's configuration, e.g. 158 to shorten the collecting frequency. However, the sensor should be 159 able to provide services to many other clients, making it hard to 160 find the best configuration that fits all clients' requirements. 162 1.2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 2. Motivation 170 The CoAP Observe Option gives clients the ability to observe changes 171 in the state of resources. A notification relationship is 172 established and whenever the state of the resource changes, the new 173 representation is pushed to the observer. In many cases, an observer 174 will typically be interested in state changes that satisfy a specific 175 condition. In addition, similar conditional observations will prove 176 useful for many different resources. For example, being informed 177 when the state of a resource exceeds a specific value. 179 Defining an agreed set of commonly used conditional observations has 180 a number of advantages. In a well-defined way, clients can observe 181 different resources conditionally. At the same time, these resources 182 can clearly announce how they can be observed, facilitating machine 183 processing of this information. Also, intermediaries can process 184 multiple conditional observations, having as goal to alleviate the 185 load on the constrained network and devices. In the absence of such 186 a set of commonly used conditional observations, where every 187 application developer can specify its own mechanisms, these 188 advantages are lost. 190 2.1. Comparison to RESTful method 192 In [I-D.shelby-core-interfaces] a simple RESTful mechanism is 193 described to provide additional conditions to the Observe Option 194 through the use of URI query parameters. It proves that conditional 195 observations are useful but begs the question how the two approaches 196 stack up to each other. The authors think that both approaches come 197 with their advantages and disadvantages. Here we try to give an 198 overview for both approaches. This short list of arguments for and 199 against both approaches isn't meant to be exhaustive. We as authors 200 of this draft are aware that we are - by definition - biased and we 201 welcome any feedback via our contact details and/or via the CoRE 202 mailing list. 204 When using the RESTful approach care should be given to avoid overlap 205 with URI query parameters that a resource might want to use itself. 206 Therefore a clear RESTful interface should define how all the 207 possible condition type are mapped to said interface. Specifying 208 conditions via URI query parameters also requires a separate request 209 for the conditions because - by default - all URI query parameters in 210 a request are part of the Cache-Key. Furthermore, it makes 211 identifying conditions harder when compared to a dedicated CoAP 212 condition option. The current approach also doesn't allow multiple 213 clients observing the same resource with different conditions. 214 Including this into the RESTful approach, while keeping caching in 215 mind, has yet to be considered. Another unspecified matter is 216 signalling which condition types are supported by a resource. 218 The main advantage of the approach proposed in the interfaces draft 219 is that due to its RESTful design it doesn't rely on Application 220 protocol specific mechanisms (like CoAP options). This means that 221 the interface can easily be supported by any other (application) 222 protocol that supports the RESTful paradigm. It also means that 223 servers and clients can limit their implementation of CoAP to the 224 basic building blocks of the protocol and use those to add additional 225 logic (in the form of RESTful interfaces) as opposed to supporting 226 yet another option. Another - albeit a purist - argument is that 227 CoAP options should limit themselves to controlling the CoAP protocol 228 and should not influence the representations offered by a resource, 229 as these should be defined within the REST interactions themselves. 231 3. The Condition Option 233 +------+-----+-----------+-----------+--------+---------------+ 234 | Type | C/E | Name | Data type | Length | Default | 235 +------+-----+-----------+-----------+--------+---------------+ 236 | 18 | E | Condition | uint | 1-5 B | (none) | 237 +------+-----+-----------+-----------+--------+---------------+ 238 Table 1: Condition Option number 240 The Condition Option has the option number 18. The last bit 241 indicates it is an elective option and the second to last bit 242 indicates that this is a Proxy Unsafe option (similar to the Observe 243 Option). The delta between the Condition Option and the Observe 244 Option is 12. 246 The Condition Option can be present in both request and response 247 messages. In both cases, it must be used together with the Observe 248 Option, since it extends the meaning of the Observe Option. 250 In a GET request message, the Condition Option represents the 251 condition the client wants to apply to the observation relationship. 252 It is used to describe the resource states the client is interested 253 in. 255 In the response to the initial GET request message, the Condition 256 Option, together with the Observe Option, indicates that the client 257 has been added to the list of observers and that notifications will 258 be sent only when the resource state meets the condition specified in 259 the Condition Option. In all further notifications, the Condition 260 Option identifies the condition to which the notification applies. 262 Basically, a similar procedure as described in the observe draft 263 [I-D.ietf-core-observe] is followed, but extended with additional 264 behaviour by taking the Condition Option into account. The exact 265 semantics are defined in the sections below. 267 The size of the Condition Option value is not fixed and can range 268 from 1 to 5 bytes. The value carried is in a specific format that 269 consist of two parts: a mandatory condition header and an optional 270 condition value. The condition header has a fixed length of 1 byte 271 and the condition value, when present, can range from 1 to 4 bytes. 272 The condition header consists of 3 fields: the condition type (TYPE), 273 reliability flag (R) and value type (V). 275 The Condition Option may occur more than once. If multiple Condition 276 Options are present in a request, their relationship is "AND", 277 meaning that the server will only send a notification when both 278 conditions are fulfilled. In the notifications to such a request, 279 the same Condition Options are present. The Figure 10 presents an 280 example of a multiple condition with "AND" conjunction. 282 Note that in order to establish an "OR" relationship between 283 conditions, a client simply needs to send separate requests using 284 different source endpoints. The Figure 11 presents an example of OR 285 condition with multiple requests, which are sent in two messages via 286 different source transport ports. 288 Since this solution could be considered as non-optimal, an 289 alternative solution is proposed for discussion in the Annex "Logic 290 flag", where multiple OR relationships with multiple conditional 291 options can be defined, similar as has been presented for the "AND" 292 conjunction. 294 In case of multiple Condition options, the main reason for choosing 295 "AND" semantics over "OR" semantics is motivated by the fact that in 296 case of the "OR" semantics the notification must be send anyway (as 297 opposed to the "AND" case). This choice minimizes the amount of 298 useless notifications that are sent over the network. The authors 299 foresee that for some constrained devices supporting more than 1 300 condition per relationship might not be possible, in that case the 301 client should try to establish the required behaviour using a minimal 302 number of 1-condition relationships and filtering out unwanted 303 notifications at the client-side. 305 0 306 0 1 2 3 4 5 6 7 307 +-+-+-+-+-+-+-+-+ 308 | TYPE |R| V | 309 +-+-+-+-+-+-+-+-+ 311 0 1 312 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | TYPE |R| V | VAL | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 0 1 2 318 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 . . 7 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | TYPE |R| V | VAL | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 0 1 2 3 324 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 . . 7 0 . . 7 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | TYPE |R| V | VAL | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 0 1 2 3 4 330 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 . . 7 0 . . 7 0 . . 7 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | TYPE |R| V | VAL | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 2: Condition Option value 338 TYPE: The condition type is a 5 bit integer indicating the type of 339 the condition in the observe request or in a notification. Every 340 value of TYPE represents the type ID of a specific condition type. 341 Every condition type can be complemented by a condition value in the 342 VAL field, further specifying the condition in more detail. Below is 343 the definition of identified condition types. 345 R: In an observe request, the reliability flag indicates whether 346 notifications for that condition need to be send non-confirmable (0) 347 or confirmable (1). In the initial response, this flag indicates the 348 server's willingness or ability to send the notifications confirmable 349 or non-confirmable, as requested by the client. In all further 350 notifications, this flag can be changed depending on the server's 351 decision. In case of a request containing multiple Condition 352 Options, the client must use the same value of the R flag in all 353 Condition Options. If the server receives a request with multiple 354 Condition Options, which do not all share the same value of the R 355 flag, the server MUST respond with a 4.00 "Bad Request" response 356 code. Note that the observe draft states that the message type of a 357 notification is independent from the type used for the request or any 358 previous notification. The R flag doesn't violate this behaviour and 359 a client should expect that a CON notification might arrive without 360 this being explicitly signalled by the server (as a NON-notification 361 signalling this, might not arrive). 363 V: The value type is a 2 bit field in a request or response that 364 gives the data type of the condition value, when present in the 365 Condition Option. If no condition value is present, this field has 366 no meaning and must be 0. Table 2 gives an overview of all available 367 value types. The Duration data type is defined in Appendix C.2 of 368 [I-D.bormann-coap-misc]. The representation of floating point 369 numbers in a common format that is understandable by constrained 370 devices is outside the scope of this document. 372 +-----------------------+------+ 373 | Value type (2 bit) | Id. | 374 +-----------------------+------+ 375 | Integer | 0 | 376 +-----------------------+------+ 377 | Duration (s) | 1 | 378 +-----------------------+------+ 379 | Float | 2 | 380 +-----------------------+------+ 382 Table 2: Value types 384 VAL: The condition value is 1 to 4 byte value of the type indicated 385 by the V flag. The condition value is used to indicate the value 386 that further specifies the condition type (e.g. a threshold). 387 Condition types can require the presence of a condition value. When 388 a condition value is present in an observe request, the same value 389 must be used in the initial response. In all further notifications, 390 the condition value can be left out to reduce the size of the option. 392 4. Condition Types 394 Table 3 gives an overview of all currently identified condition 395 types. If supported by the server, different condition types can be 396 combined in a request to express a logical AND relationship. By 397 default, logical OR of condition types is always supported through 398 sending separate requests using different source endpoints. 400 +-----------------------+------+-----------------+ 401 | Condition type (5 bit)| Id. | Condition Value | 402 +-----------------------+------+-----------------+ 403 | Cancellation | 0 | no | 404 +-----------------------+------+-----------------+ 405 | Time series | 1 | no | 406 +-----------------------+------+-----------------+ 407 | Minimum response time | 2 | yes | 408 +-----------------------+------+-----------------+ 409 | Maximum response time | 3 | yes | 410 +-----------------------+------+-----------------+ 411 | Step | 4 | yes | 412 +-----------------------+------+-----------------+ 413 | AllValues< | 5 | yes | 414 +-----------------------+------+-----------------+ 415 | AllValues> | 6 | yes | 416 +-----------------------+------+-----------------+ 417 | Value= | 7 | yes | 418 +-----------------------+------+-----------------+ 419 | Value<> | 8 | yes | 420 +-----------------------+------+-----------------+ 421 | Periodic | 9 | yes | 422 +-----------------------+------+-----------------+ 424 Table 3: Condition types 426 Time series: This condition indicates that a client wants to receive 427 all state changes of a resource, but that it does not want to receive 428 a notification in case the time since the last notification was sent 429 became greater than the max-age of the resource and the resource did 430 not change during this period. --> This is a variant of the observe 431 draft [I-D.ietf-core-observe] that deals with eventual consistency, 432 which may result in notifications even if the resource did not change 433 in order to ensure the observer has a fresh representation of the 434 resource. Note that the observe draft states that if the age of the 435 latest notification becomes greater than its indicated Max-Age, then 436 the client MUST NOT use the enclosed representation until it is 437 validated or a new notification is received. In case of the Time 438 series condition a client might opt to divert from this behaviour and 439 use these older notifications anyway. The client signals this to the 440 server by choosing a Time series condition value larger than the Max- 441 Age of the resource and including this option in its observe request. 442 In case the server thinks this behaviour isn't feasible, it signals 443 this to the client by removing the time series Condition option from 444 its response. In case the server's response does echo the Time 445 series condition, then the client is allowed to divert from the 446 behaviour specified in the observe draft and use these 'older' 447 notifications. Similar considerations hold true for the other timing 448 condition types that are defined in this draft. 450 Minimum response time: For this condition, the value specified in the 451 condition value field gives the minimum time in seconds the server 452 should leave between subsequent notifications. 454 Maximum response time: For this condition, the value specified in the 455 condition value field gives the maximum time in seconds the server is 456 allowed to leave between subsequent notifications. 458 Step: For this condition, the value specified in the condition value 459 field gives the minimum state change of a resource (since the last 460 notification) before the server should send a new notification. 462 AllValues<: This condition indicates that a client is only interested 463 in receiving notifications whenever the state of the resource changes 464 and the value is less than the value specified in the condition value 465 field. 467 AllValues>: This condition indicates that a client is only interested 468 in receiving notifications whenever the state of the resource changes 469 and the value is greater than the value specified in the condition 470 value field. 472 Value=: This condition indicates that a client is only interested in 473 receiving notifications whenever the state of the resource changes 474 and the value is equal to the value specified in the condition value 475 field. 477 Value<>: This condition indicates that a client is only interested in 478 receiving a single notification whenever the state becomes higher or 479 lower than the value specified in the condition value field. Once 480 the notification has been sent, no new notifications are sent for 481 subsequent state changes where the value remains higher or lower. As 482 such, a single notifications is sent whenever a threshold is passed 483 in either direction. 485 Periodic: This condition indicates the periodic interval in seconds 486 with which new notifications should be sent. 488 5. Using the Condition Option 490 Whenever a client wants to initiate a Conditional Observation 491 relationship, it sends a GET request with both an Observe and at 492 least one Condition Option. The Condition Option extends the meaning 493 of the Observe Option by including a condition that describes the 494 resource states the client is interested in. It represents the 495 condition the client wants to apply to the observation relationship. 497 When a server receives such a request, it first services the request 498 the same way as described in [I-D.ietf-core-observe]. Next, if the 499 server supports the Condition Option, it analyses the Condition 500 Option to find the condition requested by the client. If the 501 condition is supported, the relationship is stored and the client is 502 informed about the successful establishment of the conditional 503 relationship. This is done by sending a response containing both the 504 Observe and Condition Option, which implies that the client has now 505 been added to the list of observers and will only be informed about 506 state changes or resource states satisfying the condition described 507 in the Condition Option. 509 Since the Condition Option is elective, an observe request that 510 includes the Condition Option will automatically fall back to a basic 511 observe request if the server does not support the Condition Option. 512 There is no default value for the Condition Option. Also, if the 513 Condition Option is supported, but the requested condition is not 514 supported by the resource, the request will also fall back to a basic 515 observe request, resulting in a response only containing the Observe 516 Option. This implies that the client will now receive notifications 517 as described in [I-D.ietf-core-observe] and that the client itself is 518 responsible for processing the resource state in the notifications in 519 order to identify whether the condition of interest is fulfilled. 521 Whenever the state of a resource that supports conditional 522 observations changes on the server, the server needs to check the 523 established conditional relationships. Whenever the relationship 524 condition(s) is(are) met, the server sends the notification response 525 to the client that has established the relationship. In case the 526 server is still waiting for a confirmable notification to be 527 acknowledged or the 3 seconds on average for a non-confirmable 528 notification to elapse, it MUST adhere to the behaviour specified in 529 section 4.5 of [I-D.ietf-core-observe]. The response contains both 530 the Observe Option and the Condition Option, where the latter option 531 describes the condition that has been fulfilled. If not met, the 532 server does not send any response to the client. Furthermore, the 533 server also doesn't send a response when the last notification is 534 older than Max-Age. 536 A client is allowed to use multiple Condition Options in an observe 537 request in order to express a logical AND relationship between 538 different condition types. When a server receives such a request and 539 it does not support composed conditions, the request will also fall 540 back to a basic observe request, resulting in a response only 541 containing the Observe Option. If the server supports this, it will 542 store the relationship and send back a response echoing the same 543 multiple Condition Options. 545 In case a client wants to establish multiple different conditional 546 relationships with the same server, it needs to use a different 547 source endpoint for every conditional relationship. 549 6. Cancellation, updating and existence of conditional relationships 551 6.1. Cancellation and updating 553 In case a client wants to cancel an existing conditional 554 relationship, it has to perform a GET request to the target resource 555 without Observe and Condition Option using the same source endpoint 556 used to establish the conditional relationship (i.e. source endpoint 557 of the original request). Upon reception of such a GET request, the 558 server will remove the client from the list of conditional observers 559 for that resource. 561 Alternatively, the client can also send a confirmable request 562 containing a Condition Option with condition type _Cancellation_. 563 The source endpoint used by the client together with the request URI 564 uniquely identifies the conditional relationship the client has with 565 the server. Upon reception of such a message, the server knows that 566 the client wants to terminate the relationship it has established. 568 This cancellation mechanism implies that whenever a client wants to 569 establish multiple different conditional relationships with the same 570 resource on the same server, it needs to use a different source 571 endpoint for every conditional relationship. 573 When a client has established a conditional relationship and it sends 574 a new conditional observe request using the same source endpoint to 575 the same resource, the existing relationship is removed and the new 576 relationship established. This way, a client is able to update 577 existing relationships. 579 Apart from the cancellation through sending a GET request without 580 Observe and Condition Option, a conditional relationship can also be 581 cancelled by sending a RST message in response of a confirmable 582 notification. When a client rejects a non-confirmable notification 583 with a RST, the server can remove the client from the list of 584 observers interested in the specific condition of the resource in 585 case the server maintains state information about non-confirmable 586 notifications. 588 Additionally, if the server is for whatever reason not able to 589 further fulfill the conditional relationship of a client, the server 590 can also send a confirmable notification containing a Condition 591 Option with condition type 'Cancellation' (echoing the Token in the 592 notification). The client's endpoint and the request URI uniquely 593 identify a conditional relationship with a server. As such, upon 594 reception of such a message, the client can infer the request URI 595 from the request associated with the Token contained in the response 596 and knows the relationship that has been terminated by the server. 598 Finally, when a server sends a confirmable notification that is not 599 acknowledged by the observer, the server may terminate the 600 relationship after the last unsuccessful delivery attempt of said 601 notification. 603 Note: The possibilities to establish a Cancellation flag have also 604 been evaluated, see Annex "Cancellation flag". This has been 605 discarded since, as it is too complex for processing, when multiple 606 conditions are defined. 608 6.2. Existence 610 The observe draft [I-D.ietf-core-observe] specifies that at a minimum 611 a server must send a notification in a confirmable message at least 612 every 24 hours. In case of monitoring critical events this 24-hour 613 interval is most likely too short. Therefore additional, more 614 flexible mechanisms for checking the existence of a (conditional) 615 relationship are needed. This paragraph presents two ideas in the 616 form of CoAP options that augment the default periodic confirmable 617 message. 619 A client has the possibility to establish and remove conditional 620 relationships and a server can also inform a client about the removal 621 of a conditional relationship. Next to this, there is the issue of 622 how long the relationship is guaranteed to exist in the absence of 623 any explicit removal from either the client or server side (e.g. a 624 client that wants to maintain the relationship for a very long time) 625 or in the absence of frequent notifications. To this end, a 626 mechanism is needed for a client to know whether it is still on the 627 list of observers and for a server to know whether a client is still 628 an observer. 630 In order for a client to know whether it is still on the list of 631 observers after a long period without notifications or without 632 confirmable notifications, the server can use the Pledge Option, as 633 defined in [I-D.bormann-coap-misc]. By adding this option to its 634 notifications, the server indicates how long it minimally promises to 635 maintain that specific conditional relationship. In case no new 636 notifications or non-confirmable notifications are sent and the 637 duration indicated in the Pledge Option is to expire, the client must 638 renew the relationship by resending the same request, preferable as a 639 confirmable message. 641 In case the duration indicated in the Pledge Option expires at the 642 server side and the client did not renew the relationship, the server 643 must remove the relationship by sending an explicit cancellation 644 message (a confirmable notification to the client's source endpoint 645 containing a Condition Option with condition type 'Cancellation'.). 646 As such, the use of the Pledge Option extends the establishment and 647 removal mechanism with a server-initiated mechanism to realize 648 intermediate refreshments of the relationship. 650 The second mechanism, for a server to determine whether a client is 651 still an observer, is realized by adding a Keep-Alive Option to the 652 observe request. The size of the Keep-Alive Option value is 1 byte 653 and represents a duration in seconds, using the Duration data type as 654 defined in Appendix C.2 of [I-D.bormann-coap-misc]. 656 +------+-----+------------+----------------+--------+---------+ 657 | Type | C/E | Name | Format | Length | Default | 658 +------+-----+------------+----------------+--------+---------+ 659 | 30 | E | Keep-alive | Duration in s | 1 B | (none) | 660 +------+-----+------------+----------------+--------+---------+ 662 Table 4: Keep-alive Option number 664 The Keep-Alive Option has the option number 30, meaning that it is an 665 elective, Proxy Safe option, but not a cache key. 667 When the client adds the Keep-Alive option to its conditional observe 668 request, it requests the server to confirm that the relationship is 669 still alive every time the duration expires and no notifications or 670 only non-confirmable notifications have been sent during that period. 671 If the option is supported by the server, the option is echoed in its 672 first response. Every time the duration expires and no notifications 673 or only non-confirmable notifications have been sent, the server 674 sends a confirmable notification to the client with an empty payload 675 (since the condition is not fulfilled). As such, the use of the 676 Keep-alive Option extends the establishment and removal mechanism 677 with a client-initiated mechanism to realize intermediate 678 refreshments of the relationship. Furthermore it allows a client to 679 explicitly specify the 24-hour interval mentioned in the observe 680 draft. 682 The Pledge Option allows a server to request a client to confirm its 683 interest and the Keep-Alive option allows a client to request a 684 server to confirm whether it is still an observer. In case neither 685 of the two options are supported, the only way for the client to 686 ensure the relationship is still existing in the absence of incoming 687 notifications is to periodically re-establish the relationship and 688 the only way for the server to ensure the client is still interested 689 is to send a confirmable notification from time to time. 691 7. Discovery 693 The Condition Option enables the establishment of well-defined set of 694 conditional observations. It is equally important for a resource to 695 be able to announce in a well-defined way which conditional 696 observations it supports. Clients can then discover these 697 capabilities and process them automatically. 699 In [I-D.ietf-core-observe], the "obs" attribute is introduced as a 700 target attribute. It is used as a flag without any value, indicating 701 that the resource is observable. In order to describe the 702 conditional observe capabilities of a resource, a value is added to 703 the obs attribute. To describe which of the 2^5 possible condition 704 types a resource supports, a 32-bit value is used where a bit-value 705 of 1 at position X (starting from 0 and from right to left) indicates 706 that the condition type X is supported. As such, by a client can 707 discover the supported observe capabilities by parsing the value of 708 the "obs" attribute. In case no value is present, the "obs" 709 attribute preserves its original meaning. 711 8. Examples 713 This section gives a number of short examples with message flows to 714 illustrate the use of Condition Option in a observe GET request. 715 Note that, in order to keep the figures readable, the Condition 716 Option that is included in every notification is not shown. 718 The first example (Figure 3) shows that the client sets the Condition 719 Option to Type: 1 - No Value (1/-). The condition is Time Series, 720 meaning that the client wants to receive all state changes. In case 721 the state of the resource does not change, no notifications are sent, 722 also not in case max-age expires. We assume a max-age value of 60 723 seconds. 725 CLIENT SERVER 726 | | 727 | GET/temperature,observe:0,Condition:1/- -----> 22|0s 728 | | 729 | <------ 2.05Content,observe:0,payload:22 | 730 | | 731 | | 732 | <------ 2.05Content,observe:10,payload:22.4 22.4|10s 733 | | 734 | <------ 2.05Content,observe:15,payload:23 23|15s 735 | | 736 | <------ 2.05Content,observe:20,payload:23.5 23.5|20s 737 | | 738 | <------ 2.05Content,observe:25,payload:24 24|25s 739 | | 740 | <------ 2.05Content,observe:30,payload:22 22|30s 741 | | 742 | 22|35s 743 | | 744 | [max-age exp.] 22|90s 745 | | 746 | <------ 2.05Content,observe:120,payload:22.2 22.2|120s 747 | | 749 Figure 3: Condition Option with value 1/- (Time Series) 751 The following example (Figure 4) shows that the client sets the 752 Condition Option to Type: 2 - Value: 10 (2/10), This means that the 753 server shall wait at least 10s between sending notification 754 responses, indicating changes in the state of the resource, to the 755 client. 757 CLIENT SERVER 758 | | 759 | GET/temperature,observe:0,Condition:2/10 -----> 22|0s 760 | | 761 | <------ 2.05Content,observe:0,payload:22 | 762 | | 763 | | 764 | <------ 2.05Content,observe:10,payload:22.4 22.4|10s 765 | | 766 | 23|15s 767 | | 768 | <------ 2.05Content,observe:20,payload:23.5 23.5|20s 769 | | 770 | 24|25s 771 | | 772 | <------ 2.05Content,observe:30,payload:22 22|30s 773 | | 774 | 22|35s 775 | | 776 | 22|90s 777 | | 778 | <------ 2.05Content,observe:120,payload:22.2 22.2|120s 779 | | 781 Figure 4: Condition Option with value 2/10 (Minimum Response Time) 783 The next example (Figure 5) shows that the client sets the Condition 784 Option to Type: 3 - Value: 60 (3/60). The server will send 785 notifications upon every state change, but will leave maximally 60s 786 between subsequent notifications, even if they do not incur a state 787 change. 789 CLIENT SERVER 790 | | 791 | GET/temperature,observe:0,Condition:3/60 -----> 22|0s 792 | | 793 | <------ 2.05Content,observe:0,payload:22 | 794 | | 795 | | 796 | <------ 2.05Content,observe:10,payload:22.4 22.4|10s 797 | | 798 | <------ 2.05Content,observe:15,payload:23 23|15s 799 | | 800 | <------ 2.05Content,observe:20,payload:23.5 23.5|20s 801 | | 802 | <------ 2.05Content,observe:25,payload:24 24|25s 803 | | 804 | <------ 2.05Content,observe:30,payload:22 22|30s 805 | | 806 | 22|35s 807 | | 808 | <------ 2.05Content,observe:90,payload:22 22|90s 809 | | 810 | <------ 2.05Content,observe:120,payload:22.2 22.2|120s 811 | | 813 Figure 5: Condition Option with value 3/60 (Maximum Response Time) 815 Figure 6 shows a client setting the Condition Option to Type: 4 - 816 Value: 1 (4/1). The server will now send notifications every time 817 the change in state of the resource is at least 1. 819 CLIENT SERVER 820 | | 821 | GET/temperature,observe:0,Condition:4/1 -----> 22|0s 822 | | 823 | <------ 2.05Content,observe:0,payload:22 | 824 | | 825 | | 826 | 22.4|10s 827 | | 828 | <------ 2.05Content,observe:15,payload:23 23|15s 829 | | 830 | 23.5|20s 831 | | 832 | <------ 2.05Content,observe:25,payload:24 24|25s 833 | | 834 | <------ 2.05Content,observe:30,payload:22 22|30s 835 | | 836 | 22|35s 837 | | 838 | 22|90s 839 | | 840 | 22.2|120s 841 | | 843 Figure 6: Condition Option with value 4/1 (Step) 845 The example in Figure 7 shows that the client sets the Condition 846 Option to Type: 6 - Value: 23 (6/23). The server will send 847 notifications to the client only if the resource value is bigger than 848 23. 850 CLIENT SERVER 851 | | 852 | GET/temperature,observe:0,Condition:6/23 -----> 22|0s 853 | | 854 | <------ 2.05Content,observe:0,payload:22 | 855 | | 856 | | 857 | 22.4|10s 858 | | 859 | 23|15s 860 | | 861 | <------ 2.05Content,observe:20,payload:23.5 23.5|20s 862 | | 863 | <------ 2.05Content,observe:25,payload:24 24|25s 864 | | 865 | 22|30s 866 | | 867 | 22|35s 868 | | 869 | 22|90s 870 | | 871 | 22.2|120s 872 | | 874 Figure 7: Condition Option with value 6/23 (AllValues>) 876 Figure 8 is an example of a client setting the Condition Option to 877 Type: 8 - Value: 23 (8/23). The server will send a single 878 notification whenever the state becomes higher or lower than 23. 880 CLIENT SERVER 881 | | 882 | GET/temperature,observe:0,Condition:8/23 -----> 22|0s 883 | | 884 | <------ 2.05Content,observe:0,payload:22 | 885 | | 886 | | 887 | 22.4|10s 888 | | 889 | 23|15s 890 | | 891 | <------ 2.05Content,observe:20,payload:23.5 23.5|20s 892 | | 893 | 24|25s 894 | | 895 | <------ 2.05Content,observe:30,payload:22 22|30s 896 | | 897 | 22|35s 898 | | 899 | 22|90s 900 | | 901 | 22.2|120s 902 | | 904 Figure 8: Condition Option with value 8/23 (Values<>) 906 Figure 9 is an example of a client setting the Condition Option to 907 Type: 9 - Value: 30 (9/30). The server will send notifications every 908 30 seconds, independent whether the resource has changed or not. 910 CLIENT SERVER 911 | | 912 | GET/temperature,observe:0,Condition:9/30 -----> 22|0s 913 | | 914 | <------ 2.05Content,observe:0,payload:22 | 915 | | 916 | | 917 | 22.4|10s 918 | | 919 | 23|15s 920 | | 921 | 23.5|20s 922 | | 923 | 24|25s 924 | | 925 | <------ 2.05Content,observe:30,payload:22 22|30s 926 | | 927 | <------ 2.05Content,observe:60,payload:22 22|60s 928 | | 929 | <------ 2.05Content,observe:90,payload:22 22|60s 930 | | 931 | <------ 2.05Content,observe:120,payload:22.2 22.2|120s 932 | | 934 Figure 9: Condition Option with value 9/30 (Periodic) 936 In the following examples, we illustrate the combination of different 937 conditions. The example in Figure 10 shows the client adds two range 938 Condition Options in the request, one set to 6/5, another one set to 939 5/15. It means that the range is within 5 and 15, i.e. value > 5 AND 940 value < 15. Since it is an AND condition, the two conditions can be 941 specified in the same observe with multiple options. 943 CLIENT SERVER 944 | | 945 | GET/temperature, observe:0,Condition:6/5, | 946 Condition:5/15 ----->| 947 | | 948 | <------ 2.05Content,observe:0,payload:4 4|0s 949 | | 950 | 3|5s 951 | | 952 | 3|10s 953 | | 954 | <------ 2.05Content,observe:15,payload:12 12|15s 955 | | 956 | 16|20s 957 | | 958 | <------ 2.05Content,observe:25,payload:14 14|25s 960 Figure 10: Two Condition Options to define in-side a range option 961 6/5 AND 5/15 (AllValues> AND AllValues<) 963 The last example (Figure 11) shows the client adds two Observe 964 request messages to build a range, one sets to 6/22, another one sets 965 to 5/16. It means that the range is out of range between 16 and 22, 966 i.e. value > 22 OR value < 16. This requires two messages, since it 967 is the OR option, which is defined with multiple observe messages. 968 An example of the application for this option can be found in the 969 implementation of the conditional observer [SENSORS]. 971 CLIENT SERVER 972 | | 973 | GET/temperature, observe:0,Condition:6/22 (PORT X) ---> | 974 | GET/temperature, observe:0,Condition:5/16 (PORT Y) ---> | 975 | | 976 | | 977 | |18 978 | | 979 | <------ 2.05Content,observe:10,payload:22,5 |22.5 980 | | 981 | <------ 2.05Content,observe:20,payload:23.2 |23.2 982 | | 983 | |19 984 | | 985 | <------ 2.05Content,observe:35,payload:15 |15 987 Figure 11: Two Observe requests to define out-side a range 988 6/22 OR 5/15 (Allvalues> OR Allvalues<) 990 Further, in [CPSCOM], an evaluation can be found regarding the 991 feasibility of implementing conditional observations on real 992 constrained devices, together with a basic performance comparison 993 between conditional observe (server-filtering) and normal observe in 994 combination with client-side filtering. 996 9. Security Considerations 998 As the Condition Option is used together with the Observe option, 999 when it is used it must follow the security considerations as 1000 described in Observe draft [I-D.ietf-core-observe]. 1002 10. IANA Considerations 1004 10.1. Condition option registry 1006 This draft adds the following option numbers to the CoAP Option 1007 Numbers registry of [I-D.ietf-core-coap] 1009 +--------+---------------+----------------+ 1010 | Number | Name | Reference | 1011 +--------+---------------+----------------+ 1012 | 26 | Condition | [RFCXXXX] | 1013 +--------+---------------+----------------+ 1014 | 28 | Keep-alive | [RFCXXXX] | 1015 +--------+---------------+----------------+ 1016 Table 3: Condition and Keep-alive Option number 1018 10.2. Condition type registry 1020 The Condition types defined in this draft are identified by a string, 1021 such as "Step". In order to minimize the overhead of using these 1022 condition types, this document defines a registry for the condition 1023 types to be used in CoAP and assigns each a numeric identifier. 1025 Each entry in the registry must include the condition type registered 1026 with IANA, the numeric identifier in the range 0-31 to be used for 1027 that condition type in CoAP, and a reference to a document defining 1028 the usage of that condition type. 1030 Initial entries in this registry are as follows: 1032 +-----------------------+------+-----------+ 1033 | Condition type | Id. | Reference | 1034 +-----------------------+------+-----------+ 1035 | Cancellation | 0 | [RFCXXXX] | 1036 +-----------------------+------+-----------+ 1037 | Time series | 1 | [RFCXXXX] | 1038 +-----------------------+------+-----------+ 1039 | Minimum response time | 2 | [RFCXXXX] | 1040 +-----------------------+------+-----------+ 1041 | Maximum response time | 3 | [RFCXXXX] | 1042 +-----------------------+------+-----------+ 1043 | Step | 4 | [RFCXXXX] | 1044 +-----------------------+------+-----------+ 1045 | AllValues< | 5 | [RFCXXXX] | 1046 +-----------------------+------+-----------+ 1047 | AllValues> | 6 | [RFCXXXX] | 1048 +-----------------------+------+-----------+ 1049 | Value= | 7 | [RFCXXXX] | 1050 +-----------------------+------+-----------+ 1051 | Threshold | 8 | [RFCXXXX] | 1052 +-----------------------+------+-----------+ 1053 | Periodic | 9 | [RFCXXXX] | 1054 +-----------------------+------+-----------+ 1056 Table 5: Condition Option type 1058 11. Further considerations 1060 Intermediaries, caching, retransmissions 1062 12. Acknowledgements 1064 Thanks to the IoT6 European Project (STREP) of the 7th Framework 1065 Program (Grant 288445). 1067 13. Normative References 1069 [CPSCOM] Ketema, G., Hoebeke, J., Moerman, I., Demeester, P., Li, 1070 Shi., and A. Jara, "Efficiently observing Internet of 1071 Things Resources", The 2012 IEEE International Conference 1072 on Cyber, Physical and Social Computing November 20-23, 1073 2012, Besancon, France, Novemer 2012. 1075 [I-D.bormann-coap-misc] 1076 Bormann, C. and K. Hartke, "Miscellaneous additions to 1077 CoAP", draft-bormann-coap-misc-13 (work in progress), 1078 March 2012. 1080 [I-D.ietf-core-coap] 1081 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1082 Application Protocol (CoAP)", draft-ietf-core-coap-17 1083 (work in progress), May 2013. 1085 [I-D.ietf-core-link-format] 1086 Shelby, Z., "CoRE Link Format", draft-ietf-core-link- 1087 format-14 (work in progress), June 2012. 1089 [I-D.ietf-core-observe] 1090 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1091 core-observe-08 (work in progress), February 2013. 1093 [I-D.shelby-core-interfaces] 1094 Shelby, Z. and M. Vial, "CoRE Interfaces", draft-shelby- 1095 core-interfaces-05 (work in progress), March 2013. 1097 [OMADM] Alliance, OMA., "Lightweight Machine to Machine Technical 1098 Specification", OMA-TS-LightweightM2M-V1_0-20130301-D Open 1099 Mobile Alliance (OMA), March 2013. 1101 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1102 Requirement Levels", BCP 14, RFC 2119, March 1997. 1104 [SENSORS] Castro, M., Jara, A., and A. Skarmeta, "Architecture for 1105 Improving Terrestrial Logistics Based on the Web of 1106 Things", Sensors 12, no. 5, 6538-6575, 2012, May 2012. 1108 Appendix A. OMA Information Reporting with CoAP Conditional Observe 1109 The Open Mobile Alliance (OMA) has defined the Lightweight Machine to 1110 Machine (LWM2M) Technical Specification [OMADM]. This specification 1111 uses CoAP as the transport for the device management in terms of 1112 registration, service discovery, bootstrapping, service enablement, 1113 and information reporting. 1115 Information reporting presents a similar philosophy that CoAP 1116 conditional observe. In details, it is defined for the periodic 1117 reporting of data, or an event-triggered reporting based on changes 1118 in some of the resource values. 1120 Information reporting allows to send an Observe GET request for an 1121 Object Instance (Objects is the organization of resources in OMA 1122 LWM2M), which results in asynchronous notifications whenever that 1123 Object Instance changes (periodically or as a result of an event). 1124 The minimum and maximum period of notifications can be controlled by 1125 including the minimum (pmin) and/or maximum (pmax) period for 1126 notifications to be sent in seconds. 1128 An example of the logical operation defined by OMA LWM2M is a GET 1129 with Observe option: 1131 /{Object ID}/{Object Instance ID}/{Resource ID} 1132 ?pmin={minimum period}&pmax={maximum period} 1134 The answer is a 2.05 Content with Observe option, 4.00 Bad Request, 1135 4.04 Not Found, 4.05 Method Not Allowed, or in case of Asynchronous 1136 Response 2.04 Changed. 1138 Note, that the resources are logically organized into Objects. 1139 Thereby, multiple resources are defined per Object, and each resource 1140 is given a unique identifier within that Object. Each Resource is 1141 defined to have one or more Operations that it supports. A Resource 1142 MAY contain multiple instances as defined in Object specification. 1143 An Object defines a grouping of Resources. Object MUST be 1144 instantiated, which is called Object Instance before using the 1145 functionality of an Object. After Object Instance is created, that 1146 Object Instance and Resources which belong to that Object Instance. 1147 As a result, it is required to reference the Object ID, Object 1148 Instance ID, and finally Resource ID. 1150 The operations defined for the information reporting interface are: 1151 observe, notify, and cancel observation. 1153 First, the observe interface, following the OMA LWM2M requirements, 1154 needs to define the Minimum and Maximum period parameters. 1156 Minimum period indicates the minimum time in seconds the device 1157 SHOULD wait between sending a new notification. 1159 Maximum period indicated the maximum time in seconds the device 1160 SHOULD wait between sending the next notification (regardless if the 1161 value has changed). 1163 These options correspond with the Minimum response time (option 2), 1164 and Maximum response time (option 3) of the presented Conditional 1165 Observe. 1167 Second, the cancel observation interface of the OMA LWM2M for the 1168 information reporting corresponds with the Cancellation (option 0). 1170 Finally, the notification interface is similar. 1172 Therefore, OMA LWM2M Information Reporting can be implemented with 1173 the Conditional Observe. In addition, Conditional Observe offers a 1174 set of extra features in order to set up more complex logic for the 1175 observation (subscription). 1177 The main difference and advantage of using Conditional Observe is 1178 that the minimum and maximum period options will be defined as part 1179 of the condition, since they are two options offered by conditional 1180 observe. Thereby, it is not required the definition of minimum and 1181 maximum period by parameters (i.e., using the ?pmin={minimum period} 1182 and pmax={maximum period}). 1184 The Figure 12 presents an example to conditional observe the OMA 1185 Object 106 (which is an IPSO Sensor), Object instance 0, and the 1186 resource ID 4 (which is, for this example, a temperature value). 1187 This carries out a registration with a minium period of 30 seconds 1188 and a maximum period of 120 seconds. 1190 CLIENT SERVER 1191 | | 1192 | GET /106/0/4 observe:0,Condition:2/30, | 1193 | Condition:3/120 ----->| 1194 | | 1195 | <------ 2.05Content,observe:0,payload:4 (Sucess) 4|1s 1196 | | 1197 | 3|5s 1198 | | 1199 | 3|10s 1200 | | 1201 | <------ 2.04 Changed,observe:15,payload:12 (Notify) 12|15s 1202 | | 1203 | 16|20s 1204 | | 1205 | <------ 2.04 Changed,,observe:25,payload:14 (Notify) 14|25s 1207 Figure 12: Example of conditional observe following the 1208 OMA LWM2M Information Reporting requirement. 1209 This example is observing the OMA Object 106, 1210 Object Instance ID 0, and Resource ID 4. 1211 This is defining a minimum period of 30 seconds 1212 and maximum period of 120 seconds. 1214 Appendix B. Alternative approaches 1216 In this appendix, we include some alternative solutions the authors 1217 have discussed regarding cancellation of relationships and the 1218 logical combination of different relationships. The mechanisms 1219 described here allow more flexibility, but introduce additional 1220 (undesired?) complexity. We put their description in this appendix 1221 to trigger further discussion and provide more background. 1223 B.1. Annex: Cancellation flag 1225 An alternative way to allow the explicit establishment and removal of 1226 conditional relationships and to allow the establishment of multiple 1227 conditional relationships to the same server using the same source 1228 transport address, is through the introduction of a 1 bit 1229 cancellation flag (C) as part of the 1 byte condition header. The 1230 following paragraphs describe how this flag would change this 1231 behaviour. 1233 C: The cancellation flag, when used in an observe request, indicates 1234 whether the client wants to establish a conditional observation 1235 relationship (0) or cancel an existing conditional relationship (1). 1236 In the initial response, the server uses the same value as in the 1237 request. In all further notifications, this flag has no meaning and 1238 must be 0. In case of a request containing multiple Condition 1239 Options, the client must use the same value of the C flag in all 1240 Condition Options. The cancellation flag allows a client to 1241 establish multiple conditional observation relationships and remove 1242 individual relationships from the same address and port. 1244 When using this cancellation flag, a client is able to establish 1245 multiple conditional relationships using the same source transport 1246 address. Different from [I-D.ietf-core-observe] a GET without 1247 observe issued by a client, will not result in the removal of 1248 established conditional relationships. Instead the client has the 1249 possibility to explicitly terminate any established conditional 1250 relationship by sending the same observe request, but with the 1251 Condition Option having the C flag set in order to trigger the 1252 cancellation of the request. This way, the same end point can manage 1253 multiple conditional observation relationships without the risk of 1254 accidentally removing them. 1256 When a server receives a cancellation request, it removes the 1257 relationship indicated by the Condition Option and sends back a 1258 response containing both the Observe and the Condition Option with 1259 the cancellation flag set to 1. 1261 In case a client wants to terminate all existing conditional 1262 observation relationships with a server, it should send a request 1263 with Condition Option, where the Condition Type is set to the 1264 reserved value 0 and the cancellation flag to 1. Upon reception of 1265 this message, the server removes all existing relationships and sends 1266 back a response containing the same Condition Type. 1268 In case a client has established a conditional relationship that is 1269 the result of a request with multiple Condition Options, the client 1270 can cancel this relationship by sending the same request, but now 1271 with all cancellation flags set to 1. 1273 If the server is for whatever reason not able to further fulfil the 1274 conditional relationship of a client, the server can also send a 1275 confirmable notification containing the Condition Option with the C 1276 flag set to 1 in order to terminate the observation relationship. 1278 B.2. Annex: Logic flag 1280 Different condition types can be combined in a request to express a 1281 logical AND relationship. By default, logical OR of condition types 1282 is always supported through sending separate requests. In order to 1283 express an out-of-range condition (notification when value is lower 1284 than X OR higher than Y), two separate conditional observe requests 1285 have to be sent. Through the introduction of a 1 bit logic flag (L) 1286 as part of the 1 byte condition header, this can be avoided. 1288 L: The logic flag in a Condition Option indicates how the condition 1289 should be combined logically with the condition in the next Condition 1290 Option. A value of 0 means AND and a value of 1 means OR. The flag 1291 has no meaning if the Condition Option is the only or last Condition 1292 Option in the request. Through the use of the L flag it is possible 1293 to logically combine different conditions in a single request (e.g. 1294 C1 AND C2 OR C3 AND C4). As a drawback, when used, it complicates 1295 processing at the server side. 1297 This example (Figure 12) shows the same example from the (Figure 11) 1298 but with this alternative. This example presents as the client adds 1299 two Observe options to build a range, one set to 6/22, another one 1300 set to 5/16. It means that the range is out of range between 16 and 1301 22, i.e. value > 22 OR value < 16. The first option is defined by 1302 default with the Logic flag equal to 0. The second option is defined 1303 with the Logic flag equal to 1, since it is the OR option. Note as 1304 it has been simplified from two messages to only one message with two 1305 options, and the most important, it has avoided the management of 1306 multiple ports. 1308 CLIENT SERVER 1309 | | 1310 | GET/temperature, observe:0,Condition:6/22 (L=0) ---> | 1311 | condition:5/16 (L=1) ---> | 1312 | | 1313 | | 1314 | |18 1315 | | 1316 | <------ 2.05Content,observe:10,payload:22,5 |22.5 1317 | | 1318 | <------ 2.05Content,observe:20,payload:23.2 |23.2 1319 | | 1320 | |19 1321 | | 1322 | <------ 2.05Content,observe:35,payload:15 |15 1324 Figure 13: Two Observe options with Logic flag to define 1325 out-side a range 6/22 OR 5/15. 1327 Appendix C. Change log 1329 Changes in v04 1331 o Updated draft to be consistent with updated observe draft: 1333 * Took request URI into consideration for Cancellation. 1335 * Explicitly stated that the timing conditions allow a client to 1336 use a representation that is older than Max-Age without 1337 verifying the representation first. This collides with a MUST 1338 NOT from the observe draft. 1340 * Stated that a server should follow the text from the observe 1341 draft for an unacknowledged notification in regards to the 1342 transmission of new notifications and the cancellation of 1343 existing relationships. 1345 o Added section 2.1 comparing the RESTful approach from draft- 1346 shelby-core-interfaces to our approach for conditional 1347 observations. 1349 o Clarified why "AND" semantics are preferred over "OR" semantics in 1350 case of multiple Condition options. 1352 o Clarified that the R flag doesn't violate the behaviour defined in 1353 the Observe draft. 1355 o Clarified that a client might opt to use representations older 1356 than Max-Age without validating these first in case of most of the 1357 timing conditions. A server has the ability to deny the client 1358 this sort of behaviour however. 1360 o Updated source endpoint terminology. 1362 Changes in v03 1364 o Examples for most condition types 1366 o Update the option number according to the new numbering scheme 1368 o Added reference to paper validating implementation on constrained 1369 device 1371 Changes in v02 1373 o Restructured entire document 1375 o Detailed description of the Condition Option and updated format of 1376 the Condition Option value 1378 o Added more Condition Types 1380 o New section on cancellation, updating and existence of conditional 1381 relationships 1383 o New section on discovery 1385 Authors' Addresses 1386 Shitao Li 1387 Huawei Technologies 1388 Huawei Base 1389 101 Software Avenue, Yuhua District 1390 Nanjing, Jiangsu 210012 1391 China 1393 Phone: +86-25-56624157 1394 Email: lishitao@huawei.com 1396 Jeroen Hoebeke 1397 iMinds-IBCN/UGent 1398 Department of Information Technology 1399 Internet Based Communication Networks and Services (IBCN) 1400 Ghent University - iMinds 1401 Gaston Crommenlaan 8 bus 201 1402 Ghent B-9050 1403 Belgium 1405 Phone: +32-9-3314954 1406 Email: jeroen.hoebeke@intec.ugent.be 1408 Floris Van den Abeele 1409 iMinds-IBCN/UGent 1410 Department of Information Technology 1411 Internet Based Communication Networks and Services (IBCN) 1412 Ghent University - iMinds 1413 Gaston Crommenlaan 8 bus 201 1414 Ghent B-9050 1415 Belgium 1417 Phone: +32-9-3314946 1418 Email: floris.vandenabeele@intec.ugent.be 1420 Antonio J. Jara 1421 University of Murcia 1422 Department of Information Technology and Communications 1423 Computer Science Faculty 1424 Campus de Espinardo 1425 Murcia ES-30100 1426 Spain 1428 Phone: +34-868-88-8771 1429 Email: jara@um.es