idnits 2.17.1 draft-fossati-core-publish-option-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: An interesting outcome of this communication strategy is that the SEP may really never need to listen on its radio interface. However, ignoring the response status code from Proxy, as well as the ETag value in case of UPDATE-able resources, is not a safe practice and SHOULD not be used unless the consequences are fully understood. -- The document date (January 06, 2014) is 3762 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) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Fossati 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track P. Giacomin 5 Expires: July 10, 2014 Freelance 6 S. Loreto 7 Ericsson 8 January 06, 2014 10 Publish Option for CoAP 11 draft-fossati-core-publish-option-03 13 Abstract 15 This memo defines the Publish Option for the Constrained Application 16 Protocol (CoAP). The Publish Option is used by a CoAP Endpoint to 17 control the authority delegation of one of its resources to another 18 Endpoint. All the phases of the authority delegation process (setup, 19 renewal, cancellation) are controlled by a simple RESTful protocol. 21 This memo also introduces the 'proxies' Web Linking relation type, to 22 be used by a CoAP Proxy to explicitly advertise the resources that it 23 can serve - either from its cache, or by forwarding the Client's 24 request upstream. 26 The Publish Option and the 'proxies' relation provide the building 27 blocks for a comprehensive, in-protocol, solution to the sleepy/ 28 intermittent Endpoint use case. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 10, 2014. 47 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language and Motivation . . . . . . . . . . 3 65 2. Publish Option . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Value Format . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2.1. Publishing a Resource . . . . . . . . . . . . . . . . 4 69 2.2.2. Updating a Resource . . . . . . . . . . . . . . . . . 6 70 2.2.3. Unpublishing a Resource . . . . . . . . . . . . . . . 6 71 2.2.4. Checking for Change . . . . . . . . . . . . . . . . . 7 72 3. The 'proxies' Relation Type . . . . . . . . . . . . . . . . . 7 73 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1.1. Discover the Proxy for a Resource . . . . . . . . . . 8 75 3.1.2. Discover all the Resources that an Endpoint 'proxies' 8 76 3.2. Publish Link-Format Attributes . . . . . . . . . . . . . 9 77 3.2.1. Implicitly . . . . . . . . . . . . . . . . . . . . . 9 78 3.2.2. Explicitly . . . . . . . . . . . . . . . . . . . . . 9 79 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 6.1. Securing the Delegation . . . . . . . . . . . . . . . . . 10 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 7.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Appendix A. A (fairly) Comprehensive Example . . . . . . . . . . 11 87 A.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 A.2. Resources . . . . . . . . . . . . . . . . . . . . . . . . 12 89 A.3. Application Flow . . . . . . . . . . . . . . . . . . . . 12 90 A.3.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . 12 91 A.3.2. Configuration and Reconfiguration . . . . . . . . . . 13 92 A.3.3. Updating Functional Output . . . . . . . . . . . . . 14 93 A.3.4. Retrieving Functional Output . . . . . . . . . . . . 14 94 A.3.5. SEP Reboot . . . . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 This memo defines the Publish Option for the Constrained Application 100 Protocol [I-D.ietf-core-coap]. The Publish Option is used by a 101 sleepy Endpoint (SEP) to temporarily delegate the authority of one of 102 its resources to another, always on, Endpoint. The delegated 103 Endpoint is typically a Proxy, though it could be an Endpoint with no 104 other special network role. The SEP is given a simple RESTful 105 messaging protocol that enables the setup, renewal and cancellation 106 of the authority transfer. The whole process is driven by the SEP, 107 which may actually never need to listen or to keep any state. 109 This memo also introduces the 'proxies' Web Linking [RFC5988] 110 relation type. This new relation, which complements the default 111 'hosts' relation defined in [RFC6690], can be used by a CoAP Proxy to 112 explicitly advertise the resources that it can serve, either from 113 cache or by forwarding the Client's request upstream. 115 The 'proxies' relation works in concert with the Publish Option to 116 enable SEP discovery even while SEP is off-line. 118 1.1. Requirements Language and Motivation 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 The terms Client, Proxy, Server, and Endpoint are to be interpreted 125 as described in [I-D.ietf-core-coap]. 127 This memo reuses the terminology introduced in 128 [I-D.rahman-core-sleepy-problem-statement], and aims at meeting the 129 objectives stated in its Section 4 via an entirely in-protocol 130 solution. 132 2. Publish Option 134 The Publish Option enables a SEP to temporarily (i.e. for a specified 135 "lease" time) delegate the authority of one of its hosted resources 136 to another Endpoint. 138 +------+---+---+---+---+---------+--------+--------+---------+ 139 | No. | C | U | N | R | Name | Format | Length | Default | 140 +------+---+---+---+---+---------+--------+--------+---------+ 141 | 31 | x | x | x | - | Publish | uint | 1 | (none) | 142 +------+---+---+---+---+---------+--------+--------+---------+ 144 The one-byte integer value carried by the Publish Option allows the 145 publishing node to specify the set of CoAP methods that are allowed 146 on the resource (see Section 2.1 for details). 148 The "lease" time of the Publish action is specified by an associated 149 (implicit or explicit) Max-Age Option value. 151 2.1. Value Format 153 The Publish Option consists of a single byte having the following 154 layout: 156 0 1 2 3 4 5 6 7 157 +-+-+-+-+-+-+-+-+ 158 |G P D 0 0 0 0 0| 159 +-+-+-+-+-+-+-+-+ 161 Each of the higher 3 bits is a flag field indicating whether the 162 associated CoAP method (respectively: GET, PUT and DELETE) is allowed 163 on the published resource. The POST method has resource/application 164 specific semantics and can't therefore be safely delegated. The 165 lower 5 bits are reserved and MUST be set to 0. 167 The 0x00 value is used to explicitly revoke the delegation (see 168 Section 2.2.3.) and MUST NOT be used for any other purpose of the 169 Option. 171 If the delegated Proxy receives a request for the published resource 172 with a method that is not compatible with the mask supplied by the 173 SEP, it MUST respond with a 4.05 (Method Not Allowed) response code. 175 2.2. Operations 177 2.2.1. Publishing a Resource 179 The SEP publishes one of its hosted resources, specified by the 180 enclosed Proxy-URI, by making a PUT to the Proxy with a Publish 181 Option attached. The Publish Option value specifies the CoAP methods 182 that Clients are allowed to use on the resource (see Section 2.1). 184 The example below shows a delegation where the GET and PUT methods 185 are allowed, whereas DELETE is explicitly prohibited, meaning that a 186 Client can only read and update the resource. 188 P SEP 189 | PUT | Proxy-URI: coap://sep.example.org/res 190 |<--------+ Publish: 0xC0 191 | r | Content-Format: text/plain 192 | | Max-Age: 1200 193 | 2.01 | 194 +-------->| ETag: 0xabcd 195 | | 196 | | 198 The Proxy, which is voluntarily entrusted by the resource owner to 199 act as the delegated origin for the "lease" time specified by Max- 200 Age, replies with a 2.01 (Created) if the authority transfer 201 succeeds. An exact duplicate of the submitted representation is 202 created, and from now on it can be accessed via the delegated Proxy 203 using the original URI encoded in a Proxy-Uri Option. If the Publish 204 operation isn't successful (e.g. because the Proxy does not support 205 Publish), then the origin transfer fails, and an appropriate response 206 code is returned (e.g. 4.02 Bad Option). 208 If no Max-Age is given, a default of 3600 seconds MUST be assumed. 209 The Max-Age value, either implicit or explicit, determines the 210 lifetime of the origin delegation. When Max-Age is elapsed, the 211 Proxy MUST delete the published resource value (and any associated 212 link-format metadata) and fall back to its usual proxying function. 214 On successful delegation, the Proxy MUST generate a new ETag and 215 return it in the 2.01 response to the Client; if the published 216 resource can be UPDATE'd, then the Client SHOULD save the ETag value 217 (see Section 2.2.4). 219 The returned ETag value represents the state of the resource at the 220 time the Publish operation is performed. The Proxy MUST change its 221 value whenever the underlying resource representation changes, e.g. 222 if it gets UPDATE'd. The current ETag value SHOULD be included by 223 the Proxy in all responses involving the published representation. 224 The ETag can be used by SEP to make conditional requests to the Proxy 225 to check whether the representation has changed (see Section 2.2.4 226 for details). 228 The Publish Option is critical, and MUST NOT be present in a 229 response. If the Proxy does not recognize it, a 4.02 (Bad Option) 230 MUST be returned to the Client. If the Option value is not correctly 231 formatted (see Section 2.1), a 4.00 (Bad Request) MUST be returned to 232 the Client. The Publish Option is not Safe-to-Forward, and neither 233 is a Cache-Key. 235 Since the 2.01 is emitted, and for the duration of the delegation, 236 any Client wishing to access the resource can do so by making a 237 Proxy-URI request to the Proxy, which shall then serve the resource 238 from its own storage. 240 An interesting outcome of this communication strategy is that the SEP 241 may really never need to listen on its radio interface. However, 242 ignoring the response status code from Proxy, as well as the ETag 243 value in case of UPDATE-able resources, is not a safe practice and 244 SHOULD not be used unless the consequences are fully understood. 246 Upon publishing, the Proxy MUST save the identity (e.g. the IP 247 address) of the publishing SEP, and MUST use it to correctly 248 authorise "maintenance" operations such as renewal or cancellation of 249 the published resource. The SEP identity MUST be kept for the whole 250 duration of the delegation (including any associated renewal) and can 251 be forgotten as soon as the delegation vanishes, either implicitly or 252 explicitly. 254 2.2.2. Updating a Resource 256 In order to update the delegated resource state or to just extend the 257 lease period, the SEP sends basically the same request (except for 258 the possibly updated representation value) to the Proxy, which in 259 turn replies with a 2.04 Changed status code, and a new ETag value, 260 in case the update operation succeeds. If the operation fails, e.g. 261 because the request comes from an Endpoint different from the 262 publishing SEP, a suitable status code is returned (e.g. 4.01 263 Unauthorized). 265 P SEP 266 | PUT | Proxy-URI: coap://sep.example.org/res 267 |<--------+ Publish: 0xC0 268 | r | Content-Format: text/plain 269 | | Max-Age: 1200 270 | 2.04 | 271 +-------->| ETag: 0xdcba 272 | | 274 2.2.3. Unpublishing a Resource 276 The delegation of a given resource can be explicitly revoked by the 277 SEP at any time before the lease time expires, by issuing a DELETE 278 request to the Proxy hosting the resource duplicate with a Publish 279 Option with value 0x00. 281 On successful deletion of the delegation, a 2.02 Deleted response 282 code is returned by the Proxy. On error a suitable status code is 283 returned. 285 P SEP 286 | DELETE | Proxy-URI: coap://sep.example.org/res 287 |<---------+ Publish: 0x00 288 | | 289 | 2.02 | 290 +--------->| 291 | | 293 2.2.4. Checking for Change 295 In order to check whether an UPDATE-able resource has changed, SEP 296 issues a GET for the published resource with If-Match Option set to 297 the last seen ETag value. 299 The possible outcomes are: 301 o 4.04 (Not Found) if the resource has been deleted; 302 o 2.05 (Content) if it has been otherwise modified; 303 o 2.03 (Valid) if it has not changed. 305 In case a 2.05 is returned, SEP saves the updated ETag returned by 306 the Proxy, and uses it on subsequent If-Match GET's. 308 Note that, in exceptionally simple scenarios, an unconditional GET 309 followed by a memcmp against the previous representation value, MAY 310 constitute a viable alternative to the method described above. 312 3. The 'proxies' Relation Type 314 The new 'proxies' Web Linking [RFC5988] relation type is meant to 315 signify that the target resource carried by the link, which MUST be 316 identified by an absolute URI, is reachable through a Proxy-URI 317 request made to the anchored Origin (i.e. the Proxy). 319 (Note that we need to specify the Proxy through an explicit anchor, 320 thus increasing the verbosity of the link value, because of the way 321 the context URI override rules are defined in Section 2.1 of 322 [RFC6690]. In fact, absent an explicit anchor, rule (b) would set 323 the context to the SEP origin, which is definitely not what we want.) 325 3.1. Examples 326 3.1.1. Discover the Proxy for a Resource 328 C multicasts a query to the /.well-known/core interface and discovers 329 the P (associated to the coap://proxy.example.org authority) 330 "proxies" the resource queried via an explicit href: 332 M C 333 | GET | Uri-Path: .well-known 334 |<--------+ Uri-Path: core 335 | Uri-Query: href="coap://sep.example.org/res" 336 P 2.05 | 337 +-------->| ; 338 | | anchor="coap://proxy.example.org/"; 339 | | rel="proxies" 341 3.1.2. Discover all the Resources that an Endpoint 'proxies' 343 C discovers all the resources that P "proxies": 345 P C 346 | GET | Uri-Path: .well-known 347 |<--------+ Uri-Path: core 348 | | Uri-Query: rel="proxies" 349 | 2.05 | 350 +-------->| ; 351 | | anchor="coap://proxy.example.org/"; 352 | | rel="proxies", 353 | | <... 355 and can then GET one of the "proxied" resource from P: 357 P C 358 | GET | 359 |<--------+ Proxy-URI: coap://sep.example.org/res 360 | | 361 | 2.05 | 362 +-------->| "res" data... 363 | | 365 The 'proxies' relation is orthogonal to the Publish Option, so it's 366 up to P to decide whether to serve coap://sep.example.org/res from 367 its store/cache, or to forward the request to the origin at coap:// 368 sep.example.org. 370 3.2. Publish Link-Format Attributes 372 3.2.1. Implicitly 374 The resource metadata are implicitly extracted from the published 375 representation. Basically, the Proxy works out the 'ct' and 'sz' 376 attributes by inspecting Content-Format and the request payload size. 378 The main advantage of this method is that it needs no further 379 transmission except that needed for the Publish operation. The 380 disadvantage is the very limited (and fixed) number of attributes 381 that can be derived, which makes it suitable only for the most basic 382 use cases. 384 3.2.2. Explicitly 386 The resource metadata are explicitly published to the same Proxy-URI 387 used for the sibling resource, either in a separate request/response 388 cycle: 390 P S 391 | PUT | Proxy-URI: coap://sep.example.org/res 392 |<--------+ Publish: 0x60 393 | | Content-Format: application/link-format 394 | | 395 | 2.01 | 396 +-------->| 397 | | 399 or atomically, within the same Publish operation, e.g. by using the 400 Multipart Content-Format to aggregate one (or even more than one) 401 representation(s) together with the application/link-format entry: 403 P S 404 | PUT | Proxy-URI: coap://sep.example.org/res 405 |<--------+ Publish: 0x60 406 | [mp] | Content-Format: application/multipart+publish 407 | | Max-Age: 1200 408 | 2.01 | 409 +-------->| 410 | | 412 Note that the former is non-atomic, and limited to only one 413 representation of the resource; the latter is atomic and supports 414 multiple Content-Format's for the published resource. 416 4. Acknowledgements 418 Thanks to Bruce Nordman, Matthieu Vial, Akbar Rahman, and Esko Dijk 419 for comments and discussions that have helped shaping this document. 421 5. IANA Considerations 423 The following entry is added to the CoAP Option Numbers registry: 425 .------------------------------. 426 | Number | Name | Reference | 427 :--------:---------:-----------: 428 | 31 | Publish | This memo | 429 `------------------------------' 431 This memo registers the new "proxies" Web Linking relation type as 432 per [RFC5988]. 434 Relation Name: proxies 435 Description: the target is the absolute URI of a resource proxied 436 by the Origin stated in the anchor. 437 Reference: this memo 438 Notes: This relation is used in CoRE where links are retrieved as 439 a "/.well-known/core" resource representation. 440 Application Data: None 442 6. Security Considerations 444 This section identifies Threats (T) and related countermeasures (C). 446 o T: cache poisoning. 447 o C: use strong auth to identify SEP. 449 o T: unauthorized update or de-registration 450 o C: strong auth to identify SEP. 452 o T: Proxy resources' exhaustion. 453 o C: use strong auth to identify SEP + quota limit. 455 o T: Inject fake copies of the resource by a 3rd party. 456 o C: use delegation scheme that bundles the identities of the SEP 457 and the Proxy, together with the resource being delegated. A 458 third party must be able to verify SEP and Proxy identities, maybe 459 offline, and check the resource fingerprint. 461 6.1. Securing the Delegation 463 [[The following is just a sketch which needs further elaboration]] 464 SEP signs the identity of the delegated Proxy and a fingerprint of 465 the resource (both data and meta), and bundles it up with the 466 resource itself, maybe in a MultiPart envelope (TBD define signed 467 Content-Format). Client verifies the resource is indeed from the SEP 468 by checking the signature, and it has been served by the intended 469 origin, within the validity frame of the delegation. There seems to 470 be an issue with hierarchical caching: the resource can't be served 471 from a downstream Proxy which is different from the one that was 472 originally delegated unless each Proxy in the delivery chain wraps 473 the received message with its own credentials? 475 7. References 477 7.1. Normative References 479 [I-D.ietf-core-coap] 480 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 481 Application Protocol (CoAP)", draft-ietf-core-coap-18 482 (work in progress), June 2013. 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, March 1997. 487 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 489 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 490 Format", RFC 6690, August 2012. 492 7.2. Informative References 494 [I-D.rahman-core-sleepy-problem-statement] 495 Rahman, A., Fossati, T., Loreto, S., and M. Vial, "Sleepy 496 Devices in CoAP - Problem Statement", draft-rahman-core- 497 sleepy-problem-statement-01 (work in progress), October 498 2012. 500 Appendix A. A (fairly) Comprehensive Example 502 The following section details the whole life-cycle of an hypothetical 503 Sleepy/Intermittent node that uses Publish to exchange data (both 504 reading and writing) with other agents in a CoAP network. 506 A.1. Actors 508 SEP Sleeping/Intermittent endpoint implementing two functions: F1, 509 and F2. Each function exposes one configurable parameter, and 510 provides one output. 512 P Proxy with Publish support. 514 W Controller application which can configure function parameters 515 on SEP. 517 R Consumer application which reads values from SEP. 519 A.2. Resources 521 The following resources model the two functions (F1 and F2) 522 implemented by SEP in terms of their input and output parameters: 524 coap://sep1/i1 Configurable parameter for F1. 526 coap://sep1/i2 Configurable parameter for F2. 528 coap://sep1/o1 Output of F1. 530 coap://sep1/o2 Output of F2. 532 If the number of configuration parameters is not trivially small, 533 then it might be handy to create an aux resource which can be polled 534 by the SEP to track the parameters that have been reconfigured: 536 coap://sep1/im Update parameter mask. Conceptually a n-bit mask 537 (one bit per configurable parameter) used by W to 538 mark the updated parameters, and by SEP to clear 539 them once the corresponding configuration has been 540 applied. 542 A.3. Application Flow 544 A.3.1. Bootstrap 546 SEP publishes all the application resources to P. 548 Configurable parameter for F1: 550 SEP -> P : PUT Proxy-URI=coap://sep1/i1, Publish="G,U", Payload="1" 551 P -> SEP : 2.01 (Created), ETag=0x01 553 Configurable parameter for F2: 555 SEP -> P : PUT Proxy-URI=coap://sep1/i2, Publish="G,U", Payload="2" 556 P -> SEP : 2.01 (Created), ETag=0x01 558 Output of F1: 560 SEP -> P : PUT Proxy-URI=coap://sep1/o1, Publish="G", Payload="" 561 P -> SEP : 2.01 (Created), ETag=0x01 563 Output of F2: 565 SEP -> P : PUT Proxy-URI=coap://sep1/o2, Publish="G", Payload="" 566 P -> SEP : 2.01 (Created), ETag=0x01 568 This assumes that SEP has pre-canned values "1" and "2" for its 569 configurable parameters i1 and i2 respectively. 571 Optionally: 573 SEP -> P : PUT Proxy-URI=coap://sep1/im, Publish="G,U", 574 Payload="update_mask_cleared" 575 P -> SEP : 2.01 (Created), ETag=0x01 577 A.3.2. Configuration and Reconfiguration 579 W sets a new value, e.g. 5, for i2: 581 W -> P : PUT Proxy-URI=coap://sep1/i2, Payload="5" 582 P -> W : 2.04 (Changed), ETag=0x02 584 P updates the value of i2 accordingly, and sets a new ETag on it, 585 e.g. 0x02. 587 When SEP wakes up, it polls its configuration variables via a 588 conditional GET that uses the ETags returned by P at publishing time. 589 Since i1 has not changed, and is still associated with the original 590 ETag, a 2.03 status code is returned: 592 SEP -> P : GET Proxy-URI=coap://sep1/i1, If-Match=0x01 593 P -> SEP : 2.03 (Valid) 595 Since i2 has changed, a 2.05 status code is returned and the payload 596 carries the new value. Also, the new ETag associated with i2 is 597 returned and is updated locally by the SEP: 599 SEP -> P : GET Proxy-URI=coap://sep1/i2, If-Match=0x01 600 P -> SEP : 2.05 (Content), ETag=0x02, Payload="5" 601 The SEP reconfigures its F1 based on the new configuration setting, 602 and continues its operations. 604 A.3.3. Updating Functional Output 606 SEP wakes up and commits the newly computed values, e.g. 6 and 8, to 607 P: 609 SEP -> P : PUT Proxy-URI=coap://sep1/o1, Publish="G", Payload="6" 610 P -> SEP : 2.04 (Changed), ETag=0x02 612 SEP -> P : PUT Proxy-URI=coap://sep1/o2, Publish="G", Payload="8" 613 P -> SEP : 2.04 (Changed), ETag=0x02 615 P sets the new values, assigns a new ETag, and gives it back to P 616 together with a 2.04 status code. 618 A.3.4. Retrieving Functional Output 620 R needs to retrieve the latest values for the functions computed by 621 SEP; thus, it asks P to retrieve the associated resources: 623 R -> P : GET Proxy-URI=coap://sep1/o1 624 P -> R : 2.05 (Content), ETag=0x02, Payload="6" 626 R -> P : GET Proxy-URI=coap://sep1/o2 627 P -> R : 2.05 (Content), ETag=0x02, Payload="8" 629 Note that the exchange above applies to the very first poll. 630 Subsequent polls can be done conditionally on the "last-seen" ETag. 632 Also note that the above assumes SEP has been able to update its 633 values at least once. R must be prepared to retrieve empty 634 representations, if SEP has not yet updated their value since boot- 635 strap. 637 A.3.5. SEP Reboot 639 The idempotence of all the involved methods guarantees a clean 640 recovery in face of a reboot of the SEP. In fact, if at a given time 641 SEP reboots and loose soft state, including the configuration 642 parameters: SEP has to go again through the bootstrap phase in which 643 the application resources are published: 645 SEP -> P : PUT Proxy-URI=coap://sep1/i1, Publish="G,U", Payload="1" 646 P -> SEP : 2.04 (Changed), ETag=0x03 648 SEP -> P : PUT Proxy-URI=coap://sep1/i2, Publish="G,U", Payload="2" 649 P -> SEP : 2.04 (Changed), ETag=0x03 651 SEP -> P : PUT Proxy-URI=coap://sep1/o1, Publish="G", Payload="" 652 P -> SEP : 2.04 (Changed), ETag=0x03 654 SEP -> P : PUT Proxy-URI=coap://sep1/o2, Publish="G", Payload="" 655 P -> SEP : 2.04 (Changed), ETag=0x03 657 The ETag's value (0x03) needs to be not recently used (not within the 658 Max-Age period for the resource). 660 From now on everything can proceed as described in Appendix A.3.2, 661 Appendix A.3.3, and Appendix A.3.4 663 Authors' Addresses 665 Thomas Fossati 666 Alcatel-Lucent 667 3 Ely Road 668 Milton, Cambridge CB24 6DD 669 UK 671 Email: thomas.fossati@alcatel-lucent.com 673 Pierpaolo Giacomin 674 Freelance 676 Email: yrz@anche.no 678 Salvatore Loreto 679 Ericsson 680 Hirsalantie 11 681 Jorvas 02420 682 Finland 684 Email: salvatore.loreto@ericsson.com