idnits 2.17.1 draft-bormann-coap-misc-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 14, 2011) is 4790 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 ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-observe' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 328, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-05 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-13 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-13 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-13 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 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: September 15, 2011 March 14, 2011 7 Miscellaneous additions to CoAP 8 draft-bormann-coap-misc-07 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 September 15, 2011. 35 Copyright Notice 37 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Accept Option . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. 4.06 Not Acceptable . . . . . . . . . . . . . . . . . . . 5 56 3. URI Authorities with Binary Adresses . . . . . . . . . . . . . 6 57 4. User-defined Option . . . . . . . . . . . . . . . . . . . . . 8 58 5. Payload-Length Option . . . . . . . . . . . . . . . . . . . . 9 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 65 Appendix A. The Cemetery (Things we won't do) . . . . . . . . . . 15 66 A.1. Stateful URI compression . . . . . . . . . . . . . . . . . 15 67 Appendix B. Experimental Options . . . . . . . . . . . . . . . . 17 68 B.1. Options indicating absolute time . . . . . . . . . . . . . 17 69 B.2. Representing Durations . . . . . . . . . . . . . . . . . . 18 70 B.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 19 71 B.4. Pseudo-Floating Point . . . . . . . . . . . . . . . . . . 20 72 B.5. A Duration Type for CoAP . . . . . . . . . . . . . . . . . 21 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 75 1. Introduction 77 The CoRE WG is tasked with standardizing an Application Protocol for 78 Constrained Networks/Nodes, CoAP [I-D.ietf-core-coap]. This protocol 79 is intended to provide RESTful [REST] services not unlike HTTP 80 [RFC2616], while reducing the complexity of implementation as well as 81 the size of packets exchanged in order to make these services useful 82 in a highly constrained network of themselves highly constrained 83 nodes. 85 This objective requires restraint in a number of sometimes 86 conflicting ways: 88 o reducing implementation complexity in order to minimize code size, 90 o reducing message sizes in order to minimize the number of 91 fragments needed for each message (in turn to maximize the 92 probability of delivery of the message), the amount of 93 transmission power needed and the loading of the limited-bandwidth 94 channel, 96 o reducing requirements on the environment such as stable storage, 97 good sources of randomness or user interaction capabilities. 99 This draft attempts to address a number of problems not yet 100 adequately solved in [I-D.ietf-core-coap]. The solutions proposed to 101 these problems are somewhat interrelated and are therefore presented 102 in one draft. 104 The appendix contains the "CoAP cemetery" (possibly later to move 105 into its own draft), documenting roads that the WG decided not to 106 take, in order to spare readers from reinventing them in vain. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in {RFC2119}}. 112 The term "byte" is used in its now customary sense as a synonym for 113 "octet". 115 2. Content Negotiation 117 A resource may be available in a number of representations. Without 118 some information from the client, a server has no easy way to decide 119 which of these would be best served. HTTP [RFC2616] has an Accept: 120 request header that a client can use to indicate the media types 121 supported, allowing the server to decide. This header is somewhat 122 unpopular as, for a web browser, there are too many media types to 123 choose from, so -- even with wildcards -- there is no meaningful 124 information to put there. (This has changed a bit for AJAX calls, 125 which may indeed have a specific media type preference.) It is 126 unlikely that machine-to-machine communication would have the same 127 problem. 129 A similar function to the HTTP Accept: header could be added to CoAP 130 as an option in a much simpler way. The CoAP Accept option would 131 when included one or more times in a request, carry one or more media 132 types, each of which is an acceptable media type for the client, in 133 the order of preference. If no Accept option is given, the client 134 does not express a preference. 136 Depending on whether the Accept Option is defined as a critical or an 137 elective option, the meaning of the option is slightly different: 139 Critical: The client is not interested in a representation of the 140 resource if the server is unable or unwilling to return it in one 141 of the specified media types. (For this purpose, a new response 142 code, 4.06 Not Acceptable, is needed.) 144 Elective: The client prefers the representation returned by the 145 server to be in one of the media types, but is willing to accept 146 the response also if the server returns a representation in a 147 different media type. 149 2.1. Accept Option 151 +-----+----------+---------------+--------+--------+---------+ 152 | No. | C/E | Name | Format | Length | Default | 153 +-----+----------+---------------+--------+--------+---------+ 154 | TBD | Critical | Accept.Only | uint | 0-2 B | (none) | 155 | | | | | | | 156 | TBD | Elective | Accept.Prefer | uint | 0-2 B | (none) | 157 +-----+----------+---------------+--------+--------+---------+ 159 TODO: Decide which of these options we need, or whether both should 160 be available. 162 2.2. 4.06 Not Acceptable 164 Like HTTP 406 "Not Acceptable", but with a human-readable diagnostic 165 message instead of a representation containing a list of available 166 representation characteristics and location(s). 168 3. URI Authorities with Binary Adresses 170 One problem with the way URI authorities are represented in the URI 171 syntax is that the authority part can be very bulky if it encodes an 172 IPv6 address in ASCII. 174 Proposal: Provide an option "Uri-Authority-Binary" that can be an 175 even number of bytes between 2 and 18 except 12 or 14. 177 o If the number of bytes is 2, the destination IP address of the 178 packet transporting the CoAP message is implied. 180 o If the number of bytes is 4 or 6, the first four bytes of the 181 option value are an IPv4 address in binary. 183 o If the number of bytes is 8 or 10, the first eight bytes are the 184 lower 64 bits of an IPv6 address; the upper eight bytes are 185 implied from the destination address of the packet transporting 186 the CoAP message. 188 o If the number of bytes is 16 or 18, the first 16 bytes are an IPv6 189 address. 191 o If two more bytes remain, this is a port number (as always in 192 network byte order). 194 The resulting authority is (conceptually translated into ASCII and) 195 used in place of an Uri-Authority option, or inserted into a Proxy- 196 Uri. Examples: 198 +-------------+------------------+---------+------------------------+ 199 | Proxy-Uri | Uri-Authority-Bi | Uri-Pat | URI | 200 | | nary | h | | 201 +-------------+------------------+---------+------------------------+ 202 | (none) | (none) | (none) | "/" | 203 | | | | | 204 | (none) | (none) | 'temp' | "/temp" | 205 | | | | | 206 | (none) | 2 bytes: 61616 | 'temp' | "coap://[DA]:61616/tem | 207 | | | | p" | 208 | | | | | 209 | (none) | 16 bytes: | temp | "coap://[2000::1]/temp | 210 | | 2000::1 | | " | 211 | | | | | 212 | 'http://' | 10 bytes: | (none) | "http://[DA::123:45]:6 | 213 | | ::123:45 + 616 | | 16" | 214 | | | | | 215 | 'http:///te | 18 bytes: | (none) | "http://[2000::1]:616/ | 216 | mp' | 2000::1 + 616 | | temp" | 217 +-------------+------------------+---------+------------------------+ 219 4. User-defined Option 221 To enable experimentation and community-specific options, option 222 number 14 (the first NOP option) can also be used as a user-defined 223 option. For this application, the option value has one or more 224 bytes, the semantics of which are defined by prior agreement between 225 the communicating partners. 227 It is RECOMMENDED to start the option value with a unique identifier, 228 e.g., the SDNV [RFC5050] of the enterprise number of the organisation 229 defining the option, possibly followed by additional discriminating 230 bits or bytes. 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |1 0 0 0 0 0 0 1|0 1 1 1 0 0 1 1| private opt-id| value... | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 \___SDNV of enterprise number___/ 237 Figure 1: Example option value for user-defined option 239 User-defined Options are elective. 241 The User-defined Option is repeatable. 243 Potential options: 245 +-----+----------+------+-------------+---------+---------+ 246 | No. | C/E | Name | Format | Length | Default | 247 +-----+----------+------+-------------+---------+---------+ 248 | 14 | Elective | User | (see below) | 1-270 B | (empty) | 249 +-----+----------+------+-------------+---------+---------+ 251 5. Payload-Length Option 253 Not all transport mappings may provide an unambiguous length of the 254 CoAP message. For UDP, it may also be desirable to pack more than 255 one CoAP message into one UDP payload (aggregation); in that case, 256 for all but the last message there needs to be a way to delimit the 257 payload of that message. 259 This can be solved using a new option, the Payload-Length option. If 260 this option is present, the value of this option is an unsigned 261 integer giving the length of the payload of the message (note that 262 this integer can be zero for a zero-length payload, which can in turn 263 be represented by a zero-length option value). (In the UDP 264 aggregation case, what would have been in the payload of this message 265 after "payload-length" bytes is then actually one or more additional 266 messages.) 268 6. IANA Considerations 270 This draft adds option numbers to Table 2 of [I-D.ietf-core-coap], 271 resulting in: 273 TBD. 275 7. Security Considerations 277 TBD. 279 8. Acknowledgements 281 This work was partially funded by the Klaus Tschira Foundation. 283 Of course, much of the content of this draft is the result of 284 discussions with the [I-D.ietf-core-coap] authors. 286 9. References 288 9.1. Normative References 290 [I-D.ietf-core-coap] 291 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 292 "Constrained Application Protocol (CoAP)", 293 draft-ietf-core-coap-05 (work in progress), March 2011. 295 [I-D.ietf-core-observe] 296 Hartke, K. and Z. Shelby, "Observing Resources in CoAP", 297 draft-ietf-core-observe-01 (work in progress), 298 February 2011. 300 [I-D.ietf-httpbis-p1-messaging] 301 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 302 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 303 "HTTP/1.1, part 1: URIs, Connections, and Message 304 Parsing", draft-ietf-httpbis-p1-messaging-13 (work in 305 progress), March 2011. 307 [I-D.ietf-httpbis-p4-conditional] 308 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 309 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 310 "HTTP/1.1, part 4: Conditional Requests", 311 draft-ietf-httpbis-p4-conditional-13 (work in progress), 312 March 2011. 314 [I-D.ietf-httpbis-p6-cache] 315 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 316 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 317 "HTTP/1.1, part 6: Caching", 318 draft-ietf-httpbis-p6-cache-13 (work in progress), 319 March 2011. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 325 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 326 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 328 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 329 Resource Identifier (URI): Generic Syntax", STD 66, 330 RFC 3986, January 2005. 332 9.2. Informative References 334 [REST] Fielding, R., "Architectural Styles and the Design of 335 Network-based Software Architectures", 2000. 337 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 338 Specification", RFC 5050, November 2007. 340 Appendix A. The Cemetery (Things we won't do) 342 This annex documents roads that the WG decided not to take, in order 343 to spare readers from reinventing them in vain. 345 A.1. Stateful URI compression 347 Is the approximately 25 % average saving achievable with Huffman- 348 based URI compression schemes worth the complexity? Probably not, 349 because much higher average savings can be achieved by introducing 350 state. 352 Henning Schulzrinne has proposed for a server to be able to supply a 353 shortened URI once a resource has been requested using the full- 354 length URI. Let's call such a shortened referent a _Temporary 355 Resource Identifier_, _TeRI_ for short. This could be expressed by a 356 response option as shown in Figure 2. 358 0 359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | duration | TeRI... 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 2: Option for offering a TeRI in a response 366 The TeRI offer option indicates that the server promises to offer 367 this resources under the TeRI given for at least the time given as 368 the duration. Another TeRI offer can be made later to extend the 369 duration. 371 Once a TeRI for a URI is known (and still within its lifetime), the 372 client can supply a TeRI instead of a URI in its requests. The same 373 option format as an offer could be used to allow the client to 374 indicate how long it believes the TeRI will still be valid (so that 375 the server can decide when to update the lifetime duration). TeRIs 376 in requests could be distinguished from URIs e.g. by using a 377 different option number. 379 Proposal: Add a TeRI option that can be used in CoAP requests and 380 responses. 382 Add a way to indicate a TeRI and its duration in a link-value. 384 Do not add any form of stateless URI encoding. 386 Benefits: Much higher reduction of message size than any stateless 387 URI encoding could achieve. 389 As the use of TeRIs is entirely optional, minimal complexity nodes 390 can get by without implementing them. 392 Drawbacks: Adds considerable state and complexity to the protocol. 394 It turns out that real CoAP URIs are short enough that TeRIs are 395 not needed. 397 (Discuss the security implications of TeRIs.) 399 Appendix B. Experimental Options 401 This annex documents proposals that need significant additional 402 discussion before they can become part of (or go back to) the main 403 CoAP specification. They are not dead, but might die if there turns 404 out to be no good way to solve the problem. 406 B.1. Options indicating absolute time 408 HTTP has a number of headers that may indicate absolute time: 410 o "Date", defined in Section 14.18 in [RFC2616] (Section 9.3 in 411 [I-D.ietf-httpbis-p1-messaging]), giving the absolute time a 412 response was generated; 414 o "Last-Modified", defined in Section 14.29 in [RFC2616], (Section 415 6.6 in [I-D.ietf-httpbis-p4-conditional], giving the absolute time 416 of when the origin server believes the resource representation was 417 last modified; 419 o "If-Modified-Since", defined in Section 14.25 in [RFC2616], 420 "If-Unmodified-Since", defined in Section 14.28 in [RFC2616], and 421 "If-Range", defined in Section 14.27 in [RFC2616] can be used to 422 supply absolute time to gate a conditional request; 424 o "Expires", defined in Section 14.21 in [RFC2616] (Section 3.3 in 425 [I-D.ietf-httpbis-p6-cache]), giving the absolute time after which 426 a response is considered stale. 428 o The more obscure headers "Retry-After", defined in Section 14.37 429 in [RFC2616], and "Warning", defined in section 14.46 in 430 [RFC2616], also may employ absolute time. 432 [I-D.ietf-core-coap] defines a single "Date" option, which however 433 "indicates the creation time and date of a given resource 434 representation", i.e., is closer to a "Last-Modified" HTTP header. 435 HTTP's caching rules [I-D.ietf-httpbis-p6-cache] make use of both 436 "Date" and "Last-Modified", combined with "Expires". The specific 437 semantics required for CoAP needs further consideration. 439 In addition to the definition of the semantics, an encoding for 440 absolute times needs to be specified. 442 In UNIX-related systems, it is customary to indicate absolute time as 443 an integer number of seconds, after midnight UTC, January 1, 1970. 444 Unless negative numbers are employed, this time format cannot 445 represent time values prior to January 1, 1970, which probably is not 446 required for the uses ob absolute time in CoAP. 448 If a 32-bit integer is used and allowance is made for a sign-bit in a 449 local implementation, the latest UTC time value that can be 450 represented by the resulting 31 bit integer value is 03:14:07 on 451 January 19, 2038. If the 32-bit integer is used as an unsigned 452 value, the last date is 2106-02-07, 06:28:15. 454 The reach can be extended by: - moving the epoch forward, e.g. by 40 455 years (= 1262304000 seconds) to 2010-01-01. This makes it impossible 456 to represent Last-Modified times in that past (such as could be 457 gatewayed in from HTTP). - extending the number of bits, e.g. by one 458 more byte, either always or as one of two formats, keeping the 32-bit 459 variant as well. 461 Also, the resolution can be extended by expressing time in 462 milliseconds etc., requiring even more bits (e.g., a 48-bit unsigned 463 integer of milliseconds would last well after year 9999.) 465 For experiments, an experimental "Date" option is defined with the 466 semantics of HTTP's "Last-Modified". It can carry an unsigned 467 integer of 32, 40, or 48 bits; 32- and 40-bit integers indicate the 468 absolute time in seconds since 1970-01-01 00:00 UTC, while 48-bit 469 integers indicate the absolute time in milliseconds since 1970-01-01 470 00:00 UTC. 472 However, that option is not really that useful until there is a 473 "If-Modified-Since" option as well. 475 (Also: Discuss nodes without clocks.) 477 B.2. Representing Durations 479 Various message types used in CoAP need the representation of 480 *durations*, i.e. of the length of a timespan. In SI units, these 481 are measured in seconds. CoAP durations represent integer numbers of 482 seconds, but instead of representing these numbers as integers, a 483 more compact single-byte pseudo-floating-point (pseudo-FP) 484 representation is used (Figure 3). 486 0 1 2 3 4 5 6 7 487 +---+---+---+---+---+---+---+---+ 488 | 0... value | 489 +---+---+---+---+---+---+---+---+ 491 +---+---+---+---+---+---+---+---+ 492 | 1... mantissa | exponent | 493 +---+---+---+---+---+---+---+---+ 494 Figure 3: Duration in (8,4) pseudo-FP representation 496 If the high bit is clear, the entire n-bit value (including the high 497 bit) is the decoded value. If the high bit is set, the mantissa 498 (including the high bit, with the exponent field cleared out but 499 still present) is shifted left by the exponent to yield the decoded 500 value. 502 The (n,e)-pseudo-FP format can be decoded with a single line of code 503 (plus a couple of constant definitions), as demonstrated in Figure 4. 505 #define N 8 506 #define E 4 507 #define HIBIT (1 << (N - 1)) 508 #define EMASK ((1 << E) - 1) 509 #define MMASK ((1 << N) - 1 - EMASK) 511 #define DECODE_8_4(r) (r < HIBIT ? r : (r & MMASK) << (r & EMASK)) 513 Figure 4: Decoding an (8,4) pseudo-FP value 515 Note that a pseudo-FP encoder needs to consider rounding; different 516 applications of durations may favor rounding up or rounding down the 517 value encoded in the message. 519 The highest pseudo-FP value, represented by an all-ones byte (0xFF), 520 is reserved to indicate an indefinite duration. The next lower value 521 (0xEF) is thus the highest representable value and is decoded as 522 7340032 seconds, a little more than 12 weeks. 524 B.3. Rationale 526 Where CPU power and memory is abundant, a duration can almost always 527 be adequately represented by a non-negative floating-point number 528 representing that number of seconds. Historically, many APIs have 529 also used an integer representation, which limits both the resolution 530 (e.g., if the integer represents the duration in seconds) and often 531 the range (integer machine types have range limits that may become 532 relevant). UNIX's "time_t" (which is used for both absolute time and 533 durations) originally was a signed 32-bit value of seconds, but was 534 later complemented by an additional integer to add microsecond 535 ("struct timeval") and then later nanosecond ("struct timespec") 536 resolution. 538 Three decisions need to be made for each application of the concept 539 of duration: 541 o the *resolution*. What rounding error is acceptable? 543 o the *range*. What is the maximum duration that needs to be 544 represented? 546 o the *number of bits* that can be expended. 548 Obviously, these decisions are interrelated. Typically, a large 549 range needs a large number of bits, unless resolution is traded. For 550 most applications, the actual requirement for resolution are limited 551 for longer durations, but can be more acute for shorter durations. 553 B.4. Pseudo-Floating Point 555 Constrained systems typically avoid the use of floating-point (FP) 556 values, as 558 o simple CPUs often don't have support for floating-point datatypes 560 o software floating-point libraries are expensive in code size and 561 slow. 563 In addition, floating-point datatypes used to be a significant 564 element of market differentiation in CPU design; it has taken the 565 industry a long time to agree on a standard floating point 566 representation. 568 These issues have led to protocols that try to constrain themselves 569 to integer representation even where the ability of a floating point 570 representation to trade range for resolution would be beneficial. 572 The idea of introducing _pseudo-FP_ is to obtain the increased range 573 provided by embedding an exponent, without necessarily getting stuck 574 with hardware datatypes or inefficient software floating-point 575 libraries. 577 For the purposes of this draft, we define an (n,e)-pseudo-FP as a 578 fixed-length value of n bits, e of which may be used for an exponent. 579 Figure 3 illustrates an (8,4)-pseudo-FP value. 581 If the high bit is clear, the entire n-bit value (including the high 582 bit) is the decoded value. If the high bit is set, the mantissa 583 (including the high bit, but with the exponent field cleared out) is 584 shifted left by the exponent to yield the decoded value. 586 The (n,e)-pseudo-FP format can be decoded with a single line of code 587 (plus a couple of constant definition), as demonstrated in Figure 4. 589 Only non-negative numbers can be represented by this format. It is 590 designed to provide full integer resolution for values from 0 to 591 2^(n-1)-1, i.e., 0 to 127 in the (8,4) case, and a mantissa of n-e 592 bits from 2^(n-1) to (2^n-2^e)*2^(2^e-1), i.e., 128 to 7864320 in the 593 (8,4) case. By choosing e carefully, resolution can be traded 594 against range. 596 Note that a pseudo-FP encoder needs to consider rounding; different 597 applications of durations may favor rounding up or rounding down the 598 value encoded in the message. This requires a little more than a 599 single line of code (which is left as an exercise to the reader, as 600 the most efficient expression depends on hardware details). 602 B.5. A Duration Type for CoAP 604 CoAP needs durations in a number of places. In [I-D.ietf-core-coap], 605 durations occur in the option "Subscription-lifetime" as well as in 606 the option "Max-age". (Note that the option "Date" is not a 607 duration, but a point in time.) Other durations of this kind may be 608 added later. 610 Most durations relevant to CoAP are best expressed with a minimum 611 resolution of one second. More detailed resolutions are unlikely to 612 provide much benefit. 614 The range of lifetimes and caching ages are probably best kept below 615 the order of magnitude of months. An (8,4)-pseudo-FP has the maximum 616 value of 7864320, which is about 91 days; this appears to be adequate 617 for a subscription lifetime and probably even for a maximum cache 618 age. Figure 5 shows the values that can be expressed. (If a larger 619 range for the latter is indeed desired, an (8,5)-pseudo-FP could be 620 used; this would last 15 milleniums, at the cost of having only 3 621 bits of accuracy for values larger than 127 seconds.) 623 Proposal: A single duration type is used throughout CoAP, based on 624 an (8,4)-pseudo-FP giving a duration in seconds. 626 Benefits: Implementations can use a single piece of code for 627 managing all CoAP-related durations. 629 In addition, length information never needs to be managed for 630 durations that are embedded in other data structures: All 631 durations are expressed by a single byte. 633 It might be worthwhile to reserve one duration value, e.g. 0xFF, for 634 an indefinite duration. 636 Duration Seconds Encoded 637 ----------- ---------- ------- 638 00:00:00 0x00000000 0x00 639 00:00:01 0x00000001 0x01 640 00:00:02 0x00000002 0x02 641 00:00:03 0x00000003 0x03 642 00:00:04 0x00000004 0x04 643 00:00:05 0x00000005 0x05 644 00:00:06 0x00000006 0x06 645 00:00:07 0x00000007 0x07 646 00:00:08 0x00000008 0x08 647 00:00:09 0x00000009 0x09 648 00:00:10 0x0000000a 0x0a 649 00:00:11 0x0000000b 0x0b 650 00:00:12 0x0000000c 0x0c 651 00:00:13 0x0000000d 0x0d 652 00:00:14 0x0000000e 0x0e 653 00:00:15 0x0000000f 0x0f 654 00:00:16 0x00000010 0x10 655 00:00:17 0x00000011 0x11 656 00:00:18 0x00000012 0x12 657 00:00:19 0x00000013 0x13 658 00:00:20 0x00000014 0x14 659 00:00:21 0x00000015 0x15 660 00:00:22 0x00000016 0x16 661 00:00:23 0x00000017 0x17 662 00:00:24 0x00000018 0x18 663 00:00:25 0x00000019 0x19 664 00:00:26 0x0000001a 0x1a 665 00:00:27 0x0000001b 0x1b 666 00:00:28 0x0000001c 0x1c 667 00:00:29 0x0000001d 0x1d 668 00:00:30 0x0000001e 0x1e 669 00:00:31 0x0000001f 0x1f 670 00:00:32 0x00000020 0x20 671 00:00:33 0x00000021 0x21 672 00:00:34 0x00000022 0x22 673 00:00:35 0x00000023 0x23 674 00:00:36 0x00000024 0x24 675 00:00:37 0x00000025 0x25 676 00:00:38 0x00000026 0x26 677 00:00:39 0x00000027 0x27 678 00:00:40 0x00000028 0x28 679 00:00:41 0x00000029 0x29 680 00:00:42 0x0000002a 0x2a 681 00:00:43 0x0000002b 0x2b 682 00:00:44 0x0000002c 0x2c 683 00:00:45 0x0000002d 0x2d 684 00:00:46 0x0000002e 0x2e 685 00:00:47 0x0000002f 0x2f 686 00:00:48 0x00000030 0x30 687 00:00:49 0x00000031 0x31 688 00:00:50 0x00000032 0x32 689 00:00:51 0x00000033 0x33 690 00:00:52 0x00000034 0x34 691 00:00:53 0x00000035 0x35 692 00:00:54 0x00000036 0x36 693 00:00:55 0x00000037 0x37 694 00:00:56 0x00000038 0x38 695 00:00:57 0x00000039 0x39 696 00:00:58 0x0000003a 0x3a 697 00:00:59 0x0000003b 0x3b 698 00:01:00 0x0000003c 0x3c 699 00:01:01 0x0000003d 0x3d 700 00:01:02 0x0000003e 0x3e 701 00:01:03 0x0000003f 0x3f 702 00:01:04 0x00000040 0x40 703 00:01:05 0x00000041 0x41 704 00:01:06 0x00000042 0x42 705 00:01:07 0x00000043 0x43 706 00:01:08 0x00000044 0x44 707 00:01:09 0x00000045 0x45 708 00:01:10 0x00000046 0x46 709 00:01:11 0x00000047 0x47 710 00:01:12 0x00000048 0x48 711 00:01:13 0x00000049 0x49 712 00:01:14 0x0000004a 0x4a 713 00:01:15 0x0000004b 0x4b 714 00:01:16 0x0000004c 0x4c 715 00:01:17 0x0000004d 0x4d 716 00:01:18 0x0000004e 0x4e 717 00:01:19 0x0000004f 0x4f 718 00:01:20 0x00000050 0x50 719 00:01:21 0x00000051 0x51 720 00:01:22 0x00000052 0x52 721 00:01:23 0x00000053 0x53 722 00:01:24 0x00000054 0x54 723 00:01:25 0x00000055 0x55 724 00:01:26 0x00000056 0x56 725 00:01:27 0x00000057 0x57 726 00:01:28 0x00000058 0x58 727 00:01:29 0x00000059 0x59 728 00:01:30 0x0000005a 0x5a 729 00:01:31 0x0000005b 0x5b 730 00:01:32 0x0000005c 0x5c 731 00:01:33 0x0000005d 0x5d 732 00:01:34 0x0000005e 0x5e 733 00:01:35 0x0000005f 0x5f 734 00:01:36 0x00000060 0x60 735 00:01:37 0x00000061 0x61 736 00:01:38 0x00000062 0x62 737 00:01:39 0x00000063 0x63 738 00:01:40 0x00000064 0x64 739 00:01:41 0x00000065 0x65 740 00:01:42 0x00000066 0x66 741 00:01:43 0x00000067 0x67 742 00:01:44 0x00000068 0x68 743 00:01:45 0x00000069 0x69 744 00:01:46 0x0000006a 0x6a 745 00:01:47 0x0000006b 0x6b 746 00:01:48 0x0000006c 0x6c 747 00:01:49 0x0000006d 0x6d 748 00:01:50 0x0000006e 0x6e 749 00:01:51 0x0000006f 0x6f 750 00:01:52 0x00000070 0x70 751 00:01:53 0x00000071 0x71 752 00:01:54 0x00000072 0x72 753 00:01:55 0x00000073 0x73 754 00:01:56 0x00000074 0x74 755 00:01:57 0x00000075 0x75 756 00:01:58 0x00000076 0x76 757 00:01:59 0x00000077 0x77 758 00:02:00 0x00000078 0x78 759 00:02:01 0x00000079 0x79 760 00:02:02 0x0000007a 0x7a 761 00:02:03 0x0000007b 0x7b 762 00:02:04 0x0000007c 0x7c 763 00:02:05 0x0000007d 0x7d 764 00:02:06 0x0000007e 0x7e 765 00:02:07 0x0000007f 0x7f 766 00:02:08 0x00000080 0x80 767 00:02:24 0x00000090 0x90 768 00:02:40 0x000000a0 0xa0 769 00:02:56 0x000000b0 0xb0 770 00:03:12 0x000000c0 0xc0 771 00:03:28 0x000000d0 0xd0 772 00:03:44 0x000000e0 0xe0 773 00:04:00 0x000000f0 0xf0 774 00:04:16 0x00000100 0x81 775 00:04:48 0x00000120 0x91 776 00:05:20 0x00000140 0xa1 777 00:05:52 0x00000160 0xb1 778 00:06:24 0x00000180 0xc1 779 00:06:56 0x000001a0 0xd1 780 00:07:28 0x000001c0 0xe1 781 00:08:00 0x000001e0 0xf1 782 00:08:32 0x00000200 0x82 783 00:09:36 0x00000240 0x92 784 00:10:40 0x00000280 0xa2 785 00:11:44 0x000002c0 0xb2 786 00:12:48 0x00000300 0xc2 787 00:13:52 0x00000340 0xd2 788 00:14:56 0x00000380 0xe2 789 00:16:00 0x000003c0 0xf2 790 00:17:04 0x00000400 0x83 791 00:19:12 0x00000480 0x93 792 00:21:20 0x00000500 0xa3 793 00:23:28 0x00000580 0xb3 794 00:25:36 0x00000600 0xc3 795 00:27:44 0x00000680 0xd3 796 00:29:52 0x00000700 0xe3 797 00:32:00 0x00000780 0xf3 798 00:34:08 0x00000800 0x84 799 00:38:24 0x00000900 0x94 800 00:42:40 0x00000a00 0xa4 801 00:46:56 0x00000b00 0xb4 802 00:51:12 0x00000c00 0xc4 803 00:55:28 0x00000d00 0xd4 804 00:59:44 0x00000e00 0xe4 805 01:04:00 0x00000f00 0xf4 806 01:08:16 0x00001000 0x85 807 01:16:48 0x00001200 0x95 808 01:25:20 0x00001400 0xa5 809 01:33:52 0x00001600 0xb5 810 01:42:24 0x00001800 0xc5 811 01:50:56 0x00001a00 0xd5 812 01:59:28 0x00001c00 0xe5 813 02:08:00 0x00001e00 0xf5 814 02:16:32 0x00002000 0x86 815 02:33:36 0x00002400 0x96 816 02:50:40 0x00002800 0xa6 817 03:07:44 0x00002c00 0xb6 818 03:24:48 0x00003000 0xc6 819 03:41:52 0x00003400 0xd6 820 03:58:56 0x00003800 0xe6 821 04:16:00 0x00003c00 0xf6 822 04:33:04 0x00004000 0x87 823 05:07:12 0x00004800 0x97 824 05:41:20 0x00005000 0xa7 825 06:15:28 0x00005800 0xb7 826 06:49:36 0x00006000 0xc7 827 07:23:44 0x00006800 0xd7 828 07:57:52 0x00007000 0xe7 829 08:32:00 0x00007800 0xf7 830 09:06:08 0x00008000 0x88 831 10:14:24 0x00009000 0x98 832 11:22:40 0x0000a000 0xa8 833 12:30:56 0x0000b000 0xb8 834 13:39:12 0x0000c000 0xc8 835 14:47:28 0x0000d000 0xd8 836 15:55:44 0x0000e000 0xe8 837 17:04:00 0x0000f000 0xf8 838 18:12:16 0x00010000 0x89 839 20:28:48 0x00012000 0x99 840 22:45:20 0x00014000 0xa9 841 1d 01:01:52 0x00016000 0xb9 842 1d 03:18:24 0x00018000 0xc9 843 1d 05:34:56 0x0001a000 0xd9 844 1d 07:51:28 0x0001c000 0xe9 845 1d 10:08:00 0x0001e000 0xf9 846 1d 12:24:32 0x00020000 0x8a 847 1d 16:57:36 0x00024000 0x9a 848 1d 21:30:40 0x00028000 0xaa 849 2d 02:03:44 0x0002c000 0xba 850 2d 06:36:48 0x00030000 0xca 851 2d 11:09:52 0x00034000 0xda 852 2d 15:42:56 0x00038000 0xea 853 2d 20:16:00 0x0003c000 0xfa 854 3d 00:49:04 0x00040000 0x8b 855 3d 09:55:12 0x00048000 0x9b 856 3d 19:01:20 0x00050000 0xab 857 4d 04:07:28 0x00058000 0xbb 858 4d 13:13:36 0x00060000 0xcb 859 4d 22:19:44 0x00068000 0xdb 860 5d 07:25:52 0x00070000 0xeb 861 5d 16:32:00 0x00078000 0xfb 862 6d 01:38:08 0x00080000 0x8c 863 6d 19:50:24 0x00090000 0x9c 864 7d 14:02:40 0x000a0000 0xac 865 8d 08:14:56 0x000b0000 0xbc 866 9d 02:27:12 0x000c0000 0xcc 867 9d 20:39:28 0x000d0000 0xdc 868 10d 14:51:44 0x000e0000 0xec 869 11d 09:04:00 0x000f0000 0xfc 870 12d 03:16:16 0x00100000 0x8d 871 13d 15:40:48 0x00120000 0x9d 872 15d 04:05:20 0x00140000 0xad 873 16d 16:29:52 0x00160000 0xbd 874 18d 04:54:24 0x00180000 0xcd 875 19d 17:18:56 0x001a0000 0xdd 876 21d 05:43:28 0x001c0000 0xed 877 22d 18:08:00 0x001e0000 0xfd 878 24d 06:32:32 0x00200000 0x8e 879 27d 07:21:36 0x00240000 0x9e 880 30d 08:10:40 0x00280000 0xae 881 33d 08:59:44 0x002c0000 0xbe 882 36d 09:48:48 0x00300000 0xce 883 39d 10:37:52 0x00340000 0xde 884 42d 11:26:56 0x00380000 0xee 885 45d 12:16:00 0x003c0000 0xfe 886 48d 13:05:04 0x00400000 0x8f 887 54d 14:43:12 0x00480000 0x9f 888 60d 16:21:20 0x00500000 0xaf 889 66d 17:59:28 0x00580000 0xbf 890 72d 19:37:36 0x00600000 0xcf 891 78d 21:15:44 0x00680000 0xdf 892 84d 22:53:52 0x00700000 0xef 893 91d 00:32:00 0x00780000 0xff (reserved) 895 Figure 5 897 Authors' Addresses 899 Carsten Bormann 900 Universitaet Bremen TZI 901 Postfach 330440 902 Bremen D-28359 903 Germany 905 Phone: +49-421-218-63921 906 Fax: +49-421-218-7000 907 Email: cabo@tzi.org 909 Klaus Hartke 910 Universitaet Bremen TZI 911 Postfach 330440 912 Bremen D-28359 913 Germany 915 Phone: +49-421-218-63905 916 Fax: +49-421-218-7000 917 Email: hartke@tzi.org