idnits 2.17.1 draft-ietf-core-dynlink-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7252], [RFC7641]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 14, 2017) is 2417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group Z. Shelby 3 Internet-Draft ARM 4 Intended status: Informational Z. Vial 5 Expires: March 18, 2018 Schneider-Electric 6 M. Koster 7 SmartThings 8 C. Groves 9 J. Zhu 10 Huawei 11 B. Silverajan, Ed. 12 Tampere University of Technology 13 September 14, 2017 15 Dynamic Resource Linking for Constrained RESTful Environments 16 draft-ietf-core-dynlink-04 18 Abstract 20 For CoAP [RFC7252] Dynamic linking of state updates between 21 resources, either on an endpoint or between endpoints, is defined 22 with the concept of Link Bindings. This specification defines 23 conditional observation attributes that work with Link Bindings or 24 with CoAP Observe [RFC7641]. 26 Editor's note: 28 o The git repository for the draft is found at https://github.com/ 29 core-wg/dynlink 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 18, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Link Bindings . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. Binding Methods . . . . . . . . . . . . . . . . . . . . . 4 69 3.1.1. Polling . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1.2. Observe . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1.3. Push . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Link Relation . . . . . . . . . . . . . . . . . . . . . . 6 73 3.3. Binding Attributes . . . . . . . . . . . . . . . . . . . 6 74 3.3.1. Bind Method (bind) . . . . . . . . . . . . . . . . . 6 75 3.3.2. Minimum Period (pmin) . . . . . . . . . . . . . . . . 6 76 3.3.3. Maximum Period (pmax) . . . . . . . . . . . . . . . . 7 77 3.3.4. Change Step (st) . . . . . . . . . . . . . . . . . . 7 78 3.3.5. Greater Than (gt) . . . . . . . . . . . . . . . . . . 7 79 3.3.6. Less Than (lt) . . . . . . . . . . . . . . . . . . . 7 80 3.3.7. Attribute Interactions . . . . . . . . . . . . . . . 8 81 4. Binding Table . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.1. Binding Interface Description . . . . . . . . . . . . . . 8 83 4.2. Resource Observation Attributes . . . . . . . . . . . . . 9 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 6.1. Interface Description . . . . . . . . . . . . . . . . . . 11 87 6.2. Link Relation Type . . . . . . . . . . . . . . . . . . . 11 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 89 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 9.2. Informative References . . . . . . . . . . . . . . . . . 13 93 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 94 A.1. Greater Than (gt) example . . . . . . . . . . . . . . . . 14 95 A.2. Greater Than (gt) and Period Max (pmax) example . . . . . 14 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Introduction 101 IETF Standards for machine to machine communication in constrained 102 environments describe a REST protocol and a set of related 103 information standards that may be used to represent machine data and 104 machine metadata in REST interfaces. CoRE Link-format is a standard 105 for doing Web Linking [RFC5988] in constrained environments. 107 This specification introduces the concept of a Link Binding, which 108 defines a new link relation type to create a dynamic link between 109 resources over which to exchange state updates. Specifically, a Link 110 Binding is a link for binding the state of 2 resources together such 111 that updates to one are sent over the link to the other. CoRE Link 112 Format representations are used to configure, inspect, and maintain 113 Link Bindings. This specification additionally defines a set of 114 conditional Observe Attributes for use with Link Bindings and with 115 the standalone CoRE Observe [RFC7641] method. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this specification are to be interpreted as described 122 in [RFC2119]. 124 This specification requires readers to be familiar with all the terms 125 and concepts that are discussed in [RFC5988] and [RFC6690]. This 126 specification makes use of the following additional terminology: 128 Link Binding: A unidirectional logical link between a source 129 resource and a destination resource, over which state information 130 is synchronized. 132 State Synchronization: Depending on the binding method (Polling, 133 Observe, Push) different REST methods may be used to synchronize 134 the resource values between a source and a destination. The 135 process of using a REST method to achieve this is defined as 136 "State Synchronization". The endpoint triggering the state 137 synchronization is the synchronization initiator. 139 3. Link Bindings 141 In a M2M RESTful environment, endpoints may directly exchange the 142 content of their resources to operate the distributed system. For 143 example, a light switch may supply on-off control information that 144 may be sent directly to a light resource for on-off control. 146 Beforehand, a configuration phase is necessary to determine how the 147 resources of the different endpoints are related to each other. This 148 can be done either automatically using discovery mechanisms or by 149 means of human intervention and a so-called commissioning tool. In 150 this specification the abstract relationship between two resources is 151 called a link Binding. The configuration phase necessitates the 152 exchange of binding information so a format recognized by all CoRE 153 endpoints is essential. This specification defines a format based on 154 the CoRE Link-Format to represent binding information along with the 155 rules to define a binding method which is a specialized relationship 156 between two resources. The purpose of a binding is to synchronize 157 the content between a source resource and a destination resource. 158 The destination resource MAY be a group resource if the authority 159 component of the destination URI contains a group address (either a 160 multicast address or a name that resolves to a multicast address). 161 Since a binding is unidirectional, the binding entry defining a 162 relationship is present only on one endpoint. The binding entry may 163 be located either on the source or the destination endpoint depending 164 on the binding method. 166 3.1. Binding Methods 168 A binding method defines the rules to generate the web-transfer 169 exchanges that synchronize state between source and destination 170 resources. By using REST methods content is sent from the source 171 resource to the destination resource. 173 The following table gives a summary of the binding methods defined in 174 this specification. 176 +---------+------------+-------------+---------------+ 177 | Name | Identifier | Location | Method | 178 +---------+------------+-------------+---------------+ 179 | Polling | poll | Destination | GET | 180 | | | | | 181 | Observe | obs | Destination | GET + Observe | 182 | | | | | 183 | Push | push | Source | PUT | 184 +---------+------------+-------------+---------------+ 186 Table 1: Binding Method Summary 188 The description of a binding method must define the following 189 aspects: 191 Identifier: This is the value of the "bind" attribute used to 192 identify the method. 194 Location: This information indicates whether the binding entry is 195 stored on the source or on the destination endpoint. 197 REST Method: This is the REST method used in the Request/Response 198 exchanges. 200 Conditions: A binding method definition must state how the condition 201 attributes of the abstract binding definition are actually used in 202 this specialized binding. 204 The binding methods are described in more detail below. 206 3.1.1. Polling 208 The Polling method consists of sending periodic GET requests from the 209 destination endpoint to the source resource and copying the content 210 to the destination resource. The binding entry for this method MUST 211 be stored on the destination endpoint. The destination endpoint MUST 212 ensure that the polling frequency does not exceed the limits defined 213 by the pmin and pmax attributes of the binding entry. The copying 214 process MAY filter out content from the GET requests using value- 215 based conditions (e.g based on the Change Step, Less Than, Greater 216 Than attributes). 218 3.1.2. Observe 220 The Observe method creates an observation relationship between the 221 destination endpoint and the source resource. On each notification 222 the content from the source resource is copied to the destination 223 resource. The creation of the observation relationship requires the 224 CoAP Observation mechanism [RFC7641] hence this method is only 225 permitted when the resources are made available over CoAP. The 226 binding entry for this method MUST be stored on the destination 227 endpoint. The binding conditions are mapped as query string 228 parameters (see Section 4.2). 230 3.1.3. Push 232 When the Push method is assigned to a binding, the source endpoint 233 sends PUT requests to the destination resource when the binding 234 condition attributes are satisfied for the source resource. The 235 source endpoint MUST only send a notification request if the binding 236 conditions are met. The binding entry for this method MUST be stored 237 on the source endpoint. 239 3.2. Link Relation 241 Since Binding involves the creation of a link between two resources, 242 Web Linking and the CoRE Link-Format are a natural way to represent 243 binding information. This involves the creation of a new relation 244 type, named "boundto". In a Web link with this relation type, the 245 target URI contains the location of the source resource and the 246 context URI points to the destination resource. 248 3.3. Binding Attributes 250 Web link attributes allow a fine-grained control of the type of state 251 synchronization along with the conditions that trigger an update. 252 This specification defines the attributes below: 254 +--------------------+-----------+------------------+ 255 | Attribute | Parameter | Value | 256 +--------------------+-----------+------------------+ 257 | Binding method | bind | xsd:string | 258 | | | | 259 | Minimum Period (s) | pmin | xsd:integer (>0) | 260 | | | | 261 | Maximum Period (s) | pmax | xsd:integer (>0) | 262 | | | | 263 | Change Step | st | xsd:decimal (>0) | 264 | | | | 265 | Greater Than | gt | xsd:decimal | 266 | | | | 267 | Less Than | lt | xsd:decimal | 268 +--------------------+-----------+------------------+ 270 Table 2: Binding Attributes Summary 272 3.3.1. Bind Method (bind) 274 This is the identifier of a binding method which defines the rules to 275 synchronize the destination resource. This attribute is mandatory. 277 3.3.2. Minimum Period (pmin) 279 When present, the minimum period indicates the minimum time to wait 280 (in seconds) before triggering a new state synchronization (even if 281 it has changed). In the absence of this parameter, the minimum 282 period is up to the synchronization initiator. The minimum period 283 MUST be greater than zero otherwise the receiver MUST return a CoAP 284 error code 4.00 "Bad Request" (or equivalent). 286 3.3.3. Maximum Period (pmax) 288 When present, the maximum period indicates the maximum time in 289 seconds between two consecutive state synchronizations (regardless if 290 it has changed). In the absence of this parameter, the maximum 291 period is up to the synchronization initiator. The maximum period 292 MUST be greater than zero and MUST be greater than the minimum period 293 parameter (if present) otherwise the receiver MUST return a CoAP 294 error code 4.00 "Bad Request" (or equivalent). 296 3.3.4. Change Step (st) 298 When present, the change step indicates how much the value of a 299 resource SHOULD change before triggering a new state synchronization 300 (compared to the value of the previous synchronization). Upon 301 reception of a query including the st attribute the current value 302 (CurrVal) of the resource is set as the initial value (STinit). Once 303 the resource value differs from the STinit value (i.e. CurrVal >= 304 STinit + ST or CurrVal <= STint - ST) then a new state 305 synchronization occurs. STinit is then set to the state 306 synchronization value and new state synchronizations are based on a 307 change step against this value. The change step MUST be greater than 308 zero otherwise the receiver MUST return a CoAP error code 4.00 "Bad 309 Request" (or equivalent). 311 Note: Due to the state synchronization based update of STint it may 312 result in that resource value received in two sequential state 313 synchronizations differs by more than st. 315 3.3.5. Greater Than (gt) 317 When present, Greater Than indicates the upper limit value the 318 resource value SHOULD cross before triggering a new state 319 synchronization. State synchronization only occurs when the resource 320 value exceeds the specified upper limit value. The actual resource 321 value is used for the synchronization rather than the gt value. If 322 the value continues to rise, no new state synchronizations are 323 generated as a result of gt. If the value drops below the upper 324 limit value and then exceeds the upper limit then a new state 325 synchronization is generated. 327 3.3.6. Less Than (lt) 329 When present, Less Than indicates the lower limit value the resource 330 value SHOULD cross before triggering a new state synchronization. 331 State synchronization only occurs when the resource value is less 332 than the specified lower limit value. The actual resource value is 333 used for the synchronization rather than the lt value. If the value 334 continues to fall no new state synchronizations are generated as a 335 result of lt. If the value rises above the lower limit value and 336 then drops below the lower limit then a new state synchronization is 337 generated. 339 3.3.7. Attribute Interactions 341 Pmin, pmax, st, gt and lt may be present in the same query. 343 If pmin and pmax are present in a query then they take precedence 344 over the other parameters. Thus even if st, gt or lt are met, if 345 pmin has not been exceeded then no state synchronization occurs. 346 Likewise if st, gt or lt have not been met and pmax time has expired 347 then state synchronization occurs. The current value of the resource 348 is used for the synchronization. If pmin time is exceeded and st, gt 349 or lt are met then the current value of the resource is synchronized. 350 If st is also included, a state synchronization resulting from pmin 351 or pmax updates STinit with the synchronized value. 353 If gt and lt are included gt MUST be greater than lt otherwise an 354 error CoAP error code 4.00 "Bad Request" (or equivalent) MUST be 355 returned. 357 If st is included in a query with a gt or lt attribute then state 358 synchronizations occur only when the conditions described by st AND 359 gt or st AND gl are met. 361 4. Binding Table 363 The binding table is a special resource that gives access to the 364 bindings on a endpoint. A binding table resource MUST support the 365 Binding interface defined below. A profile SHOULD allow only one 366 resource table per endpoint. 368 4.1. Binding Interface Description 370 This section defines a REST interface for Binding table resources. 371 The interface supports the link-format type. 373 The if= column defines the Interface Description (if=) attribute 374 value to be used in the CoRE Link Format for a resource conforming to 375 that interface. When this value appears in the if= attribute of a 376 link, the resource MUST support the corresponding REST interface 377 described in this section. The resource MAY support additional 378 functionality, which is out of scope for this specification. 379 Although this interface description is intended to be used with the 380 CoRE Link Format, it is applicable for use in any REST interface 381 definition. 383 The Methods column defines the REST methods supported by the 384 interface, which are described in more detail below. 386 +-----------+----------+-------------------+-----------------+ 387 | Interface | if= | Methods | Content-Formats | 388 +-----------+----------+-------------------+-----------------+ 389 | Binding | core.bnd | GET, POST, DELETE | link-format | 390 +-----------+----------+-------------------+-----------------+ 392 Table 3: Binding Interface Description 394 The Binding interface is used to manipulate a binding table. A 395 request with a POST method and a content format of application/link- 396 format simply appends new bindings to the table. All links in the 397 payload MUST have a relation type "boundTo". A GET request simply 398 returns the current state of a binding table whereas a DELETE request 399 empties the table. Individual entries may be deleted from the table 400 by specifying the resource path in a DELETE request. 402 The following example shows requests for adding, retrieving and 403 deleting bindings in a binding table. 405 Req: POST /bnd/ (Content-Format: application/link-format) 406 ; 407 rel="boundto";anchor="/a/light";bind="obs";pmin="10";pmax="60" 408 Res: 2.04 Changed 410 Req: GET /bnd/ 411 Res: 2.05 Content (application/link-format) 412 ; 413 rel="boundto";anchor="/a/light";bind="obs";pmin="10";pmax="60" 415 Req: DELETE /bnd/a/light 416 Res: 2.04 Changed 418 Req: DELETE /bnd/ 419 Res: 2.04 Changed 421 Figure 1: Binding Interface Example 423 4.2. Resource Observation Attributes 425 When resource interfaces following this specification are made 426 available over CoAP, the CoAP Observation mechanism [RFC7641] MAY be 427 used to observe any changes in a resource, and receive asynchronous 428 notifications as a result. In addition, a set of query string 429 parameters are defined here to allow a client to control how often a 430 client is interested in receiving notifications and how much a 431 resource value should change for the new representation to be 432 interesting. These query parameters are described in the following 433 table. A resource using an interface description defined in this 434 specification and marked as Observable in its link description SHOULD 435 support these observation parameters. The Change Step parameter can 436 only be supported on resources with an atomic numeric value. 438 These query parameters MUST be treated as resources that are read 439 using GET and updated using PUT, and MUST NOT be included in the 440 Observe request. Multiple parameters MAY be updated at the same time 441 by including the values in the query string of a PUT. Before being 442 updated, these parameters have no default value. 444 +----------------+------------------+------------------+ 445 | Resource | Parameter | Data Format | 446 +----------------+------------------+------------------+ 447 | Minimum Period | /{resource}?pmin | xsd:integer (>0) | 448 | | | | 449 | Maximum Period | /{resource}?pmax | xsd:integer (>0) | 450 | | | | 451 | Change Step | /{resource}?st | xsd:decimal (>0) | 452 | | | | 453 | Less Than | /{resource}?lt | xsd:decimal | 454 | | | | 455 | Greater Than | /{resource}?gt | xsd:decimal | 456 +----------------+------------------+------------------+ 458 Table 4: Resource Observation Attribute Summary 460 inimum Period: As per Section 3.3.2 462 aximum Period: As per Section 3.3.3 464 Change Step: As per Section 3.3.4 466 Greater Than: As per Section 3.3.5 468 Less Than: As per Section 3.3.6 470 5. Security Considerations 472 An implementation of a client needs to be prepared to deal with 473 responses to a request that differ from what is specified in this 474 specification. A server implementing what the client thinks is a 475 resource with one of these interface descriptions could return 476 malformed representations and response codes either by accident or 477 maliciously. A server sending maliciously malformed responses could 478 attempt to take advantage of a poorly implemented client for example 479 to crash the node or perform denial of service. 481 6. IANA Considerations 483 6.1. Interface Description 485 The specification registers the "binding" CoRE interface description 486 link target attribute value as per [RFC6690]. 488 Attribute Value: core.binding 490 Description: The binding interface is used to manipulate a binding 491 table which describes the link bindings between source and 492 destination resources for the purposes of synchronizing their 493 content. 495 Reference: This specification. Note to RFC editor: please insert the 496 RFC of this specification. 498 Notes: None 500 6.2. Link Relation Type 502 This specification registers the new "boundto" link relation type as 503 per [RFC5988]. 505 Relation Name: boundto 507 Description: The purpose of a boundto relation type is to indicate 508 that there is a binding between a source resource and a 509 destination resource for the purposes of synchronizing their 510 content. 512 Reference: This specification. Note to RFC editor: please insert 513 the RFC of this specification. 515 Notes: None 517 Application Data: None 519 7. Acknowledgements 521 Acknowledgement is given to colleagues from the SENSEI project who 522 were critical in the initial development of the well-known REST 523 interface concept, to members of the IPSO Alliance where further 524 requirements for interface types have been discussed, and to Szymon 525 Sasin, Cedric Chauvenet, Daniel Gavelle and Carsten Bormann who have 526 provided useful discussion and input to the concepts in this 527 specification. 529 8. Changelog 531 draft-ietf-core-dynlink-03 533 o General: Reverted to using "gt" and "lt" from "gth" and "lth" for 534 this draft owing to concerns raised that the attributes are 535 already used in LwM2M with the original names "gt" and "lt". 537 o New author and editor added. 539 draft-ietf-core-dynlink-02 541 o General: Changed the name of the greater than attribute "gt" to 542 "gth" and the name of the less than attribute "lt" to "lth" due to 543 conlict with the core resource directory draft lifetime "lt" 544 attribute. 546 o Clause 6.1: Addressed the editor's note by changing the link 547 target attribute to "core.binding". 549 o Added Appendix A for examples. 551 draft-ietf-core-dynlink-01 553 o General: The term state synchronization has been introduced to 554 describe the process of synchronization between destination and 555 source resources. 557 o General: The document has been restructured the make the 558 information flow better. 560 o Clause 3.1: The descriptions of the binding attributes have been 561 updated to clarify their usage. 563 o Clause 3.1: A new clause has been added to discuss the 564 interactions between the resources. 566 o Clause 3.4: Has been simplified to refer to the descriptions in 567 3.1. As the text was largely duplicated. 569 o Clause 4.1: Added a clarification that individual resources may be 570 removed from the binding table. 572 o Clause 6: Formailised the IANA considerations. 574 draft-ietf-core-dynlink Initial Version 00: 576 o This is a copy of draft-groves-core-dynlink-00 578 draft-groves-core-dynlink Draft Initial Version 00: 580 o This initial version is based on the text regarding the dynamic 581 linking functionality in I.D.ietf-core-interfaces-05. 583 o The WADL description has been dropped in favour of a thorough 584 textual description of the REST API. 586 9. References 588 9.1. Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 592 RFC2119, March 1997, . 595 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/ 596 RFC5988, October 2010, . 599 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 600 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 601 . 603 9.2. Informative References 605 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 606 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 607 RFC7252, June 2014, . 610 [RFC7641] Hartke, K., "Observing Resources in the Constrained 611 Application Protocol (CoAP)", RFC 7641, DOI 10.17487/ 612 RFC7641, September 2015, . 615 Appendix A. Examples 617 This appendix provides some examples of the use of binding attribute 618 / observe attributes. 620 Note: For brevity the only the method or response code is shown in 621 the header field. 623 A.1. Greater Than (gt) example 625 Observed CLIENT SERVER Actual 626 t State | | State 627 ____________ | | ____________ 628 1 | | 629 2 unknown | | 18.5 Cel 630 3 +----->| Header: GET 631 4 | GET | Token: 0x4a 632 5 | | Uri-Path: temperature 633 6 | | Uri-Query: gt="25" 634 7 | | Observe: 0 (register) 635 8 | | 636 9 ____________ |<-----+ Header: 2.05 637 10 | 2.05 | Token: 0x4a 638 11 18.5 Cel | | Observe: 9 639 12 | | Payload: "18.5 Cel" 640 13 | | 641 14 | | 642 15 | | ____________ 643 16 ____________ |<-----+ Header: 2.05 644 17 | 2.05 | 26 Cel Token: 0x4a 645 18 26 Cel | | Observe: 16 646 29 | | Payload: "26 Cel" 647 20 | | 648 21 | | 650 Figure 2: Client Registers and Receives one Notification of the 651 Current State and One of a New State when it passes through the 652 greather than threshold of 25. 654 A.2. Greater Than (gt) and Period Max (pmax) example 656 Observed CLIENT SERVER Actual 657 t State | | State 658 ____________ | | ____________ 659 1 | | 660 2 unknown | | 18.5 Cel 661 3 +----->| Header: GET 662 4 | GET | Token: 0x4a 663 5 | | Uri-Path: temperature 664 6 | | Uri-Query: pmax="20";gt="25" 665 7 | | Observe: 0 (register) 666 8 | | 667 9 ____________ |<-----+ Header: 2.05 668 10 | 2.05 | Token: 0x4a 669 11 18.5 Cel | | Observe: 9 670 12 | | Payload: "18.5 Cel" 671 13 | | 672 14 | | 673 15 | | 674 16 | | 675 17 | | 676 18 | | 677 19 | | 678 20 | | 679 21 | | 680 22 | | 681 23 | | 682 24 | | 683 25 | | 684 26 | | 685 27 | | 686 28 | | 687 29 | | ____________ 688 30 ____________ |<-----+ Header: 2.05 689 31 | 2.05 | 23 Cel Token: 0x4a 690 32 23 Cel | | Observe: 30 691 33 | | Payload: "23 Cel" 692 34 | | 693 35 | | 694 36 | | ____________ 695 37 ____________ |<-----+ Header: 2.05 696 38 | 2.05 | 26 Cel Token: 0x4a 697 39 26 Cel | | Observe: 37 698 40 | | Payload: "26 Cel" 699 41 | | 700 42 | | 702 Figure 3: Client Registers and Receives one Notification of the 703 Current State, one when pmax time expires and one of a new State when 704 it passes through the greather than threshold of 25. 706 Authors' Addresses 708 Zach Shelby 709 ARM 710 150 Rose Orchard 711 San Jose 95134 712 FINLAND 714 Phone: +1-408-203-9434 715 Email: zach.shelby@arm.com 716 Matthieu Vial 717 Schneider-Electric 718 Grenoble 719 FRANCE 721 Phone: +33 (0)47657 6522 722 Email: matthieu.vial@schneider-electric.com 724 Michael Koster 725 SmartThings 726 665 Clyde Avenue 727 Mountain View 94043 728 USA 730 Email: michael.koster@smartthings.com 732 Christian Groves 733 Huawei 734 Australia 736 Email: cngroves.std@gmail.com 738 Julian Zhu 739 Huawei 740 No.127 Jinye Road, Huawei Base, High-Tech Development District 741 Xi'an, Shaanxi Province 742 China 744 Email: jintao.zhu@huawei.com 746 Bilhanan Silverajan (editor) 747 Tampere University of Technology 748 Korkeakoulunkatu 10 749 Tampere FI-33720 750 Finland 752 Email: bilhanan.silverajan@tut.fi