idnits 2.17.1 draft-li-core-coap-patience-option-06.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 176 has weird spacing: '... client ser...' -- The document date (December 16, 2014) is 3416 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 R. Sun 5 Expires: June 19, 2015 Huawei Technologies 6 E. Dijk 7 Philips Research 8 S. Loreto 9 Ericsson 10 December 16, 2014 12 CoAP Option Extension: Patience 13 draft-li-core-coap-patience-option-06 15 Abstract 17 CoAP is a RESTful application protocol for constrained nodes and 18 networks. This specification provides a simple extension for CoAP, 19 the Patience option. This option is used by a CoAP client to 20 indicate the maximum time a client is prepared to wait for a 21 response. The CoAP server should try to return the response within 22 the specified time frame. 24 Note 26 Discussion and suggestions for improvement are requested, and should 27 be sent to core@ietf.org. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 19, 2015. 46 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . 2 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Patience Option Extension . . . . . . . . . . . . . . . . . . 3 67 2.1. Patience Option Definition . . . . . . . . . . . . . . . 3 68 2.2. Using the Patience Option . . . . . . . . . . . . . . . . 3 69 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 This specification adds a new Patience option to CoAP [RFC7252]. The 79 main purpose is for the client to inform the server of the preferred 80 time frame for a response. It is used in a request to indicate the 81 client patience in waiting for a response. It then indicates "a 82 response is most useful within the specified time frame". 84 1.1. Justification 86 It can be useful for the client to indicate that the response is 87 required to be returned within a certain amount of time. For 88 example, the client could require a response within 2 seconds, 89 otherwise the response is not of interest anymore. With this 90 indication of the patience for a response, the client knows how long 91 it should wait for the response, and it needs to keep the state of 92 the request only for the indicated time. After this period, the 93 request will be given up. It can avoid that the server wastes 94 resources by sending a response which already exceeds the set 95 patience timeout of the client. 97 If the Patience option is combined with Observe option in a request, 98 it indicates the maximum time an observer is prepared to wait for an 99 initial notification. 101 1.2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Patience Option Extension 109 2.1. Patience Option Definition 111 +-----+---+---+---+---+----------+---------+--------+---------+ 112 | No. | C | U | N | R | Name | Format | Length | Default | 113 +-----+---+---+---+---+----------+---------+--------+---------+ 114 | 28 | | | x | | Patience | integer | 1-2 B | none | 115 +-----+---+---+---+---+----------+---------+--------+---------+ 117 The value of the Patience option is measured in seconds. The range 118 is from 1 second to 2^16 seconds, that is, 65535 seconds, around 18 119 hours. There is no default value for the Patience option. 121 The Patience option is "elective". It MUST NOT occur more than once. 123 2.2. Using the Patience Option 125 In the unicast case, this option is used by a CoAP client to indicate 126 the maximum time a client is prepared to wait for a response. 128 The client adds the Patience option to any request for which it is 129 prepared to wait for a response. The client sets the option to the 130 maximum time that it is prepared to wait. 132 The Patience option applies to both a piggy-backed response and a 133 separate response. For a separate response, the patience applies to 134 the actual response, not to the ACK. The ACK should be sent 135 immediately upon receipt of the CON message. 137 TBD: In case a client retransmits a request, the Patience Option 138 value MAY be decreased by an amount of time equivalent to the time 139 since the previous transmission attempt. In case a client did not 140 receive an ACK to a confirmable request and a time interval of at 141 least the interval indicated in the Patience Option of the request 142 has passed, the client SHOULD give up the request. 144 The server interprets this option as the maximum time between receipt 145 of the complete request and the time that it begins sending the 146 response. The client will observe a longer time interval between 147 request and response, as network transit and processing by proxies 148 add delays. If timing is critical, the client SHOULD consider the 149 possible delays and choose the value for the option accordingly. 151 The server MAY apply a lower value to the patience timeout based on 152 local policy. A server MAY choose to take longer to produce a 153 response, at the risk that the client is no longer able to use the 154 response. 156 In case that the CoAP message is transmitted through a proxy, the 157 Proxy MAY reduce the value of a Patience option based on a local 158 policy (e.g. to consider the maximum time that an idle connection is 159 kept open by a local NAT or Firewall). A Proxy MAY add a Patience 160 option if none is present. The value in the Patience option MUST NOT 161 be increased or removed. 163 If the client does not receive a response within the indicated 164 response time, the client SHOULD consider the request as failed. If 165 the server can't provide a response within the required time, the 166 server SHOULD discard the request. 168 3. Example 170 This section gives a short example with a message flow that 171 illustrates the use of the Patience option in a GET request. 173 This example (Figure 1) shows that the client wants to get a response 174 within 60 seconds. 176 client server 177 | | 178 | | 179 +-------->| Header: GET (T=CON, Code=1, MID=0x7d38) 180 | GET | Token: 0x53 181 | | Patience: 60 182 | | Uri-Path: "temperature" 183 | | 184 |<--------+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) 185 | 2.05 | Token: 0x53 186 | | Payload: "22.3 C" 187 | | 189 Figure 1: Patience Option in a unicast request 191 4. Security Considerations 193 This presents no security considerations beyond those in section 10 194 of the base CoAP specification [RFC7252]. 196 5. IANA Considerations 198 The IANA is requested to add the following "CoAP Option Numbers" 199 entry as per Section 12.2 of [RFC7252]. 201 +-----+---+---+---+---+----------+---------------+--------+---------+ 202 | No. | C | U | N | R | Name | Format | Length | Default | 203 +-----+---+---+---+---+----------+---------------+--------+---------+ 204 | 28 | | | x | | Patience | (ref to this | 1-2 B | (none) | 205 | | | | | | | document) | | | 206 +-----+---+---+---+---+----------+---------------+--------+---------+ 208 6. Acknowledgements 210 The authors of this draft would like to thank the participants of the 211 email discussion on this issue. Thanks to Carsten Bormann, Peter 212 Bigot, Barry Leiba, Linyi Tian, Gengyu Wei for the reviews and 213 discussions. 215 7. Normative References 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 221 Application Protocol (CoAP)", RFC 7252, June 2014. 223 Authors' Addresses 225 Kepeng Li 226 Huawei Technologies 227 Huawei Base, Bantian, Longgang District 228 Shenzhen, Guangdong 518129 229 P. R. China 231 Email: likepeng@huawei.com 233 Bert Greevenbosch 234 Huawei Technologies 235 Huawei Base, Bantian, Longgang District 236 Shenzhen, Guangdong 518129 237 P. R. China 239 Email: bert.greevenbosch@huawei.com 241 Ruinan Sun 242 Huawei Technologies 243 Huawei Base, Bantian, Longgang District 244 Shenzhen, Guangdong 518129 245 P. R. China 247 Phone: +86-755-28970171 248 Email: sunruinan@huawei.com 250 Esko Dijk 251 Philips Research 252 High Tech Campus 34 253 Eindhoven 254 The Netherlands 256 Email: esko.dijk@philips.com 258 Salvatore Loreto 259 Ericsson 260 Hirsalantie 11 261 Jorvas 02420 262 Finland 264 Email: salvatore.loreto@ericsson.com