idnits 2.17.1 draft-bormann-coap-misc-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2011) is 4544 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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-17 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 5 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: May 20, 2012 November 17, 2011 7 Miscellaneous additions to CoAP 8 draft-bormann-coap-misc-10 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 May 20, 2012. 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. Getting rid of artificial limitations . . . . . . . . . . . . 4 54 2.1. Beyond 15 options . . . . . . . . . . . . . . . . . . . . 4 55 2.1.1. Implementation considerations . . . . . . . . . . . . 6 56 2.1.2. What should we do now? . . . . . . . . . . . . . . . . 7 57 2.1.3. Alternatives . . . . . . . . . . . . . . . . . . . . . 7 58 2.1.4. Alternative: Going to a delimiter model . . . . . . . 7 59 2.2. Beyond 270 bytes in a single option . . . . . . . . . . . 8 60 3. URI Authorities with Binary Adresses . . . . . . . . . . . . . 9 61 4. User-defined Option . . . . . . . . . . . . . . . . . . . . . 11 62 5. Payload-Length Option . . . . . . . . . . . . . . . . . . . . 12 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 69 Appendix A. The Cemetery (Things we won't do) . . . . . . . . . . 17 70 A.1. Stateful URI compression . . . . . . . . . . . . . . . . . 17 71 Appendix B. Experimental Options . . . . . . . . . . . . . . . . 19 72 B.1. Options indicating absolute time . . . . . . . . . . . . . 19 73 B.2. Representing Durations . . . . . . . . . . . . . . . . . . 20 74 B.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 21 75 B.4. Pseudo-Floating Point . . . . . . . . . . . . . . . . . . 22 76 B.5. A Duration Type for CoAP . . . . . . . . . . . . . . . . . 23 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 79 1. Introduction 81 The CoRE WG is tasked with standardizing an Application Protocol for 82 Constrained Networks/Nodes, CoAP [I-D.ietf-core-coap]. This protocol 83 is intended to provide RESTful [REST] services not unlike HTTP 84 [RFC2616], while reducing the complexity of implementation as well as 85 the size of packets exchanged in order to make these services useful 86 in a highly constrained network of themselves highly constrained 87 nodes. 89 This objective requires restraint in a number of sometimes 90 conflicting ways: 92 o reducing implementation complexity in order to minimize code size, 94 o reducing message sizes in order to minimize the number of 95 fragments needed for each message (in turn to maximize the 96 probability of delivery of the message), the amount of 97 transmission power needed and the loading of the limited-bandwidth 98 channel, 100 o reducing requirements on the environment such as stable storage, 101 good sources of randomness or user interaction capabilities. 103 This draft attempts to address a number of problems not yet 104 adequately solved in [I-D.ietf-core-coap]. The solutions proposed to 105 these problems are somewhat interrelated and are therefore presented 106 in one draft. 108 The appendix contains the "CoAP cemetery" (possibly later to move 109 into its own draft), documenting roads that the WG decided not to 110 take, in order to spare readers from reinventing them in vain. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 The term "byte" is used in its now customary sense as a synonym for 117 "octet". 119 2. Getting rid of artificial limitations 121 _Artificial limitations_ are limitations of a protocol or system that 122 are not rooted in limitations of actual capabilities, but in 123 arbitrary design decisions. Proper system design tries to avoid 124 artificial limitations, as these tend to cause complexity in systems 125 that need to work with these limitations. 127 E.g., the original UNIX filesystem had an artificial limitation of 128 the length of a path name component to 14 bytes. This led to all 129 kinds of workarounds in programs that manipulate file names: E.g., 130 systematically replacing a ".el" extension in a filename with a 131 ".elc" for the compiled file might exceed the limit, so all ".el" 132 files were suddenly limited to 13-byte filenames. 134 Note that, today, there still is a limitation in most file system 135 implementations, typically at 255. This just happens to be high 136 enough to rarely be of real-world concern; we will refer to this case 137 as a "painless" artificial limitation. 139 CoAP-08 has two highly recognizable artificial limitations in its 140 protocol encoding 142 o The number of options in a single message is limited to 15 max. 144 o The length of an option is limited to 270 max. 146 It is arguable that the latter limitation causes few problems, just 147 as the 255-byte path name component limitation in filenames today 148 causes few problems. Just in case, Section 2.2 provides a design to 149 extend this. 151 2.1. Beyond 15 options 153 The limit of 15 options is motivated by the fixed four-bit field "OC" 154 that is used for indicating the number of options in the fixed-length 155 CoAP header (Figure 1). 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 |Ver| T | OC | Code | Message ID | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Options (if any) ... 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Payload (if any) ... 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1: Four-byte fixed header in a CoAP Message 168 Note that there is another fixed four-bit field in CoAP: the option 169 length (Figure 2 - note that this figure is not to the same scale as 170 the previous figure): 172 0 1 2 3 4 5 6 7 173 +---+---+---+---+---+---+---+---+ 174 | Option Delta | Length | for 0..14 175 +---+---+---+---+---+---+---+---+ 176 | Option Value ... 177 +---+---+---+---+---+---+---+---+ 179 Figure 2: Short Option Header 181 Since 15 is inacceptable for a maximum option length, the all-ones 182 value (15) was taken out of the set of allowable values for the short 183 header, and a long header was introduced that allows the insertion of 184 an extension byte (Figure 3): 186 for 15..270: 187 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 188 | Option Delta | 1 1 1 1 | Length - 15 | 189 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 190 | Option Value ... 191 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 193 Figure 3: Long Option Header 195 We might want to use the same technique for the CoAP header as well. 196 There are two obvious places where the extension byte could be 197 placed: 199 1. right after the byte carrying the OC field, so the structure is 200 the same as for the option header; 202 2. right after the fixed-size CoAP header. 204 Both solutions lose the fixed-size-ness of the CoAP header. 206 Solution 1 has the disadvantage that the CoAP header is also changing 207 in structure: The extension byte is wedged between the first and the 208 second byte of the CoAP header. This is unfortunate, as the number 209 of options only comes into play when the option processing begins, so 210 it is more natural to use solution 2 (Figure 4): 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |Ver| T | 15 | Code | Message ID | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | OC - 15 | Options ... 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Payload (if any) ... 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 4: Extended header for CoAP Messages with 15+ options 224 This would allow for up to 270 options in a CoAP message, which is 225 very likely way beyond the "painless" threshold. 227 2.1.1. Implementation considerations 229 For a message decoder, this extension creates relatively little pain, 230 as the number of options only becomes interesting when the encoding 231 turns to the options part of the message, which is then simply lead 232 in by the extension byte if the four-bit field is 15. 234 For a message encoder, this extension is not so rosy. If the encoder 235 is constructing the message serially, it may not know in advance 236 whether the number of options will exceed 14. None of the following 237 implementation strategies is particularly savory, but all of them do 238 work: 240 1. Encode the options serially under the assumption that the number 241 of options will be 14 or less. When the 15th option needs to be 242 encoded, abort the option encoding, and restart it from scratch 243 one byte further to the left. 245 2. Similar to 1, except that the bytes already encoded are all moved 246 one byte to right, the extension byte is inserted, and the option 247 encoding process is continued. 249 3. The encoder always leaves space for the extension byte (at least 250 if it can't prove the number will be less thatn 14). If the 251 extension byte is not needed, an Option 0 with length 0 is 252 encoded instead (i.e., one byte is wasted - this option is 253 elective and will be ignored by the receiver). 255 As a minimum, to enable strategy 3, the option 0 should be reserved 256 at least for the case of length=0. 258 2.1.2. What should we do now? 260 As a minimum proposal for the next version of CoAP, the value 15 for 261 OC should be marked as reserved today. 263 2.1.3. Alternatives 265 One alternative that has been discussed previously is to have an 266 "Options" Option, which allows the carriage of multiple options in 267 the belly of a single one. This could also be used to carry more 268 than 15 options. However: 270 o The conditional introduction of an Options option has 271 implementation considerations that are likely to be more severe 272 than the ones listed above; 274 o since 270 bytes may not be enough for the encoding of _all_ 275 options, the "Options" option would need to be repeatable. This 276 creates many different ways to encode the same message, leading to 277 combinatorial explosion in test cases for ensuring 278 interoperability. 280 2.1.4. Alternative: Going to a delimiter model 282 Another alternative is to spend the additional byte not as an 283 extended count, but as an option terminator. 285 In this proposal setting OC to 15 means that the number of options is 286 no longer given explicitly. Instead, the sequence of options is 287 terminated by a byte with a special interpretation, 0xF0. (Note that 288 the option _delta_ of 15 is made special, not any specific option 289 number.) The next byte is then the first byte of the payload. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |Ver| T | 15 | Code | Message ID | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Options ... 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 |1 1 1 1 0 0 0 0| Payload (if any) ... 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 5: Option Terminator for CoAP Messages with 15+ options 303 (It is to be decided whether 0xF0 is made special only for OC=15, 304 i.e. if it retains its usual meaning of (option delta = 15, option 305 length = 0) for other values of OC.) 307 2.2. Beyond 270 bytes in a single option 309 The authors would argue that 270 as the maximum length of an option 310 is already beyond the "painless" threshold. 312 If that is not the consensus of the WG, the scheme can easily be 313 extended as in Figure 6: 315 for 15..269: 316 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 317 | Option Delta | 1 1 1 1 | Length - 15 | 318 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 319 | Option Value ... 320 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 322 for 270..65805: 323 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 324 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 325 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 326 | Length - 270 (in network byte order) | 327 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 328 | Option Value ... 329 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 331 Figure 6: Ridiculously Long Option Header 333 The infinite number of obvious variations on this scheme are left as 334 an exercise to the reader. 336 Again, as a precaution to future extensions, the current encoding for 337 length 270 (eight ones in the extension byte) could be marked as 338 reserved today. 340 3. URI Authorities with Binary Adresses 342 One problem with the way URI authorities are represented in the URI 343 syntax is that the authority part can be very bulky if it encodes an 344 IPv6 address in ASCII. 346 Proposal: Provide an option "Uri-Authority-Binary" that can be an 347 even number of bytes between 2 and 18 except 12 or 14. 349 o If the number of bytes is 2, the destination IP address of the 350 packet transporting the CoAP message is implied. 352 o If the number of bytes is 4 or 6, the first four bytes of the 353 option value are an IPv4 address in binary. 355 o If the number of bytes is 8 or 10, the first eight bytes are the 356 lower 64 bits of an IPv6 address; the upper eight bytes are 357 implied from the destination address of the packet transporting 358 the CoAP message. 360 o If the number of bytes is 16 or 18, the first 16 bytes are an IPv6 361 address. 363 o If two more bytes remain, this is a port number (as always in 364 network byte order). 366 The resulting authority is (conceptually translated into ASCII and) 367 used in place of an Uri-Authority option, or inserted into a Proxy- 368 Uri. Examples: 370 +-------------+------------------+---------+------------------------+ 371 | Proxy-Uri | Uri-Authority-Bi | Uri-Pat | URI | 372 | | nary | h | | 373 +-------------+------------------+---------+------------------------+ 374 | (none) | (none) | (none) | "/" | 375 | | | | | 376 | (none) | (none) | 'temp' | "/temp" | 377 | | | | | 378 | (none) | 2 bytes: 61616 | 'temp' | "coap://[DA]:61616/tem | 379 | | | | p" | 380 | | | | | 381 | (none) | 16 bytes: | temp | "coap://[2000::1]/temp | 382 | | 2000::1 | | " | 383 | | | | | 384 | 'http://' | 10 bytes: | (none) | "http://[DA::123:45]:6 | 385 | | ::123:45 + 616 | | 16" | 386 | | | | | 387 | 'http:///te | 18 bytes: | (none) | "http://[2000::1]:616/ | 388 | mp' | 2000::1 + 616 | | temp" | 389 +-------------+------------------+---------+------------------------+ 391 4. User-defined Option 393 To enable experimentation and community-specific options, option 394 number 14 (the first NOP option) can also be used as a user-defined 395 option. For this application, the option value has one or more 396 bytes, the semantics of which are defined by prior agreement between 397 the communicating partners. 399 It is RECOMMENDED to start the option value with a unique identifier, 400 e.g., the SDNV [RFC5050] of the enterprise number of the organisation 401 defining the option, possibly followed by additional discriminating 402 bits or bytes. 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 |1 0 0 0 0 0 0 1|0 1 1 1 0 0 1 1| private opt-id| value... | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 \___SDNV of enterprise number___/ 409 Figure 7: Example option value for user-defined option 411 User-defined Options are elective. 413 The User-defined Option is repeatable. 415 Potential options: 417 +-----+----------+------+-------------+---------+---------+ 418 | No. | C/E | Name | Format | Length | Default | 419 +-----+----------+------+-------------+---------+---------+ 420 | 14 | Elective | User | (see below) | 1-270 B | (empty) | 421 +-----+----------+------+-------------+---------+---------+ 423 5. Payload-Length Option 425 Not all transport mappings may provide an unambiguous length of the 426 CoAP message. For UDP, it may also be desirable to pack more than 427 one CoAP message into one UDP payload (aggregation); in that case, 428 for all but the last message there needs to be a way to delimit the 429 payload of that message. 431 This can be solved using a new option, the Payload-Length option. If 432 this option is present, the value of this option is an unsigned 433 integer giving the length of the payload of the message (note that 434 this integer can be zero for a zero-length payload, which can in turn 435 be represented by a zero-length option value). (In the UDP 436 aggregation case, what would have been in the payload of this message 437 after "payload-length" bytes is then actually one or more additional 438 messages.) 440 6. IANA Considerations 442 This draft adds option numbers to Table 2 of [I-D.ietf-core-coap], 443 resulting in: 445 TBD. 447 7. Security Considerations 449 TBD. 451 8. Acknowledgements 453 This work was partially funded by the Klaus Tschira Foundation. 455 Of course, much of the content of this draft is the result of 456 discussions with the [I-D.ietf-core-coap] authors. 458 9. References 460 9.1. Normative References 462 [I-D.ietf-core-coap] 463 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 464 "Constrained Application Protocol (CoAP)", 465 draft-ietf-core-coap-08 (work in progress), October 2011. 467 [I-D.ietf-httpbis-p1-messaging] 468 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 469 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 470 J. Reschke, "HTTP/1.1, part 1: URIs, Connections, and 471 Message Parsing", draft-ietf-httpbis-p1-messaging-17 (work 472 in progress), October 2011. 474 [I-D.ietf-httpbis-p4-conditional] 475 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 476 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 477 J. Reschke, "HTTP/1.1, part 4: Conditional Requests", 478 draft-ietf-httpbis-p4-conditional-17 (work in progress), 479 October 2011. 481 [I-D.ietf-httpbis-p6-cache] 482 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 483 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 484 Nottingham, M., and J. Reschke, "HTTP/1.1, part 6: 485 Caching", draft-ietf-httpbis-p6-cache-17 (work in 486 progress), October 2011. 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 492 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 493 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 495 9.2. Informative References 497 [REST] Fielding, R., "Architectural Styles and the Design of 498 Network-based Software Architectures", 2000. 500 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 501 Specification", RFC 5050, November 2007. 503 Appendix A. The Cemetery (Things we won't do) 505 This annex documents roads that the WG decided not to take, in order 506 to spare readers from reinventing them in vain. 508 A.1. Stateful URI compression 510 Is the approximately 25 % average saving achievable with Huffman- 511 based URI compression schemes worth the complexity? Probably not, 512 because much higher average savings can be achieved by introducing 513 state. 515 Henning Schulzrinne has proposed for a server to be able to supply a 516 shortened URI once a resource has been requested using the full- 517 length URI. Let's call such a shortened referent a _Temporary 518 Resource Identifier_, _TeRI_ for short. This could be expressed by a 519 response option as shown in Figure 8. 521 0 522 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | duration | TeRI... 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 8: Option for offering a TeRI in a response 529 The TeRI offer option indicates that the server promises to offer 530 this resources under the TeRI given for at least the time given as 531 the duration. Another TeRI offer can be made later to extend the 532 duration. 534 Once a TeRI for a URI is known (and still within its lifetime), the 535 client can supply a TeRI instead of a URI in its requests. The same 536 option format as an offer could be used to allow the client to 537 indicate how long it believes the TeRI will still be valid (so that 538 the server can decide when to update the lifetime duration). TeRIs 539 in requests could be distinguished from URIs e.g. by using a 540 different option number. 542 Proposal: Add a TeRI option that can be used in CoAP requests and 543 responses. 545 Add a way to indicate a TeRI and its duration in a link-value. 547 Do not add any form of stateless URI encoding. 549 Benefits: Much higher reduction of message size than any stateless 550 URI encoding could achieve. 552 As the use of TeRIs is entirely optional, minimal complexity nodes 553 can get by without implementing them. 555 Drawbacks: Adds considerable state and complexity to the protocol. 557 It turns out that real CoAP URIs are short enough that TeRIs are 558 not needed. 560 (Discuss the security implications of TeRIs.) 562 Appendix B. Experimental Options 564 This annex documents proposals that need significant additional 565 discussion before they can become part of (or go back to) the main 566 CoAP specification. They are not dead, but might die if there turns 567 out to be no good way to solve the problem. 569 B.1. Options indicating absolute time 571 HTTP has a number of headers that may indicate absolute time: 573 o "Date", defined in Section 14.18 in [RFC2616] (Section 9.3 in 574 [I-D.ietf-httpbis-p1-messaging]), giving the absolute time a 575 response was generated; 577 o "Last-Modified", defined in Section 14.29 in [RFC2616], (Section 578 6.6 in [I-D.ietf-httpbis-p4-conditional], giving the absolute time 579 of when the origin server believes the resource representation was 580 last modified; 582 o "If-Modified-Since", defined in Section 14.25 in [RFC2616], 583 "If-Unmodified-Since", defined in Section 14.28 in [RFC2616], and 584 "If-Range", defined in Section 14.27 in [RFC2616] can be used to 585 supply absolute time to gate a conditional request; 587 o "Expires", defined in Section 14.21 in [RFC2616] (Section 3.3 in 588 [I-D.ietf-httpbis-p6-cache]), giving the absolute time after which 589 a response is considered stale. 591 o The more obscure headers "Retry-After", defined in Section 14.37 592 in [RFC2616], and "Warning", defined in section 14.46 in 593 [RFC2616], also may employ absolute time. 595 [I-D.ietf-core-coap] defines a single "Date" option, which however 596 "indicates the creation time and date of a given resource 597 representation", i.e., is closer to a "Last-Modified" HTTP header. 598 HTTP's caching rules [I-D.ietf-httpbis-p6-cache] make use of both 599 "Date" and "Last-Modified", combined with "Expires". The specific 600 semantics required for CoAP needs further consideration. 602 In addition to the definition of the semantics, an encoding for 603 absolute times needs to be specified. 605 In UNIX-related systems, it is customary to indicate absolute time as 606 an integer number of seconds, after midnight UTC, January 1, 1970. 607 Unless negative numbers are employed, this time format cannot 608 represent time values prior to January 1, 1970, which probably is not 609 required for the uses ob absolute time in CoAP. 611 If a 32-bit integer is used and allowance is made for a sign-bit in a 612 local implementation, the latest UTC time value that can be 613 represented by the resulting 31 bit integer value is 03:14:07 on 614 January 19, 2038. If the 32-bit integer is used as an unsigned 615 value, the last date is 2106-02-07, 06:28:15. 617 The reach can be extended by: - moving the epoch forward, e.g. by 40 618 years (= 1262304000 seconds) to 2010-01-01. This makes it impossible 619 to represent Last-Modified times in that past (such as could be 620 gatewayed in from HTTP). - extending the number of bits, e.g. by one 621 more byte, either always or as one of two formats, keeping the 32-bit 622 variant as well. 624 Also, the resolution can be extended by expressing time in 625 milliseconds etc., requiring even more bits (e.g., a 48-bit unsigned 626 integer of milliseconds would last well after year 9999.) 628 For experiments, an experimental "Date" option is defined with the 629 semantics of HTTP's "Last-Modified". It can carry an unsigned 630 integer of 32, 40, or 48 bits; 32- and 40-bit integers indicate the 631 absolute time in seconds since 1970-01-01 00:00 UTC, while 48-bit 632 integers indicate the absolute time in milliseconds since 1970-01-01 633 00:00 UTC. 635 However, that option is not really that useful until there is a 636 "If-Modified-Since" option as well. 638 (Also: Discuss nodes without clocks.) 640 B.2. Representing Durations 642 Various message types used in CoAP need the representation of 643 *durations*, i.e. of the length of a timespan. In SI units, these 644 are measured in seconds. CoAP durations represent integer numbers of 645 seconds, but instead of representing these numbers as integers, a 646 more compact single-byte pseudo-floating-point (pseudo-FP) 647 representation is used (Figure 9). 649 0 1 2 3 4 5 6 7 650 +---+---+---+---+---+---+---+---+ 651 | 0... value | 652 +---+---+---+---+---+---+---+---+ 654 +---+---+---+---+---+---+---+---+ 655 | 1... mantissa | exponent | 656 +---+---+---+---+---+---+---+---+ 657 Figure 9: Duration in (8,4) pseudo-FP representation 659 If the high bit is clear, the entire n-bit value (including the high 660 bit) is the decoded value. If the high bit is set, the mantissa 661 (including the high bit, with the exponent field cleared out but 662 still present) is shifted left by the exponent to yield the decoded 663 value. 665 The (n,e)-pseudo-FP format can be decoded with a single line of code 666 (plus a couple of constant definitions), as demonstrated in 667 Figure 10. 669 #define N 8 670 #define E 4 671 #define HIBIT (1 << (N - 1)) 672 #define EMASK ((1 << E) - 1) 673 #define MMASK ((1 << N) - 1 - EMASK) 675 #define DECODE_8_4(r) (r < HIBIT ? r : (r & MMASK) << (r & EMASK)) 677 Figure 10: Decoding an (8,4) pseudo-FP value 679 Note that a pseudo-FP encoder needs to consider rounding; different 680 applications of durations may favor rounding up or rounding down the 681 value encoded in the message. 683 The highest pseudo-FP value, represented by an all-ones byte (0xFF), 684 is reserved to indicate an indefinite duration. The next lower value 685 (0xEF) is thus the highest representable value and is decoded as 686 7340032 seconds, a little more than 12 weeks. 688 B.3. Rationale 690 Where CPU power and memory is abundant, a duration can almost always 691 be adequately represented by a non-negative floating-point number 692 representing that number of seconds. Historically, many APIs have 693 also used an integer representation, which limits both the resolution 694 (e.g., if the integer represents the duration in seconds) and often 695 the range (integer machine types have range limits that may become 696 relevant). UNIX's "time_t" (which is used for both absolute time and 697 durations) originally was a signed 32-bit value of seconds, but was 698 later complemented by an additional integer to add microsecond 699 ("struct timeval") and then later nanosecond ("struct timespec") 700 resolution. 702 Three decisions need to be made for each application of the concept 703 of duration: 705 o the *resolution*. What rounding error is acceptable? 707 o the *range*. What is the maximum duration that needs to be 708 represented? 710 o the *number of bits* that can be expended. 712 Obviously, these decisions are interrelated. Typically, a large 713 range needs a large number of bits, unless resolution is traded. For 714 most applications, the actual requirement for resolution are limited 715 for longer durations, but can be more acute for shorter durations. 717 B.4. Pseudo-Floating Point 719 Constrained systems typically avoid the use of floating-point (FP) 720 values, as 722 o simple CPUs often don't have support for floating-point datatypes 724 o software floating-point libraries are expensive in code size and 725 slow. 727 In addition, floating-point datatypes used to be a significant 728 element of market differentiation in CPU design; it has taken the 729 industry a long time to agree on a standard floating point 730 representation. 732 These issues have led to protocols that try to constrain themselves 733 to integer representation even where the ability of a floating point 734 representation to trade range for resolution would be beneficial. 736 The idea of introducing _pseudo-FP_ is to obtain the increased range 737 provided by embedding an exponent, without necessarily getting stuck 738 with hardware datatypes or inefficient software floating-point 739 libraries. 741 For the purposes of this draft, we define an (n,e)-pseudo-FP as a 742 fixed-length value of n bits, e of which may be used for an exponent. 743 Figure 9 illustrates an (8,4)-pseudo-FP value. 745 If the high bit is clear, the entire n-bit value (including the high 746 bit) is the decoded value. If the high bit is set, the mantissa 747 (including the high bit, but with the exponent field cleared out) is 748 shifted left by the exponent to yield the decoded value. 750 The (n,e)-pseudo-FP format can be decoded with a single line of code 751 (plus a couple of constant definition), as demonstrated in Figure 10. 753 Only non-negative numbers can be represented by this format. It is 754 designed to provide full integer resolution for values from 0 to 755 2^(n-1)-1, i.e., 0 to 127 in the (8,4) case, and a mantissa of n-e 756 bits from 2^(n-1) to (2^n-2^e)*2^(2^e-1), i.e., 128 to 7864320 in the 757 (8,4) case. By choosing e carefully, resolution can be traded 758 against range. 760 Note that a pseudo-FP encoder needs to consider rounding; different 761 applications of durations may favor rounding up or rounding down the 762 value encoded in the message. This requires a little more than a 763 single line of code (which is left as an exercise to the reader, as 764 the most efficient expression depends on hardware details). 766 B.5. A Duration Type for CoAP 768 CoAP needs durations in a number of places. In [I-D.ietf-core-coap], 769 durations occur in the option "Subscription-lifetime" as well as in 770 the option "Max-age". (Note that the option "Date" is not a 771 duration, but a point in time.) Other durations of this kind may be 772 added later. 774 Most durations relevant to CoAP are best expressed with a minimum 775 resolution of one second. More detailed resolutions are unlikely to 776 provide much benefit. 778 The range of lifetimes and caching ages are probably best kept below 779 the order of magnitude of months. An (8,4)-pseudo-FP has the maximum 780 value of 7864320, which is about 91 days; this appears to be adequate 781 for a subscription lifetime and probably even for a maximum cache 782 age. Figure 11 shows the values that can be expressed. (If a larger 783 range for the latter is indeed desired, an (8,5)-pseudo-FP could be 784 used; this would last 15 milleniums, at the cost of having only 3 785 bits of accuracy for values larger than 127 seconds.) 787 Proposal: A single duration type is used throughout CoAP, based on 788 an (8,4)-pseudo-FP giving a duration in seconds. 790 Benefits: Implementations can use a single piece of code for 791 managing all CoAP-related durations. 793 In addition, length information never needs to be managed for 794 durations that are embedded in other data structures: All 795 durations are expressed by a single byte. 797 It might be worthwhile to reserve one duration value, e.g. 0xFF, for 798 an indefinite duration. 800 Duration Seconds Encoded 801 ----------- ---------- ------- 802 00:00:00 0x00000000 0x00 803 00:00:01 0x00000001 0x01 804 00:00:02 0x00000002 0x02 805 00:00:03 0x00000003 0x03 806 00:00:04 0x00000004 0x04 807 00:00:05 0x00000005 0x05 808 00:00:06 0x00000006 0x06 809 00:00:07 0x00000007 0x07 810 00:00:08 0x00000008 0x08 811 00:00:09 0x00000009 0x09 812 00:00:10 0x0000000a 0x0a 813 00:00:11 0x0000000b 0x0b 814 00:00:12 0x0000000c 0x0c 815 00:00:13 0x0000000d 0x0d 816 00:00:14 0x0000000e 0x0e 817 00:00:15 0x0000000f 0x0f 818 00:00:16 0x00000010 0x10 819 00:00:17 0x00000011 0x11 820 00:00:18 0x00000012 0x12 821 00:00:19 0x00000013 0x13 822 00:00:20 0x00000014 0x14 823 00:00:21 0x00000015 0x15 824 00:00:22 0x00000016 0x16 825 00:00:23 0x00000017 0x17 826 00:00:24 0x00000018 0x18 827 00:00:25 0x00000019 0x19 828 00:00:26 0x0000001a 0x1a 829 00:00:27 0x0000001b 0x1b 830 00:00:28 0x0000001c 0x1c 831 00:00:29 0x0000001d 0x1d 832 00:00:30 0x0000001e 0x1e 833 00:00:31 0x0000001f 0x1f 834 00:00:32 0x00000020 0x20 835 00:00:33 0x00000021 0x21 836 00:00:34 0x00000022 0x22 837 00:00:35 0x00000023 0x23 838 00:00:36 0x00000024 0x24 839 00:00:37 0x00000025 0x25 840 00:00:38 0x00000026 0x26 841 00:00:39 0x00000027 0x27 842 00:00:40 0x00000028 0x28 843 00:00:41 0x00000029 0x29 844 00:00:42 0x0000002a 0x2a 845 00:00:43 0x0000002b 0x2b 846 00:00:44 0x0000002c 0x2c 847 00:00:45 0x0000002d 0x2d 848 00:00:46 0x0000002e 0x2e 849 00:00:47 0x0000002f 0x2f 850 00:00:48 0x00000030 0x30 851 00:00:49 0x00000031 0x31 852 00:00:50 0x00000032 0x32 853 00:00:51 0x00000033 0x33 854 00:00:52 0x00000034 0x34 855 00:00:53 0x00000035 0x35 856 00:00:54 0x00000036 0x36 857 00:00:55 0x00000037 0x37 858 00:00:56 0x00000038 0x38 859 00:00:57 0x00000039 0x39 860 00:00:58 0x0000003a 0x3a 861 00:00:59 0x0000003b 0x3b 862 00:01:00 0x0000003c 0x3c 863 00:01:01 0x0000003d 0x3d 864 00:01:02 0x0000003e 0x3e 865 00:01:03 0x0000003f 0x3f 866 00:01:04 0x00000040 0x40 867 00:01:05 0x00000041 0x41 868 00:01:06 0x00000042 0x42 869 00:01:07 0x00000043 0x43 870 00:01:08 0x00000044 0x44 871 00:01:09 0x00000045 0x45 872 00:01:10 0x00000046 0x46 873 00:01:11 0x00000047 0x47 874 00:01:12 0x00000048 0x48 875 00:01:13 0x00000049 0x49 876 00:01:14 0x0000004a 0x4a 877 00:01:15 0x0000004b 0x4b 878 00:01:16 0x0000004c 0x4c 879 00:01:17 0x0000004d 0x4d 880 00:01:18 0x0000004e 0x4e 881 00:01:19 0x0000004f 0x4f 882 00:01:20 0x00000050 0x50 883 00:01:21 0x00000051 0x51 884 00:01:22 0x00000052 0x52 885 00:01:23 0x00000053 0x53 886 00:01:24 0x00000054 0x54 887 00:01:25 0x00000055 0x55 888 00:01:26 0x00000056 0x56 889 00:01:27 0x00000057 0x57 890 00:01:28 0x00000058 0x58 891 00:01:29 0x00000059 0x59 892 00:01:30 0x0000005a 0x5a 893 00:01:31 0x0000005b 0x5b 894 00:01:32 0x0000005c 0x5c 895 00:01:33 0x0000005d 0x5d 896 00:01:34 0x0000005e 0x5e 897 00:01:35 0x0000005f 0x5f 898 00:01:36 0x00000060 0x60 899 00:01:37 0x00000061 0x61 900 00:01:38 0x00000062 0x62 901 00:01:39 0x00000063 0x63 902 00:01:40 0x00000064 0x64 903 00:01:41 0x00000065 0x65 904 00:01:42 0x00000066 0x66 905 00:01:43 0x00000067 0x67 906 00:01:44 0x00000068 0x68 907 00:01:45 0x00000069 0x69 908 00:01:46 0x0000006a 0x6a 909 00:01:47 0x0000006b 0x6b 910 00:01:48 0x0000006c 0x6c 911 00:01:49 0x0000006d 0x6d 912 00:01:50 0x0000006e 0x6e 913 00:01:51 0x0000006f 0x6f 914 00:01:52 0x00000070 0x70 915 00:01:53 0x00000071 0x71 916 00:01:54 0x00000072 0x72 917 00:01:55 0x00000073 0x73 918 00:01:56 0x00000074 0x74 919 00:01:57 0x00000075 0x75 920 00:01:58 0x00000076 0x76 921 00:01:59 0x00000077 0x77 922 00:02:00 0x00000078 0x78 923 00:02:01 0x00000079 0x79 924 00:02:02 0x0000007a 0x7a 925 00:02:03 0x0000007b 0x7b 926 00:02:04 0x0000007c 0x7c 927 00:02:05 0x0000007d 0x7d 928 00:02:06 0x0000007e 0x7e 929 00:02:07 0x0000007f 0x7f 930 00:02:08 0x00000080 0x80 931 00:02:24 0x00000090 0x90 932 00:02:40 0x000000a0 0xa0 933 00:02:56 0x000000b0 0xb0 934 00:03:12 0x000000c0 0xc0 935 00:03:28 0x000000d0 0xd0 936 00:03:44 0x000000e0 0xe0 937 00:04:00 0x000000f0 0xf0 938 00:04:16 0x00000100 0x81 939 00:04:48 0x00000120 0x91 940 00:05:20 0x00000140 0xa1 941 00:05:52 0x00000160 0xb1 942 00:06:24 0x00000180 0xc1 943 00:06:56 0x000001a0 0xd1 944 00:07:28 0x000001c0 0xe1 945 00:08:00 0x000001e0 0xf1 946 00:08:32 0x00000200 0x82 947 00:09:36 0x00000240 0x92 948 00:10:40 0x00000280 0xa2 949 00:11:44 0x000002c0 0xb2 950 00:12:48 0x00000300 0xc2 951 00:13:52 0x00000340 0xd2 952 00:14:56 0x00000380 0xe2 953 00:16:00 0x000003c0 0xf2 954 00:17:04 0x00000400 0x83 955 00:19:12 0x00000480 0x93 956 00:21:20 0x00000500 0xa3 957 00:23:28 0x00000580 0xb3 958 00:25:36 0x00000600 0xc3 959 00:27:44 0x00000680 0xd3 960 00:29:52 0x00000700 0xe3 961 00:32:00 0x00000780 0xf3 962 00:34:08 0x00000800 0x84 963 00:38:24 0x00000900 0x94 964 00:42:40 0x00000a00 0xa4 965 00:46:56 0x00000b00 0xb4 966 00:51:12 0x00000c00 0xc4 967 00:55:28 0x00000d00 0xd4 968 00:59:44 0x00000e00 0xe4 969 01:04:00 0x00000f00 0xf4 970 01:08:16 0x00001000 0x85 971 01:16:48 0x00001200 0x95 972 01:25:20 0x00001400 0xa5 973 01:33:52 0x00001600 0xb5 974 01:42:24 0x00001800 0xc5 975 01:50:56 0x00001a00 0xd5 976 01:59:28 0x00001c00 0xe5 977 02:08:00 0x00001e00 0xf5 978 02:16:32 0x00002000 0x86 979 02:33:36 0x00002400 0x96 980 02:50:40 0x00002800 0xa6 981 03:07:44 0x00002c00 0xb6 982 03:24:48 0x00003000 0xc6 983 03:41:52 0x00003400 0xd6 984 03:58:56 0x00003800 0xe6 985 04:16:00 0x00003c00 0xf6 986 04:33:04 0x00004000 0x87 987 05:07:12 0x00004800 0x97 988 05:41:20 0x00005000 0xa7 989 06:15:28 0x00005800 0xb7 990 06:49:36 0x00006000 0xc7 991 07:23:44 0x00006800 0xd7 992 07:57:52 0x00007000 0xe7 993 08:32:00 0x00007800 0xf7 994 09:06:08 0x00008000 0x88 995 10:14:24 0x00009000 0x98 996 11:22:40 0x0000a000 0xa8 997 12:30:56 0x0000b000 0xb8 998 13:39:12 0x0000c000 0xc8 999 14:47:28 0x0000d000 0xd8 1000 15:55:44 0x0000e000 0xe8 1001 17:04:00 0x0000f000 0xf8 1002 18:12:16 0x00010000 0x89 1003 20:28:48 0x00012000 0x99 1004 22:45:20 0x00014000 0xa9 1005 1d 01:01:52 0x00016000 0xb9 1006 1d 03:18:24 0x00018000 0xc9 1007 1d 05:34:56 0x0001a000 0xd9 1008 1d 07:51:28 0x0001c000 0xe9 1009 1d 10:08:00 0x0001e000 0xf9 1010 1d 12:24:32 0x00020000 0x8a 1011 1d 16:57:36 0x00024000 0x9a 1012 1d 21:30:40 0x00028000 0xaa 1013 2d 02:03:44 0x0002c000 0xba 1014 2d 06:36:48 0x00030000 0xca 1015 2d 11:09:52 0x00034000 0xda 1016 2d 15:42:56 0x00038000 0xea 1017 2d 20:16:00 0x0003c000 0xfa 1018 3d 00:49:04 0x00040000 0x8b 1019 3d 09:55:12 0x00048000 0x9b 1020 3d 19:01:20 0x00050000 0xab 1021 4d 04:07:28 0x00058000 0xbb 1022 4d 13:13:36 0x00060000 0xcb 1023 4d 22:19:44 0x00068000 0xdb 1024 5d 07:25:52 0x00070000 0xeb 1025 5d 16:32:00 0x00078000 0xfb 1026 6d 01:38:08 0x00080000 0x8c 1027 6d 19:50:24 0x00090000 0x9c 1028 7d 14:02:40 0x000a0000 0xac 1029 8d 08:14:56 0x000b0000 0xbc 1030 9d 02:27:12 0x000c0000 0xcc 1031 9d 20:39:28 0x000d0000 0xdc 1032 10d 14:51:44 0x000e0000 0xec 1033 11d 09:04:00 0x000f0000 0xfc 1034 12d 03:16:16 0x00100000 0x8d 1035 13d 15:40:48 0x00120000 0x9d 1036 15d 04:05:20 0x00140000 0xad 1037 16d 16:29:52 0x00160000 0xbd 1038 18d 04:54:24 0x00180000 0xcd 1039 19d 17:18:56 0x001a0000 0xdd 1040 21d 05:43:28 0x001c0000 0xed 1041 22d 18:08:00 0x001e0000 0xfd 1042 24d 06:32:32 0x00200000 0x8e 1043 27d 07:21:36 0x00240000 0x9e 1044 30d 08:10:40 0x00280000 0xae 1045 33d 08:59:44 0x002c0000 0xbe 1046 36d 09:48:48 0x00300000 0xce 1047 39d 10:37:52 0x00340000 0xde 1048 42d 11:26:56 0x00380000 0xee 1049 45d 12:16:00 0x003c0000 0xfe 1050 48d 13:05:04 0x00400000 0x8f 1051 54d 14:43:12 0x00480000 0x9f 1052 60d 16:21:20 0x00500000 0xaf 1053 66d 17:59:28 0x00580000 0xbf 1054 72d 19:37:36 0x00600000 0xcf 1055 78d 21:15:44 0x00680000 0xdf 1056 84d 22:53:52 0x00700000 0xef 1057 91d 00:32:00 0x00780000 0xff (reserved) 1059 Figure 11 1061 Authors' Addresses 1063 Carsten Bormann 1064 Universitaet Bremen TZI 1065 Postfach 330440 1066 Bremen D-28359 1067 Germany 1069 Phone: +49-421-218-63921 1070 Fax: +49-421-218-7000 1071 Email: cabo@tzi.org 1073 Klaus Hartke 1074 Universitaet Bremen TZI 1075 Postfach 330440 1076 Bremen D-28359 1077 Germany 1079 Phone: +49-421-218-63905 1080 Fax: +49-421-218-7000 1081 Email: hartke@tzi.org