idnits 2.17.1 draft-tcs-coap-no-response-option-17.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 -- The document date (May 12, 2016) is 2906 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-http-mapping' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'I-D.koster-core-coap-pubsub' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'Mobiquitous 2013' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'Sensys 2013' is defined on line 739, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- No information found for draft-ietf-core-coap-tcp-tls-01 - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CoRE A. Bhattacharyya 2 Internet Draft S. Bandyopadhyay 3 Intended status: Informational A. Pal 4 Expires: November 2016 T. Bose 5 Tata Consultancy Services Ltd. 6 May 12, 2016 8 CoAP option for no server-response 9 draft-tcs-coap-no-response-option-17 11 Abstract 13 There can be M2M scenarios where responses from a server against 14 requests from client are redundant. This kind of open-loop exchange 15 (with no response path from the server to the client) may be desired 16 to minimize resource consumption in constrained systems while 17 updating a bulk of resources simultaneously, or updating a resource 18 with a very high frequency. CoAP already provides Non-confirmable 19 (NON) messages that are not acknowledged by the recipient. However, 20 the request/response semantics still require the server to respond 21 with a status code indicating "the result of the attempt to 22 understand and satisfy the request". 24 This specification introduces a CoAP option called 'No-Response'. 25 Using this option the client can explicitly express to the server 26 its disinterest in all responses against the particular request. 27 This option also provides granular control to enable expression of 28 disinterest to a particular class of response or a combination of 29 response-classes. The server MAY decide to suppress the response by 30 not transmitting it back to the client according to the value of No- 31 Response option in the request. This option may be effective for 32 both unicast and multicast requests. This document also discusses a 33 few exemplary applications which benefit from this option. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 This Internet-Draft will expire on November 12, 2016. 58 Copyright Notice 60 Copyright (c) 2016 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with 68 respect to this document. Code Components extracted from this 69 document must include Simplified BSD License text as described in 70 Section 4.e of the Trust Legal Provisions and are provided without 71 warranty as described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction...................................................3 76 1.1. Potential Benefits........................................3 77 1.2. Terminology...............................................4 78 2. Option Definition..............................................4 79 2.1. Granular Control over Response Suppression................5 80 2.2. Method-specific Applicability Consideration...............7 81 3. Miscellaneous Aspects..........................................8 82 3.1. Re-using Tokens...........................................9 83 3.2. Taking Care of Congestion Control and Server-side Flow 84 Control.......................................................10 85 3.3. Considerations Regarding Caching of Responses............11 86 3.4. Handling No-Response Option for a HTTP-to-CoAP Reverse Proxy 87 ..............................................................11 88 4. Exemplary Application Scenarios...............................11 89 4.1. Frequent Update of Geo-location from Vehicles to Backend 90 Server........................................................11 91 4.1.1. Using No-Response with PUT..........................13 92 4.1.2. Using No-Response with POST.........................13 93 4.1.2.1. POST updating a fixed target resource..........13 94 4.1.2.2. POST updating through query-string.............14 95 4.2. Multicasting Actuation Command from a Handheld Device to a 96 Group of Appliances...........................................15 97 4.2.1. Using Granular Response Suppression.................16 98 5. IANA Considerations...........................................16 99 6. Security Considerations.......................................16 100 7. Acknowledgments...............................................16 101 8. References....................................................16 102 8.1. Normative References.....................................16 103 8.2. Informative References...................................17 105 1. Introduction 107 This specification defines a new option for Constrained Application 108 Protocol (CoAP) [RFC7252] called 'No-Response'. This option enables 109 clients to explicitly express their disinterests in receiving 110 responses back from the server. The disinterest can be expressed at 111 the granularity of response classes (e.g., 2.xx or the combination 112 of 2.xx and 5.xx). By default this option indicates interest in all 113 response classes. The server MAY decide to suppress the response by 114 not transmitting it back to the client according to the value of the 115 No-Response option in the request. 117 Along with the technical details this document presents some 118 practical application scenarios which bring out the usefulness of 119 this option. 121 Wherever, in this document, it is mentioned that a request from a 122 client is with No-Response the intended meaning is that the client 123 expresses its disinterest for all or some selected classes of 124 responses. 126 1.1. Potential Benefits 128 Use of No-Response option should be driven by typical application 129 requirement and, particularly, characteristics of the information to 130 be updated. If this option is opportunistically used in a fitting 131 M2M application then the concerned system may benefit in the 132 following aspects (however, it is to be noted, this option is 133 elective and servers can simply ignore the preference expressed by 134 the client): 136 * Reduction in network congestion due to effective reduction of 137 the overall traffic. 139 * Reduction in server-side load by relieving the server from 140 responding to each request when not necessary. 142 * Reduction in battery consumption at the constrained end- 143 point(s). 145 * Reduction in overall communication cost. 147 1.2. Terminology 149 The terms used in this document are in conformance with those 150 defined in [RFC7252]. 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC-2119. 156 2. Option Definition 158 The properties of No-Response option are given in Table 1. 160 +--------+---+---+---+---+-------------+--------+--------+---------+ 161 | Number | C | U | N | R | Name | Format | Length | Default | 162 +--------+---+---+---+---+-------------+--------+--------+---------+ 163 | 258 | | X | - | | No-Response | uint | 0-1 | 0 | 164 +--------+---+---+---+---+-------------+--------+--------+---------+ 165 Table 1: Option Properties 167 This option is a request option. It is Elective and Non-Repeatable. 168 This option is Unsafe-to-forward as the intermediary MUST know how 169 to interpret this option. Otherwise the intermediary, without 170 knowledge about the special unidirectional nature of the request, 171 would wait for responses. 173 Note: Since CoAP maintains a clear separation between the 174 request/response and the message sub-layer, this option does not 175 have any dependency on the type of message (Confirmable/Non- 176 confirmable). So, even the absence of message sub-layer (ex. 177 CoAP-over-TCP [I-D.ietf-core-coap-tcp-tls-01]) should have no 178 effect on the interpretation of this option. However, considering 179 the CoAP-over-UDP scenario [RFC7252], NON type of messages are 180 best fitting with this option, considering the expected benefits 181 out of it. Using No-Response with NON messages gets rid of any 182 kind of reverse traffic and the interaction becomes completely 183 open-loop. 185 Using this option with CON type of requests may not serve the 186 desired purpose if piggybacked responses are triggered. But, in 187 case the server responds with a separate response (which, 188 perhaps, the client does not care about) then this option can be 189 useful. Suppressing the separate response reduces traffic by one 190 additional CoAP message in this case. 192 This option contains values to indicate disinterest in all or a 193 particular class or combination of classes of responses as described 194 in the next sub-section. 196 2.1. Granular Control over Response Suppression 198 This option enables granular control over response suppression by 199 allowing the client to express its disinterest in a typical class or 200 combination of classes of responses. For example, a client may 201 explicitly tell the receiver that no response is required unless 202 something 'bad' happens and a response of class 4.xx or 5.xx is to 203 be fed back to the client. No response of the class 2.xx is required 204 in such case. 206 Note: Section 2.7 of [RFC7390] describes a scheme where a server in 207 the multicast group may decide on its own to suppress responses 208 for group communication with granular control. The client does 209 not have any knowledge about that. However, on the other hand, 210 the 'No-Response' option enables the clients to explicitly inform 211 the servers about its disinterest in responses. Such explicit 212 control on the client side may be helpful for debugging network 213 resources. An example scenario is described in Section 4.2.1. 215 The server MUST send back responses of the classes for which the 216 client has not expressed any dis-interest. There may be instances 217 where a server, on its own, decides to suppress responses. An 218 example is suppression of responses by multicast servers as 219 described in Section 2.7 of [RFC7390]. If such a server receives a 220 request with a No-Response option showing 'interest' in specific 221 response classes (i.e., not expressing disinterest for these 222 options), then any default behaviour of suppressing response, if 223 present, MUST be overridden to deliver those responses which are of 224 interest to the client. 226 So, for example, suppose a multicast server suppresses all responses 227 by default and receives a request with a No-Response option 228 expressing disinterest in 2.xx (success) responses only. Note that 229 the option value naturally expresses interest in error responses 230 4.xx/5.xx in this case. Then the server must send back a response if 231 the concerned request caused an error. 233 The option value is defined as a bit-map (Table 2) to achieve 234 granular suppression. Its length can be 0 byte (empty value) or 1 235 byte. 237 +-------+-----------------------+---------------------------------+ 238 | Value | Binary Representation | Description | 239 +-------+-----------------------+---------------------------------+ 240 | 0 | | Interested in all responses. | 241 +-------+-----------------------+---------------------------------+ 242 | 2 | 00000010 | Not interested in 2.xx | 243 | | | responses. | 244 +-------+-----------------------+---------------------------------+ 245 | 8 | 00001000 | Not interested in 4.xx | 246 | | | responses. | 247 +-------+-----------------------+---------------------------------+ 248 | 16 | 00010000 | Not interested in 5.xx | 249 | | | responses. | 250 +-------+-----------------------+---------------------------------+ 251 Table 2: Option values 253 The conventions used in deciding the option values are: 255 1. To suppress an individual class: Set bit number (n-1) starting 256 from the LSB (bit number 0) to suppress all responses belonging to 257 class n.xx. So, 259 option value to suppress n.xx class = 2**(n-1). 261 2. To suppress combination of classes: Set each corresponding bit 262 according to point 1 above. Example: The option value will be 18 263 (binary: 00010010) to suppress both 2.xx and 5.xx responses. This is 264 essentially bitwise OR of the corresponding individual values for 265 suppressing 2.xx and 5.xx. The "CoAP Response Codes" registry (Ref. 266 Section 12.1.2 of [RFC7252]) defines 2.xx, 4.xx and 5.xx responses. 267 So, an option value of 26 (binary: 00011010) will request to 268 suppress all response codes defined in [RFC7252]. 270 Note: When No-Response is used with value 26 in a request the client 271 end-point SHOULD cease listening to response(s) against the 272 particular request. On the other hand, showing interest in at 273 least one class of response means that the client end-point can 274 no longer completely cease listening activity and must be 275 configured to listen up to some application specific time-out 276 period for the particular request. The client end-point never 277 knows whether the present request will be a success or a failure. 278 Thus, for example, if the client decides to open up the response 279 for errors (4.xx and 5.xx) then it has to wait for the entire 280 time-out period even for the instances where the request is 281 successful (and the server is not supposed to send back a 282 response). A point to be noted in this context is that there may 283 be situations when the response on errors might get lost. In such 284 a situation the client would wait up to the time-out period but 285 will not receive any response. But this should not lead to the 286 impression to the client that the request was necessarily 287 successful. In other words, in this case the client cannot 288 distinguish between response suppression and message loss. The 289 application designer needs to tackle such situation. For example, 290 while performing frequent updates, the client may strategically 291 interweave requests without No-Response option into a series of 292 requests with No-Response to check time to time if things are 293 fine at the server end and the server is actively responding. 295 2.2. Method-specific Applicability Consideration 297 The following table provides a ready-reference on the possible 298 applicability of this option for all the four REST methods. This 299 table is prepared in view of the type of possible interactions 300 foreseen at time of preparing this specification. Capitalization of 301 key words like "SHOULD NOT", etc. have not been deliberately used in 302 this table as this table is only suggestive. 304 +-------------+----------------------------------------------------+ 305 | Method Name | Remarks on applicability | 306 +-------------+----------------------------------------------------+ 307 | | This should not be used with conventional GET | 308 | | request when the client requests the contents | 309 | | of a resource. However, this option may be useful | 310 | | for exceptional cases where GET requests has side | 311 | GET | effects. For instance, the proactive 'cancellation'| 312 | | procedure for observing request [RFC7641] requires | 313 | | a client to issue a GET request with Observe option| 314 | | set to 1 ('deregister'). In case it is more | 315 | | efficient to use this deregistration instead of | 316 | | reactive cancellation (rejecting the next | 317 | | notification with RST), the client MAY express its | 318 | | disinterest in the response to such a GET request. | 319 +-------------+----------------------------------------------------+ 320 | | Suitable for frequent updates (particularly in NON | 321 | | messages) on existing resources. Might not be | 322 | | useful when PUT is used to create a new resource as| 323 | | it may be important for the client to know that | 324 | PUT | the resource creation was actually successful in | 325 | | order to carry out future actions. Also, it may be | 326 | | important to ensure that a resource was actually | 327 | | created rather than updating an existing resource. | 328 +-------------+----------------------------------------------------+ 329 | | If POST is used to update a target resource | 330 | | then No-Response can be used in the same manner as | 331 | | in PUT. This option may also be useful while | 332 | POST | updating through query strings rather than updating| 333 | | a fixed target resource (see Section 4.1.2.2 for an| 334 | | example). | 335 +-------------+----------------------------------------------------+ 336 | | Deletion is usually a permanent action and if the | 337 | DELETE | client likes to ensure that the deletion request | 338 | | was properly executed then this option should not | 339 | | be used with the request. | 340 +-------------+----------------------------------------------------+ 341 Table 3: Suggested applicability of No-Response for different REST 342 methods 344 3. Miscellaneous Aspects 346 This section further describes important implementation aspects 347 worth considering while using the No-Response option. The following 348 discussion contains guidelines and requirements (derived by 349 combining [RFC7252], [RFC7390] and [RFC5405]) for the application 350 developer. 352 3.1. Re-using Tokens 354 Tokens provide a matching criteria between a request and the 355 corresponding response. The life of a Token starts when it is 356 assigned to a request and ends when the final matching response is 357 received. Then the Token can again be re-used. However, a request 358 with No-Response typically does not have any guaranteed response 359 path. So, the client has to decide on its own about when it can 360 retire a Token which has been used in an earlier request so that the 361 Token can be reused in a future request. Since the No-Response 362 option is 'elective', a server which has not implemented this option 363 will respond back. This leads to the following two scenarios: 365 The first scenario is, the client is never going to care about any 366 response coming back or about relating the response to the original 367 request. In that case it MAY reuse the Token value at liberty. 369 However, as a second scenario, let us consider that the client sends 370 two requests where the first request is with No-Response and the 371 second request, with same Token, is without No-Response. In this 372 case a delayed response to the first one can be interpreted as a 373 response to the second request (client needs a response in the 374 second case) if the time interval between using the same Token is 375 not long enough. This creates a problem in the request-response 376 semantics. 378 The most ideal solution would be to always use a unique Token for 379 requests with No-Response. But if a client wants to reuse a Token 380 then in most practical cases the client implementation SHOULD 381 implement an application specific reuse time after which it can 382 reuse the Token. A minimum reuse time for Tokens with a similar 383 expression as in Section 2.5 of [RFC7390] SHOULD be used: 385 TOKEN_REUSE_TIME = NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY + 386 MAX_LATENCY. 388 NON_LIFETIME and MAX_LATENCY are defined in 4.8.2 of [RFC7252]. 389 MAX_SERVER_RESPONSE_DELAY has same interpretation as in Section 2.5 390 of [RFC7390] for multicast request. For a unicast request, since the 391 message is sent to only one server, MAX_SERVER_RESPONSE_DELAY means 392 the expected maximum response delay from the particular server to 393 which client sent the request. For multicast requests, 394 MAX_SERVER_RESPONSE_DELAY has the same interpretation as in Section 395 2.5 of [RFC7390]. So, for multicast it is the expected maximum 396 server response delay "over all servers that the client can send a 397 multicast request to". This response delay for a given server 398 includes its specific Leisure period; where Leisure is defined in 399 Section 8.2 of [RFC7252]. In general, the Leisure for a server may 400 not be known to the client. A lower bound for Leisure, lb_Leisure, 401 is defined in [RFC7252], but not an upper bound as is needed in this 402 case. Therefore the upper bound can be estimated by taking N (N>>1) 403 times the lower bound lb_Leisure: 405 lb_Leisure = S * G / R 407 (S = estimated response size; R = data transfer rate; G = group size 408 estimate) 410 Any estimate of MAX_SERVER_RESPONSE_DELAY MUST be larger than 411 DEFAULT_LEISURE as defined in [RFC7252]. 413 Note: If it is not possible for the client to get a reasonable 414 estimate of the MAX_SERVER_RESPONSE_DELAY then the client, to be 415 safe, SHOULD use a unique Token for each stream of message. 417 3.2. Taking Care of Congestion Control and Server-side Flow Control 419 This section provides guidelines for basic congestion control. 420 Better congestion control mechanisms can be designed as future work. 422 If this option is used with NON messages then the interaction 423 becomes completely open-loop. Absence of any feedback from the 424 server-end affects congestion-control mechanism. In this case the 425 communication pattern maps to the scenario where the application 426 cannot maintain an RTT estimate as described in Section 3.1.2 of 427 [RFC5405].Hence, following [RFC5405], a 3 seconds interval is 428 suggested as the minimum interval between successive updates and use 429 even less aggressive rate when possible. However, in case of more 430 frequent update rates the application MUST have some knowledge about 431 the channel and an application developer MUST interweave occasional 432 closed-loop exchanges (e.g. NON messages without No-Response or CON 433 messages) to get an RTT estimate between the endpoints. 435 Interweaving requests without No-Response is a MUST in case of 436 aggressive request rate for applications where server-side flow 437 control is necessary. For example, as proposed in [I-D.koster-core- 438 coap-pubsub], a broker MAY return "4.29 Too Many Requests" in order 439 to request a client to slow down the request rate. Interweaving 440 requests without No-Response allows the client to listen to such 441 response. 443 3.3. Considerations Regarding Caching of Responses 445 The cacheability of CoAP responses does not depend on the request 446 method, but it depends on the Response Code. The No-Response option 447 does not lead to any impact on cacheability of responses. If a 448 request containing No-Response triggers a cacheable response then 449 the response MUST be cached. However, the response MAY not be 450 transmitted considering the value of the No-Response option in the 451 request. 453 For example, if a request with No-Response triggers a cacheable 454 response of 4.xx class with Max-Age !=0 then the response must be 455 cached. The cache will return the response to subsequent similar 456 requests without No-Response as long as the Max-Age is not elapsed. 458 3.4. Handling No-Response Option for a HTTP-to-CoAP Reverse Proxy 460 A HTTP-to-CoAP reverse proxy MAY translate an incoming HTTP request 461 to a corresponding CoAP request indicating that no response is 462 required (showing disinterest in all classes of responses) based on 463 some application specific requirement. In this case it is 464 RECOMMENDED that the reverse proxy generates an HTTP response with 465 status code 204 (No Content) when such response is allowed. The 466 generated response is sent after the proxy has successfully sent out 467 the CoAP request. 469 In case the reverse proxy applies No-Response for particular 470 class(es) of response(s) it will wait for responses up to an 471 application specific maximum time (T_max) before responding back to 472 the HTTP-side. If a response of a desired class is received within 473 T_max then the response gets translated to HTTP as defined in [I- 474 D.ietf-core-http-mapping]. However if the proxy does not receive any 475 response within T_max, it is RECOMMENDED that the reverse Proxy 476 sends an HTTP response with status code 204 (No Content) when 477 allowed for the specific HTTP request method. 479 4. Exemplary Application Scenarios 481 This section describes some exemplary application scenarios which 482 may potentially benefit from the use of No-Response option. 484 4.1. Frequent Update of Geo-location from Vehicles to Backend Server 486 Let us consider an intelligent traffic system (ITS) consisting of 487 vehicles equipped with a sensor-gateway comprising sensors like GPS 488 and Accelerometer. The sensor-gateway acts as a CoAP client. It 489 connects to the Internet using a low-bandwidth cellular (e.g. GPRS) 490 connection. The GPS co-ordinates of the vehicle are periodically 491 updated to the backend server. 493 While performing frequent location update, retransmitting (through 494 the CoAP CON mechanism) a location co-ordinate which the vehicle has 495 already left in the meantime is not efficient as it adds redundant 496 traffic to the network. Therefore, the updates are done using NON 497 messages. However, given the huge number of vehicles updating 498 frequently, the NON exchange will also trigger huge number of 499 responses from the backend. Thus the cumulative load on the network 500 will be quite significant. Also, the client in this case may not be 501 interested in getting responses against location update request for 502 the location it has already crossed in the meantime and a next 503 location update is imminent. 505 On the contrary, if the client end-points on the vehicles explicitly 506 declare that they do not need any status response back from the 507 server then load will be reduced significantly. The assumption is 508 that, since the update rate is high, stray losses in geo-location 509 reports will be compensated with the large update rate. 511 Note: It may be argued that the above example application can also 512 be implemented using Observe option ([RFC7641]) with NON 513 notifications. But, in practice, implementing with Observe would 514 require lot of book-keeping at the data-collection end-point at 515 the backend (observer). The observer needs to maintain all the 516 observe relationships with each vehicle. The data collection end- 517 point may be unable to know all its data sources beforehand. The 518 client end-points at vehicles may go offline or come back online 519 randomly. In case of Observe the onus is always on the data 520 collection end-point to establish an observe relationship with 521 each data-source. On the other hand, implementation will be much 522 simpler if the initiative is left on the data-source to carry out 523 updates using No-Response option. Another way of looking at it 524 is, the implementation choice depends on the perspective of 525 interest to initiate the update. In an Observe scenario the 526 interest is expressed by the data-consumer. On the contrary, the 527 classic update case applies when the interest is from the data- 528 producer. The 'No-Response' option enables to make classic 529 updates further less resource consuming. 531 Following subsections illustrate some exemplary exchanges based on 532 the application described above. 534 4.1.1. Using No-Response with PUT 536 Each vehicle is assigned a dedicated resource "vehicle-stat-", 537 where can be any string uniquely identifying the vehicle. The 538 update requests are sent over NON type of messages. The No-Response 539 option causes the server not to respond back. 541 Client Server 542 | | 543 | | 544 +----->| Header: PUT (T=NON, Code=0.03, MID=0x7d38) 545 | PUT | Token: 0x53 546 | | Uri-Path: "vehicle-stat-00" 547 | | Content Type: text/plain 548 | | No-Response: 26 549 | | Payload: 550 | | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667& 551 | | Time=2013-01-13T11:24:31" 552 | | 553 [No response from the server. Next update in 20s.] 554 | | 555 +----->| Header: PUT (T=NON, Code=0.03, MID=0x7d39) 556 | PUT | Token: 0x54 557 | | Uri-Path: "vehicle-stat-00" 558 | | Content Type: text/plain 559 | | No-Response: 26 560 | | Payload: 561 | | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667& 562 | | Time=2013-01-13T11:24:51" 564 Figure 1: Exemplary unreliable update with No-Response option using 565 PUT. 567 4.1.2. Using No-Response with POST 569 4.1.2.1. POST updating a fixed target resource 571 In this case POST acts the same way as PUT. The exchanges are same 572 as above. The updated values are carried as payload of POST as shown 573 in Figure 2. 575 Client Server 576 | | 577 | | 578 +----->| Header: POST (T=NON, Code=0.02, MID=0x7d38) 579 | POST | Token: 0x53 580 | | Uri-Path: "vehicle-stat-00" 581 | | Content Type: text/plain 582 | | No-Response: 26 583 | | Payload: 584 | | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667& 585 | | Time=2013-01-13T11:24:31" 586 | | 587 [No response from the server. Next update in 20s.] 588 | | 589 +----->| Header: POST (T=NON, Code=0.02, MID=0x7d39) 590 | POST | Token: 0x54 591 | | Uri-Path: "vehicle-stat-00" 592 | | Content Type: text/plain 593 | | No-Response: 26 594 | | Payload: 595 | | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667& 596 | | Time=2013-01-13T11:24:51" 598 Figure 2: Exemplary unreliable update with No-Response option using 599 POST as the update-method. 601 4.1.2.2. POST updating through query-string 603 It may be possible that the backend infrastructure deploys a 604 dedicated database to store the location updates. In such a case the 605 client can update through a POST by sending a query string in the 606 URI. The query-string contains the name/value pairs for each update. 607 'No-Response' can be used in same manner as for updating fixed 608 resources. The scenario is depicted in Figure 3. 610 Client Server 611 | | 612 | | 613 +----->| Header: POST (T=NON, Code=0.02, MID=0x7d38) 614 | POST | Token: 0x53 615 | | Uri-Path: "updateOrInsertInfo" 616 | | Uri-Query: "VehID=00" 617 | | Uri-Query: "RouteID=DN47" 618 | | Uri-Query: "Lat=22.5658745" 619 | | Uri-Query: "Long=88.4107966667" 620 | | Uri-Query: "Time=2013-01-13T11:24:31" 621 | | No-Response: 26 622 | | 623 [No response from the server. Next update in 20 secs.] 624 | | 625 +----->| Header: POST (T=NON, Code=0.02, MID=0x7d39) 626 | POST | Token: 0x54 627 | | Uri-Path: "updateOrInsertInfo" 628 | | Uri-Query: "VehID=00" 629 | | Uri-Query: "RouteID=DN47" 630 | | Uri-Query: "Lat=22.5649015" 631 | | Uri-Query: "Long=88.4103511667" 632 | | Uri-Query: "Time=2013-01-13T11:24:51" 633 | | No-Response: 26 634 | | 636 Figure 3: Exemplary unreliable update with No-Response option using 637 POST with a query-string to insert update information to backend 638 database. 640 4.2. Multicasting Actuation Command from a Handheld Device to a Group 641 of Appliances 643 A handheld device (e.g. a smart phone) may be programmed to act as 644 an IP enabled switch to remotely operate on a single or group of IP 645 enabled appliances. For example, a multicast request to switch on/ 646 off all the lights of a building can be sent. In this case the IP 647 switch application can use the No-Response option in a NON request 648 message to reduce the traffic generated due to simultaneous CoAP 649 responses from all the lights. 651 Thus No-Response helps in reducing overall communication cost and 652 the probability of network congestion in this case. 654 4.2.1. Using Granular Response Suppression 656 The IP switch application may optionally use granular response 657 suppression such that the error responses are not suppressed. In 658 that case the lights which could not execute the request would 659 respond back and be readily identified. Thus, explicit suppression 660 of option classes by the multicast client may be useful to debug the 661 network and the application. 663 5. IANA Considerations 665 The IANA has previously assigned number 284 to this option in the 666 CoAP Option Numbers Registry. IANA is requested to change this as 667 below: 669 +--------+--------------+----------------------------+ 670 | Number | Name | Reference | 671 +--------+--------------+----------------------------+ 672 | 258 | No-Response | Section 2 of this document | 673 +--------+--------------+----------------------------+ 675 6. Security Considerations 677 The No-Response option defined in this document presents no security 678 considerations beyond those in Section 11 of the base CoAP 679 specification [RFC7252]. 681 7. Acknowledgments 683 Thanks to Carsten Bormann, Matthias Kovatsch, Esko Dijk, Bert 684 Greevenbosch, Akbar Rahman and Klaus Hartke for their valuable 685 inputs. 687 8. References 689 8.1. Normative References 691 [RFC7252] 693 Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application 694 Protocol (CoAP)", RFC 7252, June, 2014 696 8.2. Informative References 698 [RFC7641] 700 Hartke, K.," Observing Resources in the Constrained Application 701 Protocol (CoAP)", RFC 7641, September, 2015 703 [RFC7390] 705 Rahman, A. and Dijk, E.,"Group Communication for CoAP", RFC 7390, 706 October, 2014 708 [RFC5405] 710 Eggert, L. and Fairhurst, G.," Unicast UDP Usage Guidelines for 711 Application Designers", RFC 5405, November, 2008 713 [I-D.ietf-core-http-mapping] 715 Castellani, A., et al., "Guidelines for HTTP-CoAP Mapping 716 Implementations", draft-ietf-core-http-mapping-09, April 6, 2016 718 [I-D.koster-core-coap-pubsub] 720 Koster, M., et al., "Publish-Subscribe Broker for the Constrained 721 Application Protocol (CoAP)", draft-koster-core-coap-pubsub-04, 722 November 5, 2015 724 [I-D.ietf-core-coap-tcp-tls-01] 726 Bormann, C., et al., "A TCP and TLS Transport for the Constrained 727 Application Protocol (CoAP)", draft-ietf-core-coap-tcp-tls-01, 728 November 19, 2015 730 [Mobiquitous 2013] 732 Bhattacharyya, A., Bandyopadhyay, S. and Pal, A., "ITS-light: 733 Adaptive lightweight scheme to resource optimize intelligent 734 transportation tracking system (ITS)-Customizing CoAP for 735 opportunistic optimization", 10th International Conference on Mobile 736 and Ubiquitous Systems: Computing, Networking and Services 737 (Mobiquitous 2013), December, 2013. 739 [Sensys 2013] 741 Bandyopadhyay, S., Bhattacharyya, A. and Pal, A., "Adapting protocol 742 characteristics of CoAP using sensed indication for vehicular 743 analytics", 11th ACM Conference on Embedded Networked Sensor Systems 744 (Sensys 2013), November, 2013. 746 Authors' Addresses 748 Abhijan Bhattacharyya 749 Tata Consultancy Services Ltd. 750 Kolkata, India 752 Email: abhijan.bhattacharyya@tcs.com 754 Soma Bandyopadhyay 755 Tata Consultancy Services Ltd. 756 Kolkata, India 758 Email: soma.bandyopadhyay@tcs.com 760 Arpan Pal 761 Tata Consultancy Services Ltd. 762 Kolkata, India 764 Email: arpan.pal@tcs.com 766 Tulika Bose 767 Tata Consultancy Services Ltd. 768 Kolkata, India 770 Email: tulika.bose@tcs.com