idnits 2.17.1 draft-ietf-core-conditional-attributes-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' TBD IANA Considerations ===================' ) ** There is 1 instance of too long lines in the document, the longest one being 60 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 (July 12, 2021) is 1011 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Koster 3 Internet-Draft SmartThings 4 Intended status: Informational B. Silverajan, Ed. 5 Expires: January 13, 2022 Tampere University 6 July 12, 2021 8 Conditional Attributes for Constrained RESTful Environments 9 draft-ietf-core-conditional-attributes-00 11 Abstract 13 This specification defines Conditional Notification and Control 14 Attributes that work with CoAP Observe (RFC7641). 16 Editor note 18 The git repository for the draft is found at TBD 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 13, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Conditional Attributes . . . . . . . . . . . . . . . . . . . 3 57 3.1. Conditional Notification Attributes . . . . . . . . . . . 3 58 3.1.1. Greater Than (gt) . . . . . . . . . . . . . . . . . . 4 59 3.1.2. Less Than (lt) . . . . . . . . . . . . . . . . . . . 4 60 3.1.3. Change Step (st) . . . . . . . . . . . . . . . . . . 5 61 3.1.4. Notification Band (band) . . . . . . . . . . . . . . 5 62 3.1.5. Edge (edge) . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Conditional Control Attributes . . . . . . . . . . . . . 6 64 3.2.1. Minimum Period (pmin) . . . . . . . . . . . . . . . . 7 65 3.2.2. Maximum Period (pmax) . . . . . . . . . . . . . . . . 7 66 3.2.3. Minimum Evaluation Period (epmin) . . . . . . . . . . 8 67 3.2.4. Maximum Evaluation Period (epmax) . . . . . . . . . . 8 68 3.2.5. Confirmable Notification (con) . . . . . . . . . . . 8 69 3.3. Server processing of Conditional Attributes . . . . . . . 8 70 4. Implementation Considerations . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 79 A.1. Minimum Period (pmin) example . . . . . . . . . . . . . . 12 80 A.2. Maximum Period (pmax) example . . . . . . . . . . . . . . 13 81 A.3. Greater Than (gt) example . . . . . . . . . . . . . . . . 14 82 A.4. Greater Than (gt) and Period Max (pmax) example . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 IETF Standards for machine to machine communication in constrained 88 environments describe a REST protocol [RFC7252] and a set of related 89 information standards that may be used to represent machine data and 90 machine metadata in REST interfaces. 92 This specification defines Conditional Notification and Control 93 Attributes for use with CoRE Observe [RFC7641]. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in 100 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 This specification requires readers to be familiar with all the terms 104 and concepts that are discussed in [RFC7641]. This specification 105 makes use of the following additional terminology: 107 Notification Band: A resource value range that may be bounded by a 108 minimum and maximum value or may be unbounded having either a 109 minimum or maximum value. 111 3. Conditional Attributes 113 This specification defines conditional attributes, which provide for 114 fine-grained control of notification and state synchronization when 115 using CoRE Observe [RFC7641]. When resource interfaces following 116 this specification are made available over CoAP, the CoAP Observation 117 mechanism [RFC7641] MAY also be used to observe any changes in a 118 resource, and receive asynchronous notifications as a result. A 119 resource marked as Observable in its link description SHOULD support 120 these conditional attributes. 122 Note: In this draft, we assume that there are finite quantization 123 effects in the internal or external updates to the value representing 124 the state of a resource; specifically, that a resource state may be 125 updated at any time with any valid value. We therefore avoid any 126 continuous-time assumptions in the description of the conditional 127 attributes and instead use the phrase "sampled value" to refer to a 128 member of a sequence of values that may be internally observed from 129 the resource state over time. 131 3.1. Conditional Notification Attributes 133 Conditional Notification Attributes define the conditions that 134 trigger a notification. Conditional Notification Attributes SHOULD 135 be evaluated on all potential notifications from a resource, whether 136 resulting from an internal server-driven sampling process or from 137 external update requests to the server. 139 The set of Conditional Notification Attributes defined here allow a 140 client to control how often a client is interested in receiving 141 notifications and how much a value should change for the new 142 representation state to be interesting. One or more Conditional 143 Notification Attributes MAY be included as query parameters in an 144 Observe request. 146 Conditional Notification Attributes are defined below: 148 +-------------------+-----------+-----------------+ 149 | Attribute | Parameter | Value | 150 +-------------------+-----------+-----------------+ 151 | Greater Than | gt | xs:decimal | 152 | | | | 153 | Less Than | lt | xs:decimal | 154 | | | | 155 | Change Step | st | xs:decimal (>0) | 156 | | | | 157 | Notification Band | band | xs:boolean | 158 | | | | 159 | Edge | edge | xs:boolean | 160 +-------------------+-----------+-----------------+ 162 Table 1: Conditional Notification Attributes 164 3.1.1. Greater Than (gt) 166 When present, Greater Than indicates the upper limit value the 167 sampled value SHOULD cross before triggering a notification. A 168 notification is sent whenever the sampled value crosses the specified 169 upper limit value, relative to the last reported value, and the time 170 fpr pmin has elapsed since the last notification. The sampled value 171 is sent in the notification. If the value continues to rise, no 172 notifications are generated as a result of gt. If the value drops 173 below the upper limit value then a notification is sent, subject 174 again to the pmin time. 176 The Greater Than parameter can only be supported on resources with a 177 scalar numeric value. 179 3.1.2. Less Than (lt) 181 When present, Less Than indicates the lower limit value the resource 182 value SHOULD cross before triggering a notification. A notification 183 is sent when the samples value crosses the specified lower limit 184 value, relative to the last reported value, and the time fpr pmin has 185 elapsed since the last notification. The sampled value is sent in 186 the notification. If the value continues to fall no notifications 187 are generated as a result of lt. If the value rises above the lower 188 limit value then a new notification is sent, subject to the pmin 189 time. 191 The Less Than parameter can only be supported on resources with a 192 scalar numeric value. 194 3.1.3. Change Step (st) 196 When present, the change step indicates how much the value 197 representing a resource state SHOULD change before triggering a 198 notification, compared to the old state. Upon reception of a query 199 including the st attribute, the current resource state representing 200 the most recently sampled value is reported, and then set as the last 201 reported value (last_rep_v). When a subsequent sampled value or 202 update of the resource state differs from the last reported state by 203 an amount, positive or negative, greater than or equal to st, and the 204 time for pmin has elapsed since the last notification, a notification 205 is sent and the last reported value is updated to the new resource 206 state sent in the notification. The change step MUST be greater than 207 zero otherwise the receiver MUST return a CoAP error code 4.00 "Bad 208 Request" (or equivalent). 210 The Change Step parameter can only be supported on resource states 211 represented with a scalar numeric value. 213 Note: Due to sampling and other constraints, e.g. pmin, the change in 214 resource states received in two sequential notifications may differ 215 by more than st. 217 3.1.4. Notification Band (band) 219 The notification band attribute allows a bounded or unbounded (based 220 on a minimum or maximum) value range that may trigger multiple 221 notifications. This enables use cases where different ranges results 222 in differing behaviour. For example, in monitoring the temperature 223 of machinery, whilst the temperature is in the normal operating 224 range, only periodic updates are needed. However as the temperature 225 moves to more abnormal ranges more frequent state updates may be sent 226 to clients. 228 Without a notification band, a transition across a less than (lt), or 229 greater than (gt) limit only generates one notification. This means 230 that it is not possible to describe a case where multiple 231 notifications are sent so long as the limit is exceeded. 233 The band attribute works as a modifier to the behaviour of gt and lt. 234 Therefore, if band is present in a query, gt, lt or both, MUST be 235 included. 237 When band is present with the lt attribute, it defines the lower 238 bound for the notification band (notification band minimum). 240 Notifications occur when the resource value is equal to or above the 241 notification band minimum. If lt is not present there is no minimum 242 value for the band. 244 When band is present with the gt attribute, it defines the upper 245 bound for the notification band (notification band maximum). 246 Notifications occur when the resource value is equal to or below the 247 notification band maximum. If gt is not present there is no maximum 248 value for the band. 250 If band is present with both the gt and lt attributes, notification 251 occurs when the resource value is greater than or equal to gt or when 252 the resource value is less than or equal to lt. 254 If a band is specified in which the value of gt is less than that of 255 lt, in-band notification occurs. That is, notification occurs 256 whenever the resource value is between the gt and lt values, 257 including equal to gt or lt. 259 If the band is specified in which the value of gt is greater than 260 that of lt, out-of-band notification occurs. That is, notification 261 occurs when the resource value not between the gt and lt values, 262 excluding equal to gt and lt. 264 The Notification Band parameter can only be supported on resources 265 with a scalar numeric value. 267 3.1.5. Edge (edge) 269 When present, the Edge attribute indicates interest for receiving 270 notifications of either the falling edge or the rising edge 271 transition of a boolean resource state. When the value of the Edge 272 attribute is 0, the server notifies the client each time a resource 273 state changes from True to False. When the value of the Edge 274 attribute is 1, the server notifies the client each time a resource 275 state changes from False to True. 277 The Edge attribute can only be supported on resources with a boolean 278 value. 280 3.2. Conditional Control Attributes 282 Conditional Control Attributes define the time intervals between 283 consecutive notifications as well as the cadence of the measurement 284 of the conditions that trigger a notification. Conditional Control 285 Attributes can be used to configure the internal server-driven 286 sampling process for performing measurements of the conditions of a 287 resource. One or more Conditional Control Attributes MAY be included 288 as query parameters in an Observe request. 290 Conditional Control Attributes are defined below: 292 +-------------------------------+-----------+-----------------+ 293 | Attribute | Parameter | Value | 294 +-------------------------------+-----------+-----------------+ 295 | Minimum Period (s) | pmin | xs:decimal (>0) | 296 | | | | 297 | Maximum Period (s) | pmax | xs:decimal (>0) | 298 | | | | 299 | Minimum Evaluation Period (s) | epmin | xs:decimal (>0) | 300 | | | | 301 | Maximum Evaluation Period (s) | epmax | xs:decimal (>0) | 302 | | | | 303 | Confirmable Notification | con | xs:boolean | 304 +-------------------------------+-----------+-----------------+ 306 Table 2: Conditional Control Attributes 308 3.2.1. Minimum Period (pmin) 310 When present, the minimum period indicates the minimum time, in 311 seconds, between two consecutive notifications (whether or not the 312 resource state has changed). In the absence of this parameter, the 313 minimum period is up to the server. The minimum period MUST be 314 greater than zero otherwise the receiver MUST return a CoAP error 315 code 4.00 "Bad Request" (or equivalent). 317 A server MAY update the resource state with the last sampled value 318 that occured during the pmin interval, after the pmin interval 319 expires. 321 Note: Due to finite quantization effects, the time between 322 notifications may be greater than pmin even when the sampled value 323 changes within the pmin interval. Pmin may or may not be used to 324 drive the internal sampling process. 326 3.2.2. Maximum Period (pmax) 328 When present, the maximum period indicates the maximum time, in 329 seconds, between two consecutive notifications (whether or not the 330 resource state has changed). In the absence of this parameter, the 331 maximum period is up to the server. The maximum period MUST be 332 greater than zero and MUST be greater than, or equal to, the minimum 333 period parameter (if present) otherwise the receiver MUST return a 334 CoAP error code 4.00 "Bad Request" (or equivalent). 336 3.2.3. Minimum Evaluation Period (epmin) 338 When present, the minimum evaluation period indicates the minimum 339 time, in seconds, the client recommends to the server to wait between 340 two consecutive measurements of the conditions of a resource since 341 the client has no interest in the server doing more frequent 342 measurements. When the minimum evaluation period expires after the 343 previous measurement, the server MAY immediately perform a new 344 measurement. In the absence of this parameter, the minimum 345 evaluation period is not defined and thus not used by the server. 346 The server MAY use pmin, if defined, as a guidance on the desired 347 measurement cadence. The minimum evaluation period MUST be greater 348 than zero otherwise the receiver MUST return a CoAP error code 4.00 349 "Bad Request" (or equivalent). 351 3.2.4. Maximum Evaluation Period (epmax) 353 When present, the maximum evaluation period indicates the maximum 354 time, in seconds, the server MAY wait between two consecutive 355 measurements of the conditions of a resource. When the maximum 356 evaluation period expires after the previous measurement, the server 357 MUST immediately perform a new measurement. In the absence of this 358 parameter, the maximum evaluation period is not defined and thus not 359 used by the server. The maximum evaluation period MUST be greater 360 than zero and MUST be greater than the minimum evaluation period 361 parameter (if present) otherwise the receiver MUST return a CoAP 362 error code 4.00 "Bad Request" (or equivalent). 364 3.2.5. Confirmable Notification (con) 366 When present with a value of 1 in a query, the con attribute 367 indicates a notification MUST be confirmable, i.e., the server MUST 368 send the notification in a confirmable CoAP message, to request an 369 acknowledgement from the client. When present with a value of 0 in a 370 query, the con attribute indicates a notification can be confirmable 371 or non-confirmable, i.e., it can be sent in a confirmable or a non- 372 confirmable CoAP message. 374 3.3. Server processing of Conditional Attributes 376 Conditional Notification Attributes and Conditional Control 377 Attributes may be present in the same query. However, they are not 378 defined at multiple prioritization levels. The server sends a 379 notification whenever any of the parameter conditions are met, upon 380 which it updates its last notification value and time to prepare for 381 the next notification. Only one notification occurs when there are 382 multiple conditions being met at the same time. The reference code 383 below illustrates the logic to determine when a notification is to be 384 sent. 386 bool notifiable( Resource * r ) { 388 #define BAND r->band 389 #define SCALAR_TYPE ( num_type == r->type ) 390 #define STRING_TYPE ( str_type == r->type ) 391 #define BOOLEAN_TYPE ( bool_type == r->type ) 392 #define PMIN_EX ( r->last_sample_time - r->last_rep_time >= r->pmin ) 393 #define PMAX_EX ( r->last_sample_time - r->last_rep_time > r->pmax ) 394 #define LT_EX ( r->v < r->lt ^ r->last_rep_v < r->lt ) 395 #define GT_EX ( r->v > r->gt ^ r->last_rep_v > r->gt ) 396 #define ST_EX ( abs( r->v - r->last_rep_v ) >= r->st ) 397 #define IN_BAND ( ( r->gt <= r->v && r->v <= r->lt ) || ( r->lt <= r->gt && r->gt <= r->v ) || ( r->v <= r->lt && r->lt <= r->gt ) ) 398 #define VB_CHANGE ( r->vb != r->last_rep_vb ) 399 #define VS_CHANGE ( r->vs != r->last_rep_vs ) 401 return ( 402 PMIN_EX && 403 ( SCALAR_TYPE ? 404 ( ( !BAND && ( GT_EX || LT_EX || ST_EX || PMAX_EX ) ) || 405 ( BAND && IN_BAND && ( ST_EX || PMAX_EX) ) ) 406 : STRING_TYPE ? 407 ( VS_CHANGE || PMAX_EX ) 408 : BOOLEAN_TYPE ? 409 ( VB_CHANGE || PMAX_EX ) 410 : false ) 411 ); 412 } 414 Figure 1: Code logic for conditional notification attribute 415 interactions 417 4. Implementation Considerations 419 When pmax and pmin are equal, the expected behaviour is that 420 notifications will be sent every (pmin == pmax) seconds. However, 421 these notifications can only be fulfilled by the server on a best 422 effort basis. Because pmin and pmax are designed as acceptable 423 tolerance bounds for sending state updates, a query from an 424 interested client containing equal pmin and pmax values must not be 425 seen as a hard real-time scheduling contract between the client and 426 the server. 428 When using multiple resource bindings (e.g. multiple Observations of 429 resource) with different bands, consideration should be given to the 430 resolution of the resource value when setting sequential bands. For 431 example: Given BandA (Abmn=10, Bbmx=20) and BandB (Bbmn=21, Bbmx=30). 432 If the resource value returns an integer then notifications for 433 values between and inclusive of 10 and 30 will be triggered. Whereas 434 if the resolution is to one decimal point (0.1) then notifications 435 for values 20.1 to 20.9 will not be triggered. 437 The use of the notification band minimum and maximum allow for a 438 synchronization whenever a change in the resource value occurs. 439 Theoretically this could occur in-line with the server internal 440 sample period or the configuration of epmin and epmax values for 441 determining the resource value. Implementors SHOULD consider the 442 resolution needed before updating the resource, e.g. updating the 443 resource when a temperature sensor value changes by 0.001 degree 444 versus 1 degree. 446 When a server has multiple observations with different measurement 447 cadences as defined by the epmin and epmax values, the server MAY 448 evaluate all observations when performing the measurement of any one 449 observation. 451 5. Security Considerations 453 TBD IANA Considerations =================== 455 TBD 457 6. Acknowledgements 459 Hannes Tschofenig and Mert Ocak highlighted syntactical corrections 460 in the usage of pmax and pmin in a query. Alan Soloway contributed 461 text leading to the inclusion of epmin and epmax. David Navarro 462 proposed allowing for pmax to be equal to pmin. 464 7. Contributors 465 Christian Groves 466 Australia 467 email: cngroves.std@gmail.com 469 Zach Shelby 470 ARM 471 Vuokatti 472 FINLAND 473 phone: +358 40 7796297 474 email: zach.shelby@arm.com 476 Matthieu Vial 477 Schneider-Electric 478 Grenoble 479 France 480 phone: +33 (0)47657 6522 481 eMail: matthieu.vial@schneider-electric.com 483 Jintao Zhu 484 Huawei 485 Xi'an, Shaanxi Province 486 China 487 email: jintao.zhu@huawei.com 489 8. Changelog 491 draft-ietf-core-conditional-attributes-00 493 o Conditional Atttributes section from draft-ietf-core-dynlink-13 494 separated into own WG draft 496 9. References 498 9.1. Normative References 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, 502 DOI 10.17487/RFC2119, March 1997, 503 . 505 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 506 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 507 May 2017, . 509 9.2. Informative References 511 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 512 Application Protocol (CoAP)", RFC 7252, 513 DOI 10.17487/RFC7252, June 2014, 514 . 516 [RFC7641] Hartke, K., "Observing Resources in the Constrained 517 Application Protocol (CoAP)", RFC 7641, 518 DOI 10.17487/RFC7641, September 2015, 519 . 521 Appendix A. Examples 523 This appendix provides some examples of the use of binding attribute 524 / observe attributes. 526 Note: For brevity the only the method or response code is shown in 527 the header field. 529 A.1. Minimum Period (pmin) example 530 Observed CLIENT SERVER Actual 531 t State | | State 532 ____________ | | ____________ 533 1 | | 534 2 unknown | | 18.5 Cel 535 3 +----->| Header: GET 536 4 | GET | Token: 0x4a 537 5 | | Uri-Path: temperature 538 6 | | Uri-Query: pmin="10" 539 7 | | Observe: 0 (register) 540 8 | | 541 9 ____________ |<-----+ Header: 2.05 542 10 | 2.05 | Token: 0x4a 543 11 18.5 Cel | | Observe: 9 544 12 | | Payload: "18.5 Cel" 545 13 | | ____________ 546 14 | | 547 15 | | 23 Cel 548 16 | | 549 17 | | 550 18 | | 551 19 | | ____________ 552 20 ____________ |<-----+ Header: 2.05 553 21 | 2.05 | 26 Cel Token: 0x4a 554 22 26 Cel | | Observe: 20 555 23 | | Payload: "26 Cel" 556 24 | | 557 25 | | 559 Figure 2: Client registers and receives one notification of the 560 current state and one of a new state state when pmin time expires. 562 A.2. Maximum Period (pmax) example 564 Observed CLIENT SERVER Actual 565 t State | | State 566 ____________ | | ____________ 567 1 | | 568 2 unknown | | 18.5 Cel 569 3 +----->| Header: GET 570 4 | GET | Token: 0x4a 571 5 | | Uri-Path: temperature 572 6 | | Uri-Query: pmax="20" 573 7 | | Observe: 0 (register) 574 8 | | 575 9 ____________ |<-----+ Header: 2.05 576 10 | 2.05 | Token: 0x4a 577 11 18.5 Cel | | Observe: 9 578 12 | | Payload: "18.5 Cel" 579 13 | | 580 14 | | 581 15 | | ____________ 582 16 ____________ |<-----+ Header: 2.05 583 17 | 2.05 | 23 Cel Token: 0x4a 584 18 23 Cel | | Observe: 16 585 19 | | Payload: "23 Cel" 586 20 | | 587 21 | | 588 22 | | 589 23 | | 590 24 | | 591 25 | | 592 26 | | 593 27 | | 594 28 | | 595 29 | | 596 30 | | 597 31 | | 598 32 | | 599 33 | | 600 34 | | 601 35 | | 602 36 | | ____________ 603 37 ____________ |<-----+ Header: 2.05 604 38 | 2.05 | 23 Cel Token: 0x4a 605 39 23 Cel | | Observe: 37 606 40 | | Payload: "23 Cel" 607 41 | | 608 42 | | 610 Figure 3: Client registers and receives one notification of the 611 current state, one of a new state and one of an unchanged state when 612 pmax time expires. 614 A.3. Greater Than (gt) example 615 Observed CLIENT SERVER Actual 616 t State | | State 617 ____________ | | ____________ 618 1 | | 619 2 unknown | | 18.5 Cel 620 3 +----->| Header: GET 621 4 | GET | Token: 0x4a 622 5 | | Uri-Path: temperature 623 6 | | Uri-Query: gt=25 624 7 | | Observe: 0 (register) 625 8 | | 626 9 ____________ |<-----+ Header: 2.05 627 10 | 2.05 | Token: 0x4a 628 11 18.5 Cel | | Observe: 9 629 12 | | Payload: "18.5 Cel" 630 13 | | 631 14 | | 632 15 | | ____________ 633 16 ____________ |<-----+ Header: 2.05 634 17 | 2.05 | 26 Cel Token: 0x4a 635 18 26 Cel | | Observe: 16 636 29 | | Payload: "26 Cel" 637 20 | | 638 21 | | 640 Figure 4: Client registers and receives one notification of the 641 current state and one of a new state when it passes through the 642 greater than threshold of 25. 644 A.4. Greater Than (gt) and Period Max (pmax) example 646 Observed CLIENT SERVER Actual 647 t State | | State 648 ____________ | | ____________ 649 1 | | 650 2 unknown | | 18.5 Cel 651 3 +----->| Header: GET 652 4 | GET | Token: 0x4a 653 5 | | Uri-Path: temperature 654 6 | | Uri-Query: pmax=20;gt=25 655 7 | | Observe: 0 (register) 656 8 | | 657 9 ____________ |<-----+ Header: 2.05 658 10 | 2.05 | Token: 0x4a 659 11 18.5 Cel | | Observe: 9 660 12 | | Payload: "18.5 Cel" 661 13 | | 662 14 | | 663 15 | | 664 16 | | 665 17 | | 666 18 | | 667 19 | | 668 20 | | 669 21 | | 670 22 | | 671 23 | | 672 24 | | 673 25 | | 674 26 | | 675 27 | | 676 28 | | 677 29 | | ____________ 678 30 ____________ |<-----+ Header: 2.05 679 31 | 2.05 | 23 Cel Token: 0x4a 680 32 23 Cel | | Observe: 30 681 33 | | Payload: "23 Cel" 682 34 | | 683 35 | | 684 36 | | ____________ 685 37 ____________ |<-----+ Header: 2.05 686 38 | 2.05 | 26 Cel Token: 0x4a 687 39 26 Cel | | Observe: 37 688 40 | | Payload: "26 Cel" 689 41 | | 690 42 | | 692 Figure 5: Client registers and receives one notification of the 693 current state, one when pmax time expires and one of a new state when 694 it passes through the greater than threshold of 25. 696 Authors' Addresses 698 Michael Koster 699 SmartThings 700 665 Clyde Avenue 701 Mountain View 94043 702 USA 704 Email: michael.koster@smartthings.com 705 Bilhanan Silverajan (editor) 706 Tampere University 707 Kalevantie 4 708 Tampere FI-33100 709 Finland 711 Email: bilhanan.silverajan@tuni.fi