idnits 2.17.1 draft-bormann-coap-misc-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 == Line 1174 has weird spacing: '... code mid...' -- The document date (May 26, 2012) is 4350 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 782, but not defined -- Looks like a reference, but probably isn't: '0' on line 1467 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-09 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-19 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-03) exists of draft-allman-tcpm-rto-consider-01 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft K. Hartke 4 Intended status: Informational Universitaet Bremen TZI 5 Expires: November 27, 2012 May 26, 2012 7 Miscellaneous additions to CoAP 8 draft-bormann-coap-misc-17 10 Abstract 12 This short I-D makes a number of partially interrelated proposals how 13 to solve certain problems in the CoRE WG's main protocol, the 14 Constrained Application Protocol (CoAP). The current version has 15 been resubmitted to keep information about these proposals available; 16 the proposals are not all fleshed out at this point in time. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 27, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Getting rid of artificial limitations . . . . . . . . . . . . 5 54 2.1. Option Length encoding beyond 270 bytes . . . . . . . . . 5 55 3. Vendor-defined Option . . . . . . . . . . . . . . . . . . . . 8 56 4. Patience, Leisure, and Pledge . . . . . . . . . . . . . . . . 9 57 4.1. Patience . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 4.2. Leisure . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 4.3. Pledge . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 4.4. Option Formats . . . . . . . . . . . . . . . . . . . . . . 10 61 5. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 5.1. Requesting a Tunnel with CONNECT . . . . . . . . . . . . . 12 63 5.2. Using a CONNECT Tunnel . . . . . . . . . . . . . . . . . . 12 64 5.3. Closing down a CONNECT Tunnel . . . . . . . . . . . . . . 13 65 6. Envelope Options . . . . . . . . . . . . . . . . . . . . . . . 14 66 6.1. Example envelope option: solving #230 . . . . . . . . . . 15 67 6.2. Example envelope option: proxy-elective options . . . . . 15 68 7. Protocol Constants and Time Constants . . . . . . . . . . . . 17 69 7.1. Protocol Constants . . . . . . . . . . . . . . . . . . . . 17 70 7.2. Time Constants derived from Protocol Constants . . . . . . 18 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 77 Appendix A. The Nursery (Things that still need to ripen a 78 bit) . . . . . . . . . . . . . . . . . . . . . . . . 26 79 A.1. Payload-Length Option . . . . . . . . . . . . . . . . . . 26 80 A.2. URI Authorities with Binary Adresses . . . . . . . . . . . 26 81 A.3. Length-aware number encoding (o256) . . . . . . . . . . . 27 82 A.4. SMS encoding . . . . . . . . . . . . . . . . . . . . . . . 29 83 A.4.1. ASCII-optimized SMS encoding . . . . . . . . . . . . . 30 84 Appendix B. The Cemetery (Things we won't do) . . . . . . . . . . 33 85 B.1. Stateful URI compression . . . . . . . . . . . . . . . . . 33 86 B.2. Beyond 270 bytes in a single option . . . . . . . . . . . 34 87 B.3. Beyond 15 options . . . . . . . . . . . . . . . . . . . . 35 88 B.3.1. Implementation considerations . . . . . . . . . . . . 36 89 B.3.2. What should we do now? . . . . . . . . . . . . . . . . 37 90 B.3.3. Alternatives . . . . . . . . . . . . . . . . . . . . . 37 91 B.3.4. Alternative: Going to a delimiter model . . . . . . . 37 92 B.4. Implementing the option delimiter for 15 or more 93 options . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 Appendix C. Experimental Options . . . . . . . . . . . . . . . . 39 95 C.1. Options indicating absolute time . . . . . . . . . . . . . 39 96 C.2. Representing Durations . . . . . . . . . . . . . . . . . . 40 97 C.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 41 98 C.4. Pseudo-Floating Point . . . . . . . . . . . . . . . . . . 42 99 C.5. A Duration Type for CoAP . . . . . . . . . . . . . . . . . 43 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 102 1. Introduction 104 The CoRE WG is tasked with standardizing an Application Protocol for 105 Constrained Networks/Nodes, CoAP [I-D.ietf-core-coap]. This protocol 106 is intended to provide RESTful [REST] services not unlike HTTP 107 [RFC2616], while reducing the complexity of implementation as well as 108 the size of packets exchanged in order to make these services useful 109 in a highly constrained network of themselves highly constrained 110 nodes. 112 This objective requires restraint in a number of sometimes 113 conflicting ways: 115 o reducing implementation complexity in order to minimize code size, 117 o reducing message sizes in order to minimize the number of 118 fragments needed for each message (in turn to maximize the 119 probability of delivery of the message), the amount of 120 transmission power needed and the loading of the limited-bandwidth 121 channel, 123 o reducing requirements on the environment such as stable storage, 124 good sources of randomness or user interaction capabilities. 126 This draft attempts to address a number of problems not yet 127 adequately solved in [I-D.ietf-core-coap]. The solutions proposed to 128 these problems are somewhat interrelated and are therefore presented 129 in one draft. 131 The appendix contains the "CoAP cemetery" (possibly later to move 132 into its own draft), documenting roads that the WG decided not to 133 take, in order to spare readers from reinventing them in vain. 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 The term "byte" is used in its now customary sense as a synonym for 140 "octet". 142 2. Getting rid of artificial limitations 144 _Artificial limitations_ are limitations of a protocol or system that 145 are not rooted in limitations of actual capabilities, but in 146 arbitrary design decisions. Proper system design tries to avoid 147 artificial limitations, as these tend to cause complexity in systems 148 that need to work with these limitations. 150 E.g., the original UNIX filesystem had an artificial limitation of 151 the length of a path name component to 14 bytes. This led to all 152 kinds of workarounds in programs that manipulate file names: E.g., 153 systematically replacing a ".el" extension in a filename with a 154 ".elc" for the compiled file might exceed the limit, so all ".el" 155 files were suddenly limited to 13-byte filenames. 157 Note that, today, there still is a limitation in most file system 158 implementations, typically at 255. This just happens to be high 159 enough to rarely be of real-world concern; we will refer to this case 160 as a "painless" artificial limitation. 162 CoAP-08 had two highly recognizable artificial limitations in its 163 protocol encoding 165 o The number of options in a single message is limited to 15 max. 167 o The length of an option is limited to 270 max. 169 It has been argued that the latter limitation causes few problems, 170 just as the 255-byte path name component limitation in filenames 171 today causes few problems. Appendix B.2 provided a design to extend 172 this; as a precaution to future extensions of this kind, the current 173 encoding for length 270 (eight ones in the extension byte) could be 174 marked as reserved today. Since, Matthias Kovatsch has proposed a 175 simpler scheme that seems to gain favor in the WG, see Section 2.1. 177 The former limitation has been solved in CoAP-09. A historical 178 discussion of other approaches for going beyond 15 options is in 179 Appendix B.3. Appendix B.4 discusses implementation. 181 2.1. Option Length encoding beyond 270 bytes 183 For option lengths beyond 270 bytes, we reserve the value 255 of an 184 extension byte to mean "add 255, read another extension byte" 185 Figure 1. While this causes the length of the option header to grow 186 linearly with the size of the option value, only 0.4 % of that size 187 is used. With a focus on short options, this encoding is justified. 189 for 15..269: 190 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 191 | Option Delta | 1 1 1 1 | Length - 15 | 192 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 193 | Option Value ... 194 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 196 for 270..524: 197 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 198 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 199 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 200 | Length - 270 | Option Value ... 201 +---+---+---+---+---+---+---+---+ 202 | 203 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 205 for 525..779: 206 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 207 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 208 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 209 | 1 1 1 1 1 1 1 1 | Length - 525 | 210 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 | Option Value ... 212 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 214 for 780..1034: 215 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 216 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 217 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 218 | 1 1 1 1 1 1 1 1 | 1 1 1 1 1 1 1 1 | 219 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 220 | Length - 780 | Option Value ... 221 +---+---+---+---+---+---+---+---+ 222 | 223 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 225 Figure 1: Options beyond 270 bytes 227 Options that are longer than 1034 bytes MUST NOT be sent; an option 228 that has 255 (all one bits) in the field called "Length - 780" MUST 229 be rejected upon reception as an invalid option. 231 In the process, the maximum length of all options that are currently 232 set at 270 should now be set to a carefully chosen value. With the 233 purely encoding-based limit gone, Uri-Proxy should now be restored to 234 be a non-repeatable option. 236 A first proposal for a new set of per-option length restrictions 237 follows: 239 +--------+----------------+-----+------+--------+--------+ 240 | number | name | min | max | type | repeat | 241 +--------+----------------+-----+------+--------+--------+ 242 | 1 | content_type | 0 | 2 | uint | no | 243 | | | | | | | 244 | 2 | max_age | 0 | 4 | uint | no | 245 | | | | | | | 246 | 3 | proxy_uri | 1 | 1023 | string | no | 247 | | | | | | | 248 | 4 | etag | 1 | 8 | opaque | yes | 249 | | | | | | | 250 | 5 | uri_host | 1 | 255 | string | no | 251 | | | | | | | 252 | 6 | location_path | 0 | 255 | string | yes | 253 | | | | | | | 254 | 7 | uri_port | 0 | 2 | uint | no | 255 | | | | | | | 256 | 8 | location_query | 0 | 255 | string | yes | 257 | | | | | | | 258 | 9 | uri_path | 0 | 255 | string | yes | 259 | | | | | | | 260 | 10 | observe | 0 | 2 | uint | no | 261 | | | | | | | 262 | 11 | token | 1 | 8 | opaque | no | 263 | | | | | | | 264 | 12 | accept | 0 | 2 | uint | yes | 265 | | | | | | | 266 | 13 | if_match | 0 | 8 | opaque | yes | 267 | | | | | | | 268 | 14 | vendor | 0 | 1023 | opaque | yes | 269 | | | | | | | 270 | 15 | uri_query | 1 | 255 | string | yes | 271 | | | | | | | 272 | 17 | block2 | 0 | 3 | uint | no | 273 | | | | | | | 274 | 18 | size | 0 | 4 | uint | no | 275 | | | | | | | 276 | 19 | block1 | 0 | 3 | uint | no | 277 | | | | | | | 278 | 21 | if_none_match | 0 | 0 | - | no | 279 +--------+----------------+-----+------+--------+--------+ 281 (Option 14 with a length of 0 is a fencepost only.) 283 3. Vendor-defined Option 285 To enable experimentation and community-specific options, option 286 number 14 (the first NOP option) can also be used as a vendor-defined 287 option. For this application, the option value has one or more 288 bytes, the semantics of which are defined by prior agreement between 289 the communicating partners. 291 It is RECOMMENDED to start the option value with a unique identifier, 292 e.g., the SDNV [RFC5050] of the enterprise number of the organisation 293 defining the option, possibly followed by additional discriminating 294 bits or bytes as defined by the organisation. 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |1 0 0 0 0 0 0 1|0 1 1 1 0 0 1 1| private opt-id| value... | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 \___SDNV of enterprise number___/ 301 Figure 2: Example option value for vendor-defined option 303 Note that a Vendor-defined Option cannot be empty, not only because 304 there would be no space for the SDNV, but in particular as the empty 305 option 14 is reserved for fenceposting ([I-D.ietf-core-coap], section 306 3.2). (Obviously, once a Vendor-defined Option is in use, there is 307 never a need for a fence-post for option number 14.) 309 Vendor-defined Options are elective. 311 The Vendor-defined Option is repeatable. 313 +-----+----------+--------+-------------+---------+---------+ 314 | No. | C/E | Name | Format | Length | Default | 315 +-----+----------+--------+-------------+---------+---------+ 316 | 14 | Elective | Vendor | (see below) | 1-270 B | (empty) | 317 +-----+----------+--------+-------------+---------+---------+ 319 4. Patience, Leisure, and Pledge 321 A number of options might be useful for controlling the timing of 322 interactions. 324 (This section also addresses core-coap ticket #177.) 326 4.1. Patience 328 A client may have a limited time period in which it can actually make 329 use of the response for a request. Using the Patience option, it can 330 provide an (elective) indication how much time it is willing to wait 331 for the response from the server, giving the server license to ignore 332 or reject the request if it cannot fulfill it in this period. 334 If the server knows early that it cannot fulfill the request in the 335 time requested, it MAY indicate this with a 5.04 "Timeout" response. 336 For non-safe methods (such as PUT, POST, DELETE), the server SHOULD 337 indicate whether it has fulfilled the request by either responding 338 with 5.04 "Timeout" (and not further processing the request) or by 339 processing the request normally. 341 Note that the value of the Patience option should be chosen such that 342 the client will be able to make use of the result even in the 343 presence of the expected network delays for the request and the 344 response. Similarly, when a proxy receives a request with a Patience 345 option and cannot fulfill that request from its cache, it may want to 346 adjust the value of the option before forwarding it to an upstream 347 server. 349 (TBD: The various cases that arise when combining Patience with 350 Observe.) 352 The Patience option is elective. Hence, a client MUST be prepared to 353 receive a normal response even after the chosen Patience period (plus 354 an allowance for network delays) has elapsed. 356 4.2. Leisure 358 Servers generally will compute an internal value that we will call 359 Leisure, which indicates the period of time that will be used for 360 responding to a request. A Patience option, if present, can be used 361 as an upper bound for the Leisure. Leisure may be non-zero for 362 congestion control reasons, in particular for responses to multicast 363 requests. For these, the server should have a group size estimate G, 364 a target rate R (which both should be chosen conservatively) and an 365 estimated response size S; a rough lower bound for Leisure can then 366 be computed as follows: 368 lb_Leisure = S * G / R 370 Figure 3: Computing a lower bound for the Leisure 372 E.g., for a multicast request with link-local scope on an 2.4 GHz 373 IEEE 802.15.4 (6LoWPAN) network, G could be (relatively 374 conservatively) set to 100, S to 100 bytes, and the target rate to 8 375 kbit/s = 1 kB/s. The resulting lower bound for the Leisure is 10 376 seconds. 378 To avoid response implosion, responses to multicast requests SHOULD 379 be dithered within a Leisure period chosen by the server to fall 380 between these two bounds. 382 Currently, we don't foresee a need to signal a value for Leisure from 383 client to server (beyond the signalling provided by Patience) or from 384 server to client, but an appropriate Option might be added later. 386 4.3. Pledge 388 In a basic observation relationship [I-D.ietf-core-observe], the 389 server makes a pledge to keep the client in the observation 390 relationship for a resource at least until the max-age for the 391 resource is reached. 393 To save the client some effort in re-establishing observation 394 relationships each time max-age is reached, the server MAY want to 395 extend its pledge beyond the end of max-age by signalling in a 396 response/notification an additional time period using the Pledge 397 Option, in parallel to the Observe Option. 399 The Pledge Option MUST NOT be used unless the server can make a 400 reasonable promise not to lose the observation relationship in this 401 time frame. 403 Currently, we don't foresee a need to signal a value for Pledge from 404 client to server, but an appropriate behavior might be added later 405 for this option when sent in a request. 407 4.4. Option Formats 409 +-----+----------+----------+-----------------+--------+---------+ 410 | No. | C/E | Name | Format | Length | Default | 411 +-----+----------+----------+-----------------+--------+---------+ 412 | 22 | Elective | Patience | Duration in mis | 1 B | (none) | 413 | | | | | | | 414 | 24 | Elective | Pledge | Duration in s | 1 B | 0 | 415 +-----+----------+----------+-----------------+--------+---------+ 417 All timing options use the Duration data type (see Appendix C.2), 418 however Patience (and Leisure, if that ever becomes an option) uses a 419 timebase of mibiseconds (mis = 1/1024 s) instead of seconds. (This 420 reduces the range of the Duration from ~ 91 days to 128 minutes.) 422 Implementation note: As there are no strong accuracy requirements on 423 the clocks employed, making use of any existing time base of 424 milliseconds is a valid implementation approach (2.4 % off). 426 None of the options may be repeated. 428 5. CONNECT 430 [RFC2817] defines the HTTP CONNECT method to establish a TCP tunnel 431 through a proxy so that end-to-end TLS connections can be made 432 through the proxy. Recently, a requirement for similar functionality 433 has been discussed for CoAP. This section defines a strawman CONNECT 434 method and related methods and response codes for CoAP. 436 (IANA considerations for this section TBD.) 438 5.1. Requesting a Tunnel with CONNECT 440 CONNECT is allocated as a new method code in the "CoAP Method Codes" 441 registry. When a client makes a CONNECT request to an intermediary, 442 the intermediary evaluates the Uri-Host, Uri-Port, and/or the 443 authority part of the Proxy-Uri Options in a way that is defined by 444 the security policy of the intermediary. If the security policy 445 allows the allocation of a tunnel based on these parameters, the 446 method returns an empty payload and a response code of 2.30 Tunnel 447 Established. Other possible response codes include 4.03 Forbidden. 449 It may be the case that the intermediary itself can only reach the 450 requested origin server through another intermediary. In this case, 451 the first intermediary SHOULD make a CONNECT request of that next 452 intermediary, requesting a tunnel to the authority. A proxy MUST NOT 453 respond with any 2.xx status code unless it has either a direct or 454 tunnel connection established to the authority. 456 An origin server which receives a CONNECT request for itself MAY 457 respond with a 2.xx status code to indicate that a tunnel is 458 established to itself. 460 Code 2.30 "Tunnel Established" is allocated as a new response code in 461 the "CoAP Response Codes" registry. 463 5.2. Using a CONNECT Tunnel 465 Any successful (2.xx) response to a CONNECT request indicates that 466 the intermediary has established a tunnel to the requested host and 467 port. The tunnel is bound to the requesting end-point and the Token 468 supplied in the request (as always, the default Token is admissable). 469 The tunnel can be used by the client by making a DATAGRAM request. 471 DATAGRAM is allocated as a new method code in the "CoAP Method Codes" 472 registry. When a client makes a DATAGRAM request to an intermediary, 473 the intermediary looks up the tunnel bound to the client end-point 474 and Token supplied in the DATAGRAM request (no other Options are 475 permitted). If a tunnel is found and the intermediary's security 476 policy permits, the intermediary forwards the payload of the DATAGRAM 477 request as the UDP payload towards the host and port established for 478 the tunnel. No response is defined for this request (note that the 479 request can be given as a CON or NON request; for CON, there will be 480 an ACK on the message layer if the tunnel exists). 482 The security policy on the intermediary may restrict the allowable 483 payloads based on its security policy, possibly considering host and 484 port. An inadmissable paylaod SHOULD cause a 4.03 Forbidden response 485 with a diagnostic message as payload. 487 The UDP payload of any datagram received from the tunnel and admitted 488 by the security policy is forwarded to the client as the payload of a 489 2.31 "Datagram Received" response. The response does not carry any 490 Option except for Token, which identifies the tunnel towards the 491 client. 493 Code 2.31 "Datagram Received" is allocated as a new response code in 494 the "CoAP Response Codes" registry. 496 An origin server that has established a tunnel to itself processes 497 the CoAP payloads of related DATAGRAM requests as it would process an 498 incoming UDP payload, and forwards what would be outgoing UDP 499 payloads in 2.31 "Datagram Received" responses. 501 5.3. Closing down a CONNECT Tunnel 503 A 2.31 "Datagram Received" response may be replied to with a RST, 504 which closes down the tunnel. Similarly, the Token used in the 505 tunnel may be reused by the client for a different purpose, which 506 also closes down the tunnel. 508 6. Envelope Options 510 As of [I-D.ietf-core-coap], options can take one of three types, two 511 of which are mostly identical: 513 o uint: A non-negative integer which is represented in network byte 514 order using a variable number of bytes (see [I-D.ietf-core-coap] 515 Appendix A); 517 o string: a sequence of bytes that is nominally a Net-Unicode string 518 [RFC5198]; 520 o opaque: a sequence of bytes. 522 It turns out some options would benefit from some internal structure. 523 Also, it may be a good idea to be able to bundle multiple options 524 into one, in order to ensure consistency for a set of elective 525 options that need to be processed all or nothing (i.e., the option 526 becomes critical as soon as another option out of the set is 527 processed, too). 529 In this section, we introduce a fourth CoAP option type: Envelope 530 options. 532 An envelope option is a sequence of bytes that looks and is 533 interpreted exactly like a CoAP sequence of options. Instead of an 534 option count or an end-of-option marker, the sequence of options is 535 terminated by the end of the envelope option. 537 The nested options (options inside the envelope option) may come from 538 the same number space as the top-level CoAP options, or the envelope 539 option may define its own number space - this choice needs to be 540 defined for each envelope option. 542 If the top-level number space is used, the envelope option typically 543 will restrict the set of options that actually can be used in the 544 envelope. In particular, it is unlikely that an envelope option will 545 allow itself inside the envelope (this would be a recursive option). 547 Envelope options are a general, but simple mechanism. Some of its 548 potential uses are illustrated by two examples below. (Each of these 549 examples also has its own merits and demerits, which should be 550 discussed separately from the concept of Envelope options employed in 551 the examples.) 553 6.1. Example envelope option: solving #230 555 Ticket #230 [CoRE230] points out a design flaw of 556 [I-D.ietf-core-coap]: When we split the elective Location option of 557 draft -01 into multiple elective options, we made it possible that an 558 implementation might process some of these and ignore others, leading 559 to an incorrect interpretation of the Location expressed by the 560 server. 562 There are several more or less savory solutions to #230. 564 Each of the elective options that together make up the Location could 565 be defined in such a way that it makes a requirement on the 566 processing of the related option (essentially revoking their elective 567 status once the option under consideration is actually processed). 568 This falls flat as soon as another option is defined that would also 569 become part of the Location: existing implementations would not know 570 that the new option is also part of the cluster that is re- 571 interpreted as critical. The potential future addition of Location- 572 Host and Location-Port makes this a valid consideration. 574 A better solution would be to define an elective Envelope Option 575 called Location. Within a Location Option, the following top-level 576 options might be allowed (now or in the future): 578 o Uri-Host 580 o Uri-Port 582 o Uri-Path 584 o Uri-Query 586 This would unify the code for interpreting the top-level request 587 options that indicate the request URI with the code that interprets 588 the Location URI. 590 The four options listed are all critical, while the envelope is 591 elective. This gives exactly the desired semantics: If the envelope 592 is processed at all (which is elective), the nested options are 593 critical and all need to be processed. 595 6.2. Example envelope option: proxy-elective options 597 Another potential application of envelope options is motivated by the 598 observation that new critical options might not be implemented by all 599 proxies on the CoAP path to an origin server. So that this does not 600 become an obstacle to introducing new critical options that are of 601 interest only to client and origin server, the client might want to 602 mark some critical options proxy-elective, i.e. elective for a proxy 603 but still critical for the origin server. 605 One way to do this would be an Envelope option, the Proxy-Elective 606 Option. A client might bundle a number of critical options into a 607 critical Proxy-Elective Option. A proxy that processes the message 608 is obliged to process the envelope (or reject the message), where 609 processing means passing on the nested options towards the origin 610 server (preferably again within a Proxy-Elective option). It can 611 pass on the nested options, even ones unknown to the proxy, knowing 612 that the client is happy with proxies not processing all of them. 614 (The assumption here is that the Proxy-Elective option becomes part 615 of the base standard, so all but the most basic proxies would know 616 how to handle it.) 618 7. Protocol Constants and Time Constants 620 CoAP defines a number of time-related protocol constants. There are 621 also a number of assumptions about the timing behavior of the 622 network. This section attempts to provide input to a possible 623 update, addressing #201 [CoRE201]. 625 7.1. Protocol Constants 627 Section 9 of [I-D.ietf-core-coap] defines three protocol constants: 629 +------------------------+---------------+ 630 | name | default value | 631 +------------------------+---------------+ 632 | RESPONSE_TIMEOUT | 2 seconds | 633 | | | 634 | RESPONSE_RANDOM_FACTOR | 1.5 | 635 | | | 636 | MAX_RETRANSMIT | 4 | 637 +------------------------+---------------+ 639 Section 9 gives license to a configuration to modify these protocol 640 constants, without specifying a configuration method. It also does 641 not give any further guidance. Both Cullen Jennings (msg03072by) and 642 Michael Scharf (msg03280e) have argued we do need some additional 643 guidance here. 645 In particular, Michael Scharf notes that 647 o a decrease of RESPONSE_TIMEOUT below 1 second would violate the 648 guidelines of RFC 5405, and it would not be safe for use in the 649 Internet; 651 o significantly decreasing the RESPONSE_TIMEOUT would require an 652 adaptive RTT measurement to be robust, see RFC 5405 or 653 draft-allman-tcpm-rto-consider. [...] the draft should strongly 654 discourage any decrease of RESPONSE_TIMOUT until such more 655 advanced mechanisms exist, and it should explain why. 657 We should therefore add the following text at the end of Section 9: 659 The protocol constants have been chosen to achieve a behavior in 660 the presence of congestion that is safe in the Internet. If a 661 configuration desires to use different values, the onus is on the 662 configureation to ensure these congestion control properties are 663 not violated. In particular, a decrease of RESPONSE_TIMEOUT below 664 1 second would violate the guidelines of [RFC5405]. 665 ([I-D.allman-tcpm-rto-consider] provides some additional 666 background.) CoAP was designed to enable implementations that do 667 not maintain round-trip-time (RTT) measurements. However, where 668 it is desired to decrease the RESPONSE_TIMEOUT significantly, this 669 can only be done safely when maintaining such measurements. 670 Configurations MUST NOT decrease RESPONSE_TIMEOUT without using 671 mechanisms that ensure congestion control safety, either defined 672 in the configuration or in future standards documents. 674 RESPONSE_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it 675 SHOULD have a value that is sufficiently different from 1.0 to 676 provide some protection from synchronization effects. 678 MAX_RETRANSMIT can be freely adjusted, but a too small value will 679 reduce the probability that a confirmed message is actually 680 received, while a larger value will require further adjustments in 681 the time constants (see discussion below). 683 If the choice of protocol constants leads to an increase of 684 derived time constants (see below), the configuration mechanism 685 MUST ensure the adjusted value is available to the corresponding 686 end-points, too. 688 7.2. Time Constants derived from Protocol Constants 690 (This section might become a new section 9.2 in [I-D.ietf-core-coap]. 691 The various places where these calculations are included in the text, 692 e.g., section 4.1, can then just use these numbers.) 694 The combination of RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR and 695 MAX_RETRANSMIT influences the timing of retransmissions, which in 696 turn influences how long certain information items need to be kept by 697 an implementation. To be able to unambiguously reference these 698 derived time constants, we give them names as follows: 700 o MAX_TRANSMIT_SPAN is the maximum time from the first transmission 701 of a confirmed message to its last retransmission. For the 702 default protocol constants, the value is (2+4+8+16)*1.5 = 45 703 seconds, or more generally: 705 RESPONSE_TIMEOUT * (2 ** MAX_RETRANSMIT - 1) * 706 RESPONSE_RANDOM_FACTOR 708 o MAX_TRANSMIT_WAIT is the maximum time from the first transmission 709 of a confirmed message to the time when the sender gives up on 710 receiving a response. For the default protocol constants, the 711 value is (2+4+8+16+32)*1.5 = 93 seconds, or more generally: 713 RESPONSE_TIMEOUT * (2 ** (MAX_RETRANSMIT + 1) - 1) * 714 RESPONSE_RANDOM_FACTOR 716 In addition, some assumptions need to be made on the characteristics 717 of the network and the nodes. 719 o MAX_LATENCY is the maximum time a datagram is expected to take 720 from the start of its transmission to the completion of its 721 reception. This constant is related to the MSL (Maximum Segment 722 Lifetime) of [RFC0793], which is "arbitrarily defined to be 2 723 minutes" ([RFC0793] glossary, page 81). Note that this is not 724 necessarily smaller than MAX_TRANSMIT_WAIT, as MAX_LATENCY is not 725 intended to describe a situation when the protocol works well, but 726 the worst case situation against which the protocol has to guard. 727 We, also arbitrarily, define MAX_LATENCY to be 100 seconds. Apart 728 from being reasonably realistic for the bulk of configurations as 729 well as close to the historic choice for TCP, this value also 730 allows message ID lifetime timers to be represented in 8 bits 731 (when measured in seconds). In these calculations, there is no 732 assumption that the direction of the transmission is irrelevant 733 (i.e. that the network is symmetric), just that the same value can 734 reasonably be used as a maximum value for both directions. If 735 that is not the case, the following calculations become only 736 slightly more complex. 738 o PROCESSING_DELAY is the time a node takes to turn around a 739 confirmed message into an acknowledgement. We assume the node 740 will attempt to send an ACK before having the sender time out, so 741 as a conservative assumption we set it equal to RESPONSE_TIMEOUT. 743 o MAX_RTT is the maximum round-trip time, or: 745 2 * MAX_LATENCY + PROCESSING_DELAY 747 From these constants, we can derive the following values relevant to 748 the protocol operation: 750 o EXCHANGE_LIFETIME is the time from starting to send a confirmed 751 message to the time when a response is no longer expected, i.e. 752 message layer information about the message exchange can be 753 purged. EXCHANGE_LIFETIME includes a MAX_TRANSMIT_SPAN, a 754 MAX_LATENCY forward, PROCESSING_DELAY, and a MAX_LATENCY for the 755 way back. Note that there is no need to consider 756 MAX_TRANSMIT_WAIT if the configuration is chosen such that the 757 last waiting period (RESPONSE_TIMEOUT * (2 ** MAX_RETRANSMIT) or 758 the difference between MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT) is 759 less than MAX_LATENCY -- which is a likely choice, as MAX_LATENCY 760 is a worst case value unlikely to be met in the real world. In 761 this case, EXCHANGE_LIFETIME simplifies to: 763 (RESPONSE_TIMEOUT * (2 ** MAX_RETRANSMIT) * 764 RESPONSE_RANDOM_FACTOR) + (2 * MAX_LATENCY) 766 or 248 seconds with the default protocol constants. 768 o (others? We need to go through [I-D.ietf-core-coap] and find 769 places where we can substitute in these constants.) 771 8. IANA Considerations 773 This draft adds option numbers to Table 2 of [I-D.ietf-core-coap]: 775 +--------+----------+-----------+ 776 | Number | Name | Reference | 777 +--------+----------+-----------+ 778 | 14 | Vendor | [RFCXXXX] | 779 | | | | 780 | 22 | Patience | [RFCXXXX] | 781 | | | | 782 | 24 | Pledge | [RFCXXXX] | 783 +--------+----------+-----------+ 785 Table 1: New CoAP Option Numbers 787 9. Security Considerations 789 TBD. 791 10. Acknowledgements 793 This work was partially funded by the Klaus Tschira Foundation. 795 Of course, much of the content of this draft is the result of 796 discussions with the [I-D.ietf-core-coap] authors. 798 Patience and Leisure were influenced by a mailing list discussion 799 with Esko Dijk, Kepeng Li, and Salvatore Loreto - thanks! 801 11. References 803 11.1. Normative References 805 [I-D.ietf-core-coap] 806 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 807 "Constrained Application Protocol (CoAP)", 808 draft-ietf-core-coap-09 (work in progress), March 2012. 810 [I-D.ietf-core-observe] 811 Hartke, K., "Observing Resources in CoAP", 812 draft-ietf-core-observe-05 (work in progress), March 2012. 814 [I-D.ietf-httpbis-p1-messaging] 815 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 816 1: URIs, Connections, and Message Parsing", 817 draft-ietf-httpbis-p1-messaging-19 (work in progress), 818 March 2012. 820 [I-D.ietf-httpbis-p4-conditional] 821 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 822 4: Conditional Requests", 823 draft-ietf-httpbis-p4-conditional-19 (work in progress), 824 March 2012. 826 [I-D.ietf-httpbis-p6-cache] 827 Fielding, R., Lafon, Y., Nottingham, M., and J. Reschke, 828 "HTTP/1.1, part 6: Caching", 829 draft-ietf-httpbis-p6-cache-19 (work in progress), 830 March 2012. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, March 1997. 835 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 836 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 837 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 839 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 840 Encodings", RFC 4648, October 2006. 842 11.2. Informative References 844 [CoRE201] "Multiple Location options need to be processed as a 845 unit", CoRE ticket #201, 2012, 846 . 848 [CoRE230] "Multiple Location options need to be processed as a 849 unit", CoRE ticket #230, 2012, 850 . 852 [I-D.allman-tcpm-rto-consider] 853 Allman, M., "Retransmission Timeout Considerations", 854 draft-allman-tcpm-rto-consider-01 (work in progress), 855 May 2012. 857 [REST] Fielding, R., "Architectural Styles and the Design of 858 Network-based Software Architectures", 2000. 860 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 861 RFC 793, September 1981. 863 [RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", 864 RFC 1924, April 1996. 866 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 867 HTTP/1.1", RFC 2817, May 2000. 869 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 870 Specification", RFC 5050, November 2007. 872 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 873 Interchange", RFC 5198, March 2008. 875 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 876 for Application Designers", BCP 145, RFC 5405, 877 November 2008. 879 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 880 Values in Protocols", RFC 6256, May 2011. 882 Appendix A. The Nursery (Things that still need to ripen a bit) 884 A.1. Payload-Length Option 886 Not all transport mappings may provide an unambiguous length of the 887 CoAP message. For UDP, it may also be desirable to pack more than 888 one CoAP message into one UDP payload (aggregation); in that case, 889 for all but the last message there needs to be a way to delimit the 890 payload of that message. 892 This can be solved using a new option, the Payload-Length option. If 893 this option is present, the value of this option is an unsigned 894 integer giving the length of the payload of the message (note that 895 this integer can be zero for a zero-length payload, which can in turn 896 be represented by a zero-length option value). (In the UDP 897 aggregation case, what would have been in the payload of this message 898 after "payload-length" bytes is then actually one or more additional 899 messages.) 901 A.2. URI Authorities with Binary Adresses 903 One problem with the way URI authorities are represented in the URI 904 syntax is that the authority part can be very bulky if it encodes an 905 IPv6 address in ASCII. 907 Proposal: Provide an option "Uri-Authority-Binary" that can be an 908 even number of bytes between 2 and 18 except 12 or 14. 910 o If the number of bytes is 2, the destination IP address of the 911 packet transporting the CoAP message is implied. 913 o If the number of bytes is 4 or 6, the first four bytes of the 914 option value are an IPv4 address in binary. 916 o If the number of bytes is 8 or 10, the first eight bytes are the 917 lower 64 bits of an IPv6 address; the upper eight bytes are 918 implied from the destination address of the packet transporting 919 the CoAP message. 921 o If the number of bytes is 16 or 18, the first 16 bytes are an IPv6 922 address. 924 o If two more bytes remain, this is a port number (as always in 925 network byte order). 927 The resulting authority is (conceptually translated into ASCII and) 928 used in place of an Uri-Authority option, or inserted into a Proxy- 929 Uri. Examples: 931 +-------------+------------------+---------+------------------------+ 932 | Proxy-Uri | Uri-Authority-Bi | Uri-Pat | URI | 933 | | nary | h | | 934 +-------------+------------------+---------+------------------------+ 935 | (none) | (none) | (none) | "/" | 936 | | | | | 937 | (none) | (none) | 'temp' | "/temp" | 938 | | | | | 939 | (none) | 2 bytes: 61616 | 'temp' | "coap://[DA]:61616/tem | 940 | | | | p" | 941 | | | | | 942 | (none) | 16 bytes: | temp | "coap://[2000::1]/temp | 943 | | 2000::1 | | " | 944 | | | | | 945 | 'http://' | 10 bytes: | (none) | "http://[DA::123:45]:6 | 946 | | ::123:45 + 616 | | 16" | 947 | | | | | 948 | 'http:///te | 18 bytes: | (none) | "http://[2000::1]:616/ | 949 | mp' | 2000::1 + 616 | | temp" | 950 +-------------+------------------+---------+------------------------+ 952 A.3. Length-aware number encoding (o256) 954 The number encoding defined in Appendix A of [I-D.ietf-core-coap] has 955 one significant flaw: Every number has an infinite number of 956 representations, which can be derived by adding leading zero bytes. 957 This runs against the principle of minimizing unnecessary choice. 958 The resulting uncertainty in encoding ultimately leads to unnecessary 959 interoperability failures. (It also wastes a small fraction of the 960 encoding space, i.e., it wastes bytes.) 962 We could solve the first, but not the second, by outlawing leading 963 zeroes, but then we have to cope with error cases caused by illegal 964 values, another source of interoperability problems. 966 The number encoding "o256" defined in this section avoids this flaw. 967 The suggestion is not to replace CoAP's "uint" encoding wholesale 968 (CoAP is already too widely implemented for such a change), but to 969 consider this format for new options. 971 The basic requirements for such an encoding are: 973 o numbers are encoded as a sequence of zero or more bytes 975 o each number has exactly one encoding 977 o for a < b, encoding-size(a) <= encoding-size(b) -- i.e., with 978 larger numbers, the encoding only gets larger, never smaller 979 again. 981 o within each encoding size (0 bytes, 1 byte, etc.), lexicographical 982 ordering of the bytes is the same as numeric ordering 984 Obviously, there is only one encoding that satisfies all these 985 requirements. As illustrated by Figure 4, this is unambiguously 986 derived by 988 1. enumerating all possible byte sequences, ordered by length and 989 within the same length in lexicographic ordering, and, 991 2. assigning sequential cardinals. 993 0x'' -> 0 994 0x'00' -> 1 995 0x'01' -> 2 996 0x'02' -> 3 997 ... 998 0x'fe' -> 255 999 0x'ff' -> 256 1000 0x'0000' -> 257 1001 0x'0001' -> 258 1002 ... 1003 0x'fefd' -> 65534 1004 0x'fefe' -> 65535 1005 0x'feff' -> 65536 1006 ... 1007 0x'ffff' -> 65792 1008 0x'000000' -> 65793 1009 0x'000001' -> 65794 1011 Figure 4: Enumerating byte sequences by length and then lexicographic 1012 order 1014 This results in an exceedingly simple algorithm: each byte is 1015 interpreted in the base-256 place-value system, but stands for a 1016 number between 1 and 256 instead of 0 to 255. We therefore call this 1017 encoding "o256" (one-to-256). 0 is always encoded in zero bytes; 1 to 1018 256 is one byte, 257 (0x101) to 65792 (0x10100) is two bytes, 65793 1019 (0x10101) to 16843008 (0x1010100) is three bytes, etc. 1021 To further illustrate the algorithmic simplicity, pseudocode for 1022 encoding and decoding is given in Figure 5 and Figure 6, respectively 1023 (in the encoder, "prepend" stands for adding a byte at the _leading_ 1024 edge, the requirement for which is a result of the network byte 1025 order). Note that this differs only in a single subtraction/addition 1026 (resp.) of one from the canonical algorithm for Appendix A uints. 1028 while num > 0 1029 num -= 1 1030 prepend(num & 0xFF) 1031 num >>= 8 1032 end 1034 Figure 5: o256 encoder (pseudocode) 1036 num = 0 1037 each_byte do |b| 1038 num <<= 8 1039 num += b + 1 1040 end 1042 Figure 6: o256 decoder (pseudocode) 1044 On a more philosophical note, it can be observed that o256 solves the 1045 inverse problem of Self-Delimiting Numeric Values (SDNV) [RFC6256]: 1046 SDNV encodes variable-length numbers together with their length 1047 (allowing decoding without knowing their length in advance, deriving 1048 delimiting information from the number encoding). o256 encodes 1049 variable-length numbers when there is a way to separately convey the 1050 length (as in CoAP options), encoding (and later deriving) a small 1051 part of the numeric value into/from that size information. 1053 A.4. SMS encoding 1055 For use in SMS applications, CoAP messages can be transferred using 1056 SMS binary mode. However, there is operational experience showing 1057 that some environments cannot successfully send a binary mode SMS. 1059 For transferring SMS in character mode (7-bit characters), base64- 1060 encoding [RFC4648] is an obvious choice. 3 bytes of message (24 bits) 1061 turn into 4 characters, which cosume 28 bits. The overall overhead 1062 is approximately 17 %; the maximum message size is 120 bytes (160 SMS 1063 characters). 1065 If a more compact encoding is desired, base85 encoding can be 1066 employed (however, probably not the version defined in [RFC1924] -- 1067 instead, the version used in tools such as btoa and PDF should be 1068 chosen). However, this requires division operations. Also, the 1069 base85 character set includes several characters that cannot be 1070 transferred in a single 7-bit unit in SMS and/or are known to cause 1071 operational problems. A modified base85 character set can be defined 1072 to solve the latter problem. 4 bytes of message (32 bits) turn into 5 1073 characters, which consume 35 bits. The overall overhead is 1074 approximately 9.3 %; the resulting maximum message size is 128 bytes 1075 (160 SMS characters). 1077 Base64 and base85 do not make use of the fact that much CoAP data 1078 will be ASCII-based. Therefore, we define the following experimental 1079 SMS encoding. 1081 A.4.1. ASCII-optimized SMS encoding 1083 Not all 128 theoretically possible SMS characters are operationally 1084 free of problems. We therefore define: 1086 Shunned code characters: @ sign, as it maps to 0x00 1088 LF and CR signs (0x0A, 0x0D) 1090 uppercase C cedilla (0x09), as it is often mistranslated in 1091 gateways 1093 ESC (0x1B), as it is used in certain character combinations only 1095 Some ASCII characters cannot be transferred in the base SMS character 1096 set, as their code positions are taken by non-ASCII characters. 1097 These are simply encoded with their ASCII code positions, e.g., an 1098 underscore becomes a section mark (even though underscore has a 1099 different code position in the SMS character set). 1101 Equivalently translated input bytes: $, @, [, \, ], ^, _, `, {, |, 1102 }, ~, DEL 1104 In other words, bytes 0x20 to 0x7F are encoded into the same code 1105 positions in the 7-bit character set. 1107 Out of the remaining code characters, the following SMS characters 1108 are available for encoding: 1110 Non-equivalently translated (NET) code characters: 0x01 to 0x08, (8 1111 characters) 1113 0x0B, 0x0C, (2 characters) 1115 0x0E to 0x1A, (13 characters) 1117 0x1C to 0x1F, (4 characters) 1119 Of the 27 NET code characters, 18 are taken as prefix characters (see 1120 below), and 8 are defined as directly translated characters: 1122 Directly translated bytes: Equivalently translated input bytes are 1123 represented as themselves 1125 0x00 to 0x07 are represented as 0x01 to 0x08 1127 This leaves 0x08 to 0x1F and 0x80 to 0xFF. Of these, the bytes 0x80 1128 to 0x87 and 0xA0 to 0xFF are represented as the bytes 0x00 to 0x07 1129 (represented by characters 0x01 to 0x08) and 0x20 to 0x7F, with a 1130 prefix of 1 (see below). The characters 0x08 to 0x1F are represented 1131 as the characters 0x28 to 0x3F with a prefix of 2 (see below). The 1132 characters 0x88 to 0x9F are represented as the characters 0x48 to 1133 0x5F with a prefix of 2 (see below). (Characters 0x01 to 0x08, 0x20 1134 to 0x27, 0x40 to 0x47, and 0x60 to 0x7f with a prefix of 2 are 1135 reserved for future extensions, which could be used for some 1136 backreferencing or run-length compression.) 1138 Bytes that do not need a prefix (directly translated bytes) are sent 1139 as is. Any byte that does need a prefix (i.e., 1 or 2) is preceded 1140 by a prefix character, which provides a prefix for this and the 1141 following two bytes as follows: 1143 +------+-----+---+------+-----+ 1144 | 0x0B | 100 | | 0x15 | 200 | 1145 +------+-----+---+------+-----+ 1146 | 0x0C | 101 | | 0x16 | 201 | 1147 | | | | | | 1148 | 0x0E | 102 | | 0x17 | 202 | 1149 | | | | | | 1150 | 0x0F | 110 | | 0x18 | 210 | 1151 | | | | | | 1152 | 0x10 | 111 | | 0x19 | 211 | 1153 | | | | | | 1154 | 0x11 | 112 | | 0x1A | 212 | 1155 | | | | | | 1156 | 0x12 | 120 | | 0x1C | 220 | 1157 | | | | | | 1158 | 0x13 | 121 | | 0x1D | 221 | 1159 | | | | | | 1160 | 0x14 | 122 | | 0x1E | 222 | 1161 +------+-----+---+------+-----+ 1163 (This leaves one non-shunned character, 0x1F, for future extension.) 1165 The coding overhead of this encoding for random bytes is similar to 1166 Base85, without the need for a division/multiplication. For bytes 1167 that are mostly ASCII characters, the overhead can easily become 1168 negative. (Conversely, for bytes that are more likely to be non- 1169 ASCII than in a random sequence of bytes, the overhead becomes 1170 greater.) 1172 So, for instance, for the CoAP message in Figure 7: 1174 ver tt code mid 1175 1 ack 2.05 17033 1176 content_type 40 1177 token sometok 1178 3c 2f 3e 3b 74 69 74 6c 65 3d 22 47 65 6e 65 72 |;title="Gener| 1179 61 6c 20 49 6e 66 6f 22 3b 63 74 3d 30 2c 3c 2f |al Info";ct=0,;if="clock"| 1181 3b 72 74 3d 22 54 69 63 6b 73 22 3b 74 69 74 6c |;rt="Ticks";titl| 1182 65 3d 22 49 6e 74 65 72 6e 61 6c 20 43 6c 6f 63 |e="Internal Cloc| 1183 6b 22 3b 63 74 3d 30 2c 3c 2f 61 73 79 6e 63 3e |k";ct=0,| 1184 3b 63 74 3d 30 |;ct=0 | 1186 Figure 7: CoAP response message as captured and decoded 1188 The 116 byte unencoded message is shown as ASCII characters in 1189 Figure 8 (\xDD stands for the byte with the hex digits DD): 1191 bEB\x89\x11(\xA7sometok;title="General Info";ct=0, 1192 ;if="clock";rt="Ticks";title="Internal Clock";ct=0,;ct=0 1194 Figure 8: CoAP response message shown as unencoded characters 1196 The equivalent SMS encoding is shown as equivalent-coded SMS 1197 characters in Figure 9 (7 bits per character, \x12 is a 220 prefix 1198 and \x0B is a 100 prefix, the rest is shown in equivalent encoding), 1199 adding two characters of prefix overhead, for a total length of 118 1200 7-bit characters or 104 (103.25 plus padding) bytes: 1202 bEB\x12I1(\x0B'sometok;title="General Info";ct=0, 1203 ;if="clock";rt="Ticks";title="Internal Clock";ct=0,;ct=0 1205 Figure 9: CoAP response message shown as SMS-encoded characters 1207 Appendix B. The Cemetery (Things we won't do) 1209 This annex documents roads that the WG decided not to take, in order 1210 to spare readers from reinventing them in vain. 1212 B.1. Stateful URI compression 1214 Is the approximately 25 % average saving achievable with Huffman- 1215 based URI compression schemes worth the complexity? Probably not, 1216 because much higher average savings can be achieved by introducing 1217 state. 1219 Henning Schulzrinne has proposed for a server to be able to supply a 1220 shortened URI once a resource has been requested using the full- 1221 length URI. Let's call such a shortened referent a _Temporary 1222 Resource Identifier_, _TeRI_ for short. This could be expressed by a 1223 response option as shown in Figure 10. 1225 0 1226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | duration | TeRI... 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 Figure 10: Option for offering a TeRI in a response 1233 The TeRI offer option indicates that the server promises to offer 1234 this resources under the TeRI given for at least the time given as 1235 the duration. Another TeRI offer can be made later to extend the 1236 duration. 1238 Once a TeRI for a URI is known (and still within its lifetime), the 1239 client can supply a TeRI instead of a URI in its requests. The same 1240 option format as an offer could be used to allow the client to 1241 indicate how long it believes the TeRI will still be valid (so that 1242 the server can decide when to update the lifetime duration). TeRIs 1243 in requests could be distinguished from URIs e.g. by using a 1244 different option number. 1246 Proposal: Add a TeRI option that can be used in CoAP requests and 1247 responses. 1249 Add a way to indicate a TeRI and its duration in a link-value. 1251 Do not add any form of stateless URI encoding. 1253 Benefits: Much higher reduction of message size than any stateless 1254 URI encoding could achieve. 1256 As the use of TeRIs is entirely optional, minimal complexity nodes 1257 can get by without implementing them. 1259 Drawbacks: Adds considerable state and complexity to the protocol. 1261 It turns out that real CoAP URIs are short enough that TeRIs are 1262 not needed. 1264 (Discuss the security implications of TeRIs.) 1266 B.2. Beyond 270 bytes in a single option 1268 The authors would argue that 270 as the maximum length of an option 1269 is already beyond the "painless" threshold. 1271 If that is not the consensus of the WG, the scheme can easily be 1272 extended as in Figure 11: 1274 for 15..269: 1275 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1276 | Option Delta | 1 1 1 1 | Length - 15 | 1277 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1278 | Option Value ... 1279 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1281 for 270..65805: 1282 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1283 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 1284 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1285 | Length - 270 (in network byte order) | 1286 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1287 | Option Value ... 1288 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1290 Figure 11: Ridiculously Long Option Header 1292 The infinite number of obvious variations on this scheme are left as 1293 an exercise to the reader. 1295 Again, as a precaution to future extensions, the current encoding for 1296 length 270 (eight ones in the extension byte) could be marked as 1297 reserved today. 1299 B.3. Beyond 15 options 1301 (This section keeps discussion that is no longer needed as we have 1302 agreed to do what is documented in Appendix B.4). 1304 The limit of 15 options is motivated by the fixed four-bit field "OC" 1305 that is used for indicating the number of options in the fixed-length 1306 CoAP header (Figure 12). 1308 0 1 2 3 1309 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 |Ver| T | OC | Code | Message ID | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Options (if any) ... 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Payload (if any) ... 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 Figure 12: Four-byte fixed header in a CoAP Message 1320 Note that there is another fixed four-bit field in CoAP: the option 1321 length (Figure 13 - note that this figure is not to the same scale as 1322 the previous figure): 1324 0 1 2 3 4 5 6 7 1325 +---+---+---+---+---+---+---+---+ 1326 | Option Delta | Length | for 0..14 1327 +---+---+---+---+---+---+---+---+ 1328 | Option Value ... 1329 +---+---+---+---+---+---+---+---+ 1331 Figure 13: Short Option Header 1333 Since 15 is inacceptable for a maximum option length, the all-ones 1334 value (15) was taken out of the set of allowable values for the short 1335 header, and a long header was introduced that allows the insertion of 1336 an extension byte (Figure 14): 1338 for 15..270: 1339 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1340 | Option Delta | 1 1 1 1 | Length - 15 | 1341 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1342 | Option Value ... 1343 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1345 Figure 14: Long Option Header 1347 We might want to use the same technique for the CoAP header as well. 1348 There are two obvious places where the extension byte could be 1349 placed: 1351 1. right after the byte carrying the OC field, so the structure is 1352 the same as for the option header; 1354 2. right after the fixed-size CoAP header. 1356 Both solutions lose the fixed-size-ness of the CoAP header. 1358 Solution 1 has the disadvantage that the CoAP header is also changing 1359 in structure: The extension byte is wedged between the first and the 1360 second byte of the CoAP header. This is unfortunate, as the number 1361 of options only comes into play when the option processing begins, so 1362 it is more natural to use solution 2 (Figure 15): 1364 0 1 2 3 1365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 |Ver| T | 15 | Code | Message ID | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | OC - 15 | Options ... 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Payload (if any) ... 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 Figure 15: Extended header for CoAP Messages with 15+ options 1376 This would allow for up to 270 options in a CoAP message, which is 1377 very likely way beyond the "painless" threshold. 1379 B.3.1. Implementation considerations 1381 For a message decoder, this extension creates relatively little pain, 1382 as the number of options only becomes interesting when the encoding 1383 turns to the options part of the message, which is then simply lead 1384 in by the extension byte if the four-bit field is 15. 1386 For a message encoder, this extension is not so rosy. If the encoder 1387 is constructing the message serially, it may not know in advance 1388 whether the number of options will exceed 14. None of the following 1389 implementation strategies is particularly savory, but all of them do 1390 work: 1392 1. Encode the options serially under the assumption that the number 1393 of options will be 14 or less. When the 15th option needs to be 1394 encoded, abort the option encoding, and restart it from scratch 1395 one byte further to the left. 1397 2. Similar to 1, except that the bytes already encoded are all moved 1398 one byte to right, the extension byte is inserted, and the option 1399 encoding process is continued. 1401 3. The encoder always leaves space for the extension byte (at least 1402 if it can't prove the number will be less thatn 14). If the 1403 extension byte is not needed, an Option 0 with length 0 is 1404 encoded instead (i.e., one byte is wasted - this option is 1405 elective and will be ignored by the receiver). 1407 As a minimum, to enable strategy 3, the option 0 should be reserved 1408 at least for the case of length=0. 1410 B.3.2. What should we do now? 1412 As a minimum proposal for the next version of CoAP, the value 15 for 1413 OC should be marked as reserved today. 1415 B.3.3. Alternatives 1417 One alternative that has been discussed previously is to have an 1418 "Options" Option, which allows the carriage of multiple options in 1419 the belly of a single one. This could also be used to carry more 1420 than 15 options. However: 1422 o The conditional introduction of an Options option has 1423 implementation considerations that are likely to be more severe 1424 than the ones listed above; 1426 o since 270 bytes may not be enough for the encoding of _all_ 1427 options, the "Options" option would need to be repeatable. This 1428 creates many different ways to encode the same message, leading to 1429 combinatorial explosion in test cases for ensuring 1430 interoperability. 1432 B.3.4. Alternative: Going to a delimiter model 1434 Another alternative is to spend the additional byte not as an 1435 extended count, but as an option terminator. 1437 B.4. Implementing the option delimiter for 15 or more options 1438 Implementation note: As can be seen from the proof of concept code 1439 in Figure 16, the actual implementation cost for a decoder is 1440 around 4 lines of code (or about 8-10 machine code instructions). 1442 while numopt > 0 1443 nextbyte = ... get next byte 1445 if numopt == 15 # new 1446 break if nextbyte == 0xF0 # new 1447 else # new 1448 numopt -= 1 1449 end # new 1451 ... decode the delta and length from nextbyte and handle them 1452 end 1454 Figure 16: Implementing the Option Terminator 1456 Similarly, creating the option terminator needs about four more lines 1457 (not marked "old" in the C code in Figure 17). 1459 b0 = 0x40 + (tt << 4); /* old */ 1460 buffer[0] = b0 + 15; /* guess first byte */ 1462 .... encode options .... /* old */ 1464 if (option_count >= 15 || first_fragment_already_shipped) 1465 buffer[pos++] = 0xF0; /* use delimiter */ 1466 else /* save a byte: */ 1467 buffer[0] = b0 + option_count; /* old: backpatch */ 1469 Figure 17: Creating the Option Terminator 1471 Appendix C. Experimental Options 1473 This annex documents proposals that need significant additional 1474 discussion before they can become part of (or go back to) the main 1475 CoAP specification. They are not dead, but might die if there turns 1476 out to be no good way to solve the problem. 1478 C.1. Options indicating absolute time 1480 HTTP has a number of headers that may indicate absolute time: 1482 o "Date", defined in Section 14.18 in [RFC2616] (Section 9.3 in 1483 [I-D.ietf-httpbis-p1-messaging]), giving the absolute time a 1484 response was generated; 1486 o "Last-Modified", defined in Section 14.29 in [RFC2616], (Section 1487 6.6 in [I-D.ietf-httpbis-p4-conditional], giving the absolute time 1488 of when the origin server believes the resource representation was 1489 last modified; 1491 o "If-Modified-Since", defined in Section 14.25 in [RFC2616], 1492 "If-Unmodified-Since", defined in Section 14.28 in [RFC2616], and 1493 "If-Range", defined in Section 14.27 in [RFC2616] can be used to 1494 supply absolute time to gate a conditional request; 1496 o "Expires", defined in Section 14.21 in [RFC2616] (Section 3.3 in 1497 [I-D.ietf-httpbis-p6-cache]), giving the absolute time after which 1498 a response is considered stale. 1500 o The more obscure headers "Retry-After", defined in Section 14.37 1501 in [RFC2616], and "Warning", defined in section 14.46 in 1502 [RFC2616], also may employ absolute time. 1504 [I-D.ietf-core-coap] defines a single "Date" option, which however 1505 "indicates the creation time and date of a given resource 1506 representation", i.e., is closer to a "Last-Modified" HTTP header. 1507 HTTP's caching rules [I-D.ietf-httpbis-p6-cache] make use of both 1508 "Date" and "Last-Modified", combined with "Expires". The specific 1509 semantics required for CoAP needs further consideration. 1511 In addition to the definition of the semantics, an encoding for 1512 absolute times needs to be specified. 1514 In UNIX-related systems, it is customary to indicate absolute time as 1515 an integer number of seconds, after midnight UTC, January 1, 1970. 1516 Unless negative numbers are employed, this time format cannot 1517 represent time values prior to January 1, 1970, which probably is not 1518 required for the uses ob absolute time in CoAP. 1520 If a 32-bit integer is used and allowance is made for a sign-bit in a 1521 local implementation, the latest UTC time value that can be 1522 represented by the resulting 31 bit integer value is 03:14:07 on 1523 January 19, 2038. If the 32-bit integer is used as an unsigned 1524 value, the last date is 2106-02-07, 06:28:15. 1526 The reach can be extended by: - moving the epoch forward, e.g. by 40 1527 years (= 1262304000 seconds) to 2010-01-01. This makes it impossible 1528 to represent Last-Modified times in that past (such as could be 1529 gatewayed in from HTTP). - extending the number of bits, e.g. by one 1530 more byte, either always or as one of two formats, keeping the 32-bit 1531 variant as well. 1533 Also, the resolution can be extended by expressing time in 1534 milliseconds etc., requiring even more bits (e.g., a 48-bit unsigned 1535 integer of milliseconds would last well after year 9999.) 1537 For experiments, an experimental "Date" option is defined with the 1538 semantics of HTTP's "Last-Modified". It can carry an unsigned 1539 integer of 32, 40, or 48 bits; 32- and 40-bit integers indicate the 1540 absolute time in seconds since 1970-01-01 00:00 UTC, while 48-bit 1541 integers indicate the absolute time in milliseconds since 1970-01-01 1542 00:00 UTC. 1544 However, that option is not really that useful until there is a 1545 "If-Modified-Since" option as well. 1547 (Also: Discuss nodes without clocks.) 1549 C.2. Representing Durations 1551 Various message types used in CoAP need the representation of 1552 *durations*, i.e. of the length of a timespan. In SI units, these 1553 are measured in seconds. CoAP durations represent integer numbers of 1554 seconds, but instead of representing these numbers as integers, a 1555 more compact single-byte pseudo-floating-point (pseudo-FP) 1556 representation is used (Figure 18). 1558 0 1 2 3 4 5 6 7 1559 +---+---+---+---+---+---+---+---+ 1560 | 0... value | 1561 +---+---+---+---+---+---+---+---+ 1563 +---+---+---+---+---+---+---+---+ 1564 | 1... mantissa | exponent | 1565 +---+---+---+---+---+---+---+---+ 1566 Figure 18: Duration in (8,4) pseudo-FP representation 1568 If the high bit is clear, the entire n-bit value (including the high 1569 bit) is the decoded value. If the high bit is set, the mantissa 1570 (including the high bit, with the exponent field cleared out but 1571 still present) is shifted left by the exponent to yield the decoded 1572 value. 1574 The (n,e)-pseudo-FP format can be decoded with a single line of code 1575 (plus a couple of constant definitions), as demonstrated in 1576 Figure 19. 1578 #define N 8 1579 #define E 4 1580 #define HIBIT (1 << (N - 1)) 1581 #define EMASK ((1 << E) - 1) 1582 #define MMASK ((1 << N) - 1 - EMASK) 1584 #define DECODE_8_4(r) (r < HIBIT ? r : (r & MMASK) << (r & EMASK)) 1586 Figure 19: Decoding an (8,4) pseudo-FP value 1588 Note that a pseudo-FP encoder needs to consider rounding; different 1589 applications of durations may favor rounding up or rounding down the 1590 value encoded in the message. 1592 The highest pseudo-FP value, represented by an all-ones byte (0xFF), 1593 is reserved to indicate an indefinite duration. The next lower value 1594 (0xEF) is thus the highest representable value and is decoded as 1595 7340032 seconds, a little more than 12 weeks. 1597 C.3. Rationale 1599 Where CPU power and memory is abundant, a duration can almost always 1600 be adequately represented by a non-negative floating-point number 1601 representing that number of seconds. Historically, many APIs have 1602 also used an integer representation, which limits both the resolution 1603 (e.g., if the integer represents the duration in seconds) and often 1604 the range (integer machine types have range limits that may become 1605 relevant). UNIX's "time_t" (which is used for both absolute time and 1606 durations) originally was a signed 32-bit value of seconds, but was 1607 later complemented by an additional integer to add microsecond 1608 ("struct timeval") and then later nanosecond ("struct timespec") 1609 resolution. 1611 Three decisions need to be made for each application of the concept 1612 of duration: 1614 o the *resolution*. What rounding error is acceptable? 1616 o the *range*. What is the maximum duration that needs to be 1617 represented? 1619 o the *number of bits* that can be expended. 1621 Obviously, these decisions are interrelated. Typically, a large 1622 range needs a large number of bits, unless resolution is traded. For 1623 most applications, the actual requirement for resolution are limited 1624 for longer durations, but can be more acute for shorter durations. 1626 C.4. Pseudo-Floating Point 1628 Constrained systems typically avoid the use of floating-point (FP) 1629 values, as 1631 o simple CPUs often don't have support for floating-point datatypes 1633 o software floating-point libraries are expensive in code size and 1634 slow. 1636 In addition, floating-point datatypes used to be a significant 1637 element of market differentiation in CPU design; it has taken the 1638 industry a long time to agree on a standard floating point 1639 representation. 1641 These issues have led to protocols that try to constrain themselves 1642 to integer representation even where the ability of a floating point 1643 representation to trade range for resolution would be beneficial. 1645 The idea of introducing _pseudo-FP_ is to obtain the increased range 1646 provided by embedding an exponent, without necessarily getting stuck 1647 with hardware datatypes or inefficient software floating-point 1648 libraries. 1650 For the purposes of this draft, we define an (n,e)-pseudo-FP as a 1651 fixed-length value of n bits, e of which may be used for an exponent. 1652 Figure 18 illustrates an (8,4)-pseudo-FP value. 1654 If the high bit is clear, the entire n-bit value (including the high 1655 bit) is the decoded value. If the high bit is set, the mantissa 1656 (including the high bit, but with the exponent field cleared out) is 1657 shifted left by the exponent to yield the decoded value. 1659 The (n,e)-pseudo-FP format can be decoded with a single line of code 1660 (plus a couple of constant definition), as demonstrated in Figure 19. 1662 Only non-negative numbers can be represented by this format. It is 1663 designed to provide full integer resolution for values from 0 to 1664 2^(n-1)-1, i.e., 0 to 127 in the (8,4) case, and a mantissa of n-e 1665 bits from 2^(n-1) to (2^n-2^e)*2^(2^e-1), i.e., 128 to 7864320 in the 1666 (8,4) case. By choosing e carefully, resolution can be traded 1667 against range. 1669 Note that a pseudo-FP encoder needs to consider rounding; different 1670 applications of durations may favor rounding up or rounding down the 1671 value encoded in the message. This requires a little more than a 1672 single line of code (which is left as an exercise to the reader, as 1673 the most efficient expression depends on hardware details). 1675 C.5. A Duration Type for CoAP 1677 CoAP needs durations in a number of places. In [I-D.ietf-core-coap], 1678 durations occur in the option "Subscription-lifetime" as well as in 1679 the option "Max-age". (Note that the option "Date" is not a 1680 duration, but a point in time.) Other durations of this kind may be 1681 added later. 1683 Most durations relevant to CoAP are best expressed with a minimum 1684 resolution of one second. More detailed resolutions are unlikely to 1685 provide much benefit. 1687 The range of lifetimes and caching ages are probably best kept below 1688 the order of magnitude of months. An (8,4)-pseudo-FP has the maximum 1689 value of 7864320, which is about 91 days; this appears to be adequate 1690 for a subscription lifetime and probably even for a maximum cache 1691 age. Figure 20 shows the values that can be expressed. (If a larger 1692 range for the latter is indeed desired, an (8,5)-pseudo-FP could be 1693 used; this would last 15 milleniums, at the cost of having only 3 1694 bits of accuracy for values larger than 127 seconds.) 1696 Proposal: A single duration type is used throughout CoAP, based on 1697 an (8,4)-pseudo-FP giving a duration in seconds. 1699 Benefits: Implementations can use a single piece of code for 1700 managing all CoAP-related durations. 1702 In addition, length information never needs to be managed for 1703 durations that are embedded in other data structures: All 1704 durations are expressed by a single byte. 1706 It might be worthwhile to reserve one duration value, e.g. 0xFF, for 1707 an indefinite duration. 1709 Duration Seconds Encoded 1710 ----------- ---------- ------- 1711 00:00:00 0x00000000 0x00 1712 00:00:01 0x00000001 0x01 1713 00:00:02 0x00000002 0x02 1714 00:00:03 0x00000003 0x03 1715 00:00:04 0x00000004 0x04 1716 00:00:05 0x00000005 0x05 1717 00:00:06 0x00000006 0x06 1718 00:00:07 0x00000007 0x07 1719 00:00:08 0x00000008 0x08 1720 00:00:09 0x00000009 0x09 1721 00:00:10 0x0000000a 0x0a 1722 00:00:11 0x0000000b 0x0b 1723 00:00:12 0x0000000c 0x0c 1724 00:00:13 0x0000000d 0x0d 1725 00:00:14 0x0000000e 0x0e 1726 00:00:15 0x0000000f 0x0f 1727 00:00:16 0x00000010 0x10 1728 00:00:17 0x00000011 0x11 1729 00:00:18 0x00000012 0x12 1730 00:00:19 0x00000013 0x13 1731 00:00:20 0x00000014 0x14 1732 00:00:21 0x00000015 0x15 1733 00:00:22 0x00000016 0x16 1734 00:00:23 0x00000017 0x17 1735 00:00:24 0x00000018 0x18 1736 00:00:25 0x00000019 0x19 1737 00:00:26 0x0000001a 0x1a 1738 00:00:27 0x0000001b 0x1b 1739 00:00:28 0x0000001c 0x1c 1740 00:00:29 0x0000001d 0x1d 1741 00:00:30 0x0000001e 0x1e 1742 00:00:31 0x0000001f 0x1f 1743 00:00:32 0x00000020 0x20 1744 00:00:33 0x00000021 0x21 1745 00:00:34 0x00000022 0x22 1746 00:00:35 0x00000023 0x23 1747 00:00:36 0x00000024 0x24 1748 00:00:37 0x00000025 0x25 1749 00:00:38 0x00000026 0x26 1750 00:00:39 0x00000027 0x27 1751 00:00:40 0x00000028 0x28 1752 00:00:41 0x00000029 0x29 1753 00:00:42 0x0000002a 0x2a 1754 00:00:43 0x0000002b 0x2b 1755 00:00:44 0x0000002c 0x2c 1756 00:00:45 0x0000002d 0x2d 1757 00:00:46 0x0000002e 0x2e 1758 00:00:47 0x0000002f 0x2f 1759 00:00:48 0x00000030 0x30 1760 00:00:49 0x00000031 0x31 1761 00:00:50 0x00000032 0x32 1762 00:00:51 0x00000033 0x33 1763 00:00:52 0x00000034 0x34 1764 00:00:53 0x00000035 0x35 1765 00:00:54 0x00000036 0x36 1766 00:00:55 0x00000037 0x37 1767 00:00:56 0x00000038 0x38 1768 00:00:57 0x00000039 0x39 1769 00:00:58 0x0000003a 0x3a 1770 00:00:59 0x0000003b 0x3b 1771 00:01:00 0x0000003c 0x3c 1772 00:01:01 0x0000003d 0x3d 1773 00:01:02 0x0000003e 0x3e 1774 00:01:03 0x0000003f 0x3f 1775 00:01:04 0x00000040 0x40 1776 00:01:05 0x00000041 0x41 1777 00:01:06 0x00000042 0x42 1778 00:01:07 0x00000043 0x43 1779 00:01:08 0x00000044 0x44 1780 00:01:09 0x00000045 0x45 1781 00:01:10 0x00000046 0x46 1782 00:01:11 0x00000047 0x47 1783 00:01:12 0x00000048 0x48 1784 00:01:13 0x00000049 0x49 1785 00:01:14 0x0000004a 0x4a 1786 00:01:15 0x0000004b 0x4b 1787 00:01:16 0x0000004c 0x4c 1788 00:01:17 0x0000004d 0x4d 1789 00:01:18 0x0000004e 0x4e 1790 00:01:19 0x0000004f 0x4f 1791 00:01:20 0x00000050 0x50 1792 00:01:21 0x00000051 0x51 1793 00:01:22 0x00000052 0x52 1794 00:01:23 0x00000053 0x53 1795 00:01:24 0x00000054 0x54 1796 00:01:25 0x00000055 0x55 1797 00:01:26 0x00000056 0x56 1798 00:01:27 0x00000057 0x57 1799 00:01:28 0x00000058 0x58 1800 00:01:29 0x00000059 0x59 1801 00:01:30 0x0000005a 0x5a 1802 00:01:31 0x0000005b 0x5b 1803 00:01:32 0x0000005c 0x5c 1804 00:01:33 0x0000005d 0x5d 1805 00:01:34 0x0000005e 0x5e 1806 00:01:35 0x0000005f 0x5f 1807 00:01:36 0x00000060 0x60 1808 00:01:37 0x00000061 0x61 1809 00:01:38 0x00000062 0x62 1810 00:01:39 0x00000063 0x63 1811 00:01:40 0x00000064 0x64 1812 00:01:41 0x00000065 0x65 1813 00:01:42 0x00000066 0x66 1814 00:01:43 0x00000067 0x67 1815 00:01:44 0x00000068 0x68 1816 00:01:45 0x00000069 0x69 1817 00:01:46 0x0000006a 0x6a 1818 00:01:47 0x0000006b 0x6b 1819 00:01:48 0x0000006c 0x6c 1820 00:01:49 0x0000006d 0x6d 1821 00:01:50 0x0000006e 0x6e 1822 00:01:51 0x0000006f 0x6f 1823 00:01:52 0x00000070 0x70 1824 00:01:53 0x00000071 0x71 1825 00:01:54 0x00000072 0x72 1826 00:01:55 0x00000073 0x73 1827 00:01:56 0x00000074 0x74 1828 00:01:57 0x00000075 0x75 1829 00:01:58 0x00000076 0x76 1830 00:01:59 0x00000077 0x77 1831 00:02:00 0x00000078 0x78 1832 00:02:01 0x00000079 0x79 1833 00:02:02 0x0000007a 0x7a 1834 00:02:03 0x0000007b 0x7b 1835 00:02:04 0x0000007c 0x7c 1836 00:02:05 0x0000007d 0x7d 1837 00:02:06 0x0000007e 0x7e 1838 00:02:07 0x0000007f 0x7f 1839 00:02:08 0x00000080 0x80 1840 00:02:24 0x00000090 0x90 1841 00:02:40 0x000000a0 0xa0 1842 00:02:56 0x000000b0 0xb0 1843 00:03:12 0x000000c0 0xc0 1844 00:03:28 0x000000d0 0xd0 1845 00:03:44 0x000000e0 0xe0 1846 00:04:00 0x000000f0 0xf0 1847 00:04:16 0x00000100 0x81 1848 00:04:48 0x00000120 0x91 1849 00:05:20 0x00000140 0xa1 1850 00:05:52 0x00000160 0xb1 1851 00:06:24 0x00000180 0xc1 1852 00:06:56 0x000001a0 0xd1 1853 00:07:28 0x000001c0 0xe1 1854 00:08:00 0x000001e0 0xf1 1855 00:08:32 0x00000200 0x82 1856 00:09:36 0x00000240 0x92 1857 00:10:40 0x00000280 0xa2 1858 00:11:44 0x000002c0 0xb2 1859 00:12:48 0x00000300 0xc2 1860 00:13:52 0x00000340 0xd2 1861 00:14:56 0x00000380 0xe2 1862 00:16:00 0x000003c0 0xf2 1863 00:17:04 0x00000400 0x83 1864 00:19:12 0x00000480 0x93 1865 00:21:20 0x00000500 0xa3 1866 00:23:28 0x00000580 0xb3 1867 00:25:36 0x00000600 0xc3 1868 00:27:44 0x00000680 0xd3 1869 00:29:52 0x00000700 0xe3 1870 00:32:00 0x00000780 0xf3 1871 00:34:08 0x00000800 0x84 1872 00:38:24 0x00000900 0x94 1873 00:42:40 0x00000a00 0xa4 1874 00:46:56 0x00000b00 0xb4 1875 00:51:12 0x00000c00 0xc4 1876 00:55:28 0x00000d00 0xd4 1877 00:59:44 0x00000e00 0xe4 1878 01:04:00 0x00000f00 0xf4 1879 01:08:16 0x00001000 0x85 1880 01:16:48 0x00001200 0x95 1881 01:25:20 0x00001400 0xa5 1882 01:33:52 0x00001600 0xb5 1883 01:42:24 0x00001800 0xc5 1884 01:50:56 0x00001a00 0xd5 1885 01:59:28 0x00001c00 0xe5 1886 02:08:00 0x00001e00 0xf5 1887 02:16:32 0x00002000 0x86 1888 02:33:36 0x00002400 0x96 1889 02:50:40 0x00002800 0xa6 1890 03:07:44 0x00002c00 0xb6 1891 03:24:48 0x00003000 0xc6 1892 03:41:52 0x00003400 0xd6 1893 03:58:56 0x00003800 0xe6 1894 04:16:00 0x00003c00 0xf6 1895 04:33:04 0x00004000 0x87 1896 05:07:12 0x00004800 0x97 1897 05:41:20 0x00005000 0xa7 1898 06:15:28 0x00005800 0xb7 1899 06:49:36 0x00006000 0xc7 1900 07:23:44 0x00006800 0xd7 1901 07:57:52 0x00007000 0xe7 1902 08:32:00 0x00007800 0xf7 1903 09:06:08 0x00008000 0x88 1904 10:14:24 0x00009000 0x98 1905 11:22:40 0x0000a000 0xa8 1906 12:30:56 0x0000b000 0xb8 1907 13:39:12 0x0000c000 0xc8 1908 14:47:28 0x0000d000 0xd8 1909 15:55:44 0x0000e000 0xe8 1910 17:04:00 0x0000f000 0xf8 1911 18:12:16 0x00010000 0x89 1912 20:28:48 0x00012000 0x99 1913 22:45:20 0x00014000 0xa9 1914 1d 01:01:52 0x00016000 0xb9 1915 1d 03:18:24 0x00018000 0xc9 1916 1d 05:34:56 0x0001a000 0xd9 1917 1d 07:51:28 0x0001c000 0xe9 1918 1d 10:08:00 0x0001e000 0xf9 1919 1d 12:24:32 0x00020000 0x8a 1920 1d 16:57:36 0x00024000 0x9a 1921 1d 21:30:40 0x00028000 0xaa 1922 2d 02:03:44 0x0002c000 0xba 1923 2d 06:36:48 0x00030000 0xca 1924 2d 11:09:52 0x00034000 0xda 1925 2d 15:42:56 0x00038000 0xea 1926 2d 20:16:00 0x0003c000 0xfa 1927 3d 00:49:04 0x00040000 0x8b 1928 3d 09:55:12 0x00048000 0x9b 1929 3d 19:01:20 0x00050000 0xab 1930 4d 04:07:28 0x00058000 0xbb 1931 4d 13:13:36 0x00060000 0xcb 1932 4d 22:19:44 0x00068000 0xdb 1933 5d 07:25:52 0x00070000 0xeb 1934 5d 16:32:00 0x00078000 0xfb 1935 6d 01:38:08 0x00080000 0x8c 1936 6d 19:50:24 0x00090000 0x9c 1937 7d 14:02:40 0x000a0000 0xac 1938 8d 08:14:56 0x000b0000 0xbc 1939 9d 02:27:12 0x000c0000 0xcc 1940 9d 20:39:28 0x000d0000 0xdc 1941 10d 14:51:44 0x000e0000 0xec 1942 11d 09:04:00 0x000f0000 0xfc 1943 12d 03:16:16 0x00100000 0x8d 1944 13d 15:40:48 0x00120000 0x9d 1945 15d 04:05:20 0x00140000 0xad 1946 16d 16:29:52 0x00160000 0xbd 1947 18d 04:54:24 0x00180000 0xcd 1948 19d 17:18:56 0x001a0000 0xdd 1949 21d 05:43:28 0x001c0000 0xed 1950 22d 18:08:00 0x001e0000 0xfd 1951 24d 06:32:32 0x00200000 0x8e 1952 27d 07:21:36 0x00240000 0x9e 1953 30d 08:10:40 0x00280000 0xae 1954 33d 08:59:44 0x002c0000 0xbe 1955 36d 09:48:48 0x00300000 0xce 1956 39d 10:37:52 0x00340000 0xde 1957 42d 11:26:56 0x00380000 0xee 1958 45d 12:16:00 0x003c0000 0xfe 1959 48d 13:05:04 0x00400000 0x8f 1960 54d 14:43:12 0x00480000 0x9f 1961 60d 16:21:20 0x00500000 0xaf 1962 66d 17:59:28 0x00580000 0xbf 1963 72d 19:37:36 0x00600000 0xcf 1964 78d 21:15:44 0x00680000 0xdf 1965 84d 22:53:52 0x00700000 0xef 1966 91d 00:32:00 0x00780000 0xff (reserved) 1968 Figure 20 1970 Authors' Addresses 1972 Carsten Bormann 1973 Universitaet Bremen TZI 1974 Postfach 330440 1975 Bremen D-28359 1976 Germany 1978 Phone: +49-421-218-63921 1979 Fax: +49-421-218-7000 1980 Email: cabo@tzi.org 1982 Klaus Hartke 1983 Universitaet Bremen TZI 1984 Postfach 330440 1985 Bremen D-28359 1986 Germany 1988 Phone: +49-421-218-63905 1989 Fax: +49-421-218-7000 1990 Email: hartke@tzi.org