idnits 2.17.1 draft-li-core-coap-patience-option-05.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 == Line 175 has weird spacing: '... client ser...' -- The document date (October 24, 2014) is 3471 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core K. Li 3 Internet-Draft B. Greevenbosch 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 27, 2015 E. Dijk 6 Philips Research 7 S. Loreto 8 Ericsson 9 October 24, 2014 11 CoAP Option Extension: Patience 12 draft-li-core-coap-patience-option-05 14 Abstract 16 CoAP is a RESTful application protocol for constrained nodes and 17 networks. This specification provides a simple extension for CoAP, 18 the Patience option. This option is used by a CoAP client to 19 indicate the maximum time a client is prepared to wait for a 20 response. The CoAP server should try to return the response within 21 the specified time frame. 23 Note 25 Discussion and suggestions for improvement are requested, and should 26 be sent to core@ietf.org. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 27, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . 2 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Patience Option Extension . . . . . . . . . . . . . . . . . . 3 66 2.1. Patience Option Definition . . . . . . . . . . . . . . . 3 67 2.2. Using the Patience Option . . . . . . . . . . . . . . . . 3 68 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 This specification adds a new Patience option to CoAP [RFC7252]. The 78 main purpose is for the client to inform the server of the preferred 79 time frame for a response. It is used in a request to indicate the 80 client patience in waiting for a response. It then indicates "a 81 response is most useful within the specified time frame". 83 1.1. Justification 85 It can be useful for the client to indicate that the response is 86 required to be returned within a certain amount of time. For 87 example, the client could require a response within 2 seconds, 88 otherwise the response is not of interest anymore. With this 89 indication of the patience for a response, the client knows how long 90 it should wait for the response, and it needs to keep the state of 91 the request only for the indicated time. After this period, the 92 request will be given up. It can avoid that the server wastes 93 resources by sending a response which already exceeds the set 94 patience timeout of the client. 96 If the Patience option is combined with Observe option in a request, 97 it indicates the maximum time an observer is prepared to wait for an 98 initial notification. 100 1.2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Patience Option Extension 108 2.1. Patience Option Definition 110 +-----+---+---+---+---+----------+---------+--------+---------+ 111 | No. | C | U | N | R | Name | Format | Length | Default | 112 +-----+---+---+---+---+----------+---------+--------+---------+ 113 | 28 | | | x | | Patience | integer | 1-2 B | none | 114 +-----+---+---+---+---+----------+---------+--------+---------+ 116 The value of the Patience option is measured in seconds. The range 117 is from 1 second to 2^16 seconds, that is, 65535 seconds, around 18 118 hours. There is no default value for the Patience option. 120 The Patience option is "elective". It MUST NOT occur more than once. 122 2.2. Using the Patience Option 124 In the unicast case, this option is used by a CoAP client to indicate 125 the maximum time a client is prepared to wait for a response. 127 The client adds the Patience option to any request for which it is 128 prepared to wait for a response. The client sets the option to the 129 maximum time that it is prepared to wait. 131 The Patience option applies to both a piggy-backed response and a 132 separate response. For a separate response, the patience applies to 133 the actual response, not to the ACK. The ACK should be sent 134 immediately upon receipt of the CON message. 136 TBD: In case a client retransmits a request, the Patience Option 137 value MAY be decreased by an amount of time equivalent to the time 138 since the previous transmission attempt. In case a client did not 139 receive an ACK to a confirmable request and a time interval of at 140 least the interval indicated in the Patience Option of the request 141 has passed, the client SHOULD give up the request. 143 The server interprets this option as the maximum time between receipt 144 of the complete request and the time that it begins sending the 145 response. The client will observe a longer time interval between 146 request and response, as network transit and processing by proxies 147 add delays. If timing is critical, the client SHOULD consider the 148 possible delays and choose the value for the option accordingly. 150 The server MAY apply a lower value to the patience timeout based on 151 local policy. A server MAY choose to take longer to produce a 152 response, at the risk that the client is no longer able to use the 153 response. 155 In case that the CoAP message is transmitted through a proxy, the 156 Proxy MAY reduce the value of a Patience option based on a local 157 policy (e.g. to consider the maximum time that an idle connection is 158 kept open by a local NAT or Firewall). A Proxy MAY add a Patience 159 option if none is present. The value in the Patience option MUST NOT 160 be increased or removed. 162 If the client does not receive a response within the indicated 163 response time, the client SHOULD consider the request as failed. If 164 the server can't provide a response within the required time, the 165 server SHOULD discard the request. 167 3. Example 169 This section gives a short example with a message flow that 170 illustrates the use of the Patience option in a GET request. 172 This example (Figure 1) shows that the client wants to get a response 173 within 60 seconds. 175 client server 176 | | 177 | | 178 +-------->| Header: GET (T=CON, Code=1, MID=0x7d38) 179 | GET | Token: 0x53 180 | | Patience: 60 181 | | Uri-Path: "temperature" 182 | | 183 |<--------+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) 184 | 2.05 | Token: 0x53 185 | | Payload: "22.3 C" 186 | | 188 Figure 1: Patience Option in a unicast request 190 4. Security Considerations 192 This presents no security considerations beyond those in section 10 193 of the base CoAP specification [RFC7252]. 195 5. IANA Considerations 197 The IANA is requested to add the following "CoAP Option Numbers" 198 entry as per Section 12.2 of [RFC7252]. 200 +-----+---+---+---+---+----------+---------------+--------+---------+ 201 | No. | C | U | N | R | Name | Format | Length | Default | 202 +-----+---+---+---+---+----------+---------------+--------+---------+ 203 | 28 | | | x | | Patience | (ref to this | 1-2 B | (none) | 204 | | | | | | | document) | | | 205 +-----+---+---+---+---+----------+---------------+--------+---------+ 207 6. Acknowledgements 209 The authors of this draft would like to thank the participants of the 210 email discussion on this issue. Thanks to Carsten Bormann, Peter 211 Bigot, Barry Leiba, Linyi Tian, Gengyu Wei for the reviews and 212 discussions. 214 7. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, March 1997. 219 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 220 Application Protocol (CoAP)", RFC 7252, June 2014. 222 Authors' Addresses 224 Kepeng Li 225 Huawei Technologies 226 Huawei Base, Bantian, Longgang District 227 Shenzhen, Guangdong 518129 228 P. R. China 230 Email: likepeng@huawei.com 232 Bert Greevenbosch 233 Huawei Technologies 234 Huawei Base, Bantian, Longgang District 235 Shenzhen, Guangdong 518129 236 P. R. China 238 Email: bert.greevenbosch@huawei.com 240 Esko Dijk 241 Philips Research 242 High Tech Campus 34 243 Eindhoven 244 The Netherlands 246 Email: esko.dijk@philips.com 248 Salvatore Loreto 249 Ericsson 250 Hirsalantie 11 251 Jorvas 02420 252 Finland 254 Email: salvatore.loreto@ericsson.com