idnits 2.17.00 (12 Aug 2021) /tmp/idnits21205/draft-bormann-coap-misc-27.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 809 has weird spacing: '... code mid...' -- The document date (November 14, 2014) is 2738 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 1541, but not defined -- Looks like a reference, but probably isn't: '0' on line 1180 == Unused Reference: 'CoRE201' is defined on line 432, but no explicit reference was found in the text == Outdated reference: draft-ietf-core-observe has been published as RFC 7641 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 18, 2015 November 14, 2014 7 Miscellaneous additions to CoAP 8 draft-bormann-coap-misc-27 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 18, 2015. 35 Copyright Notice 37 Copyright (c) 2014 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. Observing Resources in CoAP . . . . . . . . . . . . . . . . . 4 54 3. The Base-Uri Option . . . . . . . . . . . . . . . . . . . . . 6 55 4. CoAP Response Sets . . . . . . . . . . . . . . . . . . . . . 7 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 59 6.2. Informative References . . . . . . . . . . . . . . . . . 10 60 Appendix A. The Nursery (Things that still need to ripen a bit) 10 61 A.1. Envelope Options . . . . . . . . . . . . . . . . . . . . 10 62 A.2. Payload-Length Option . . . . . . . . . . . . . . . . . . 11 63 A.3. URI Authorities with Binary Adresses . . . . . . . . . . 12 64 A.4. Length-aware number encoding (o256) . . . . . . . . . . . 13 65 A.5. SMS encoding . . . . . . . . . . . . . . . . . . . . . . 15 66 A.5.1. ASCII-optimized SMS encoding . . . . . . . . . . . . 16 67 A.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 A.6.1. Requesting a Tunnel with CONNECT . . . . . . . . . . 19 69 A.6.2. Using a CONNECT Tunnel . . . . . . . . . . . . . . . 19 70 A.6.3. Closing down a CONNECT Tunnel . . . . . . . . . . . . 20 71 Appendix B. The Museum (Things we did, but maybe not exactly 72 this way) . . . . . . . . . . . . . . . . . . . . . 20 73 B.1. Getting rid of artificial limitations . . . . . . . . . . 20 74 B.1.1. Beyond 270 bytes in a single option . . . . . . . . . 21 75 B.1.2. Beyond 15 options . . . . . . . . . . . . . . . . . . 22 76 B.1.3. Implementing the option delimiter for 15 or more 77 options . . . . . . . . . . . . . . . . . . . . . . . 25 78 B.1.4. Option Length encoding beyond 270 bytes . . . . . . . 26 79 B.2. Registered Option . . . . . . . . . . . . . . . . . . . . 29 80 B.2.1. A Separate Suboption Number Space . . . . . . . . . . 29 81 B.2.2. Opening Up the Option Number Space . . . . . . . . . 30 82 B.3. Enabling Protocol Evolution . . . . . . . . . . . . . . . 34 83 B.3.1. Potential new option number allocation . . . . . . . 35 84 B.4. Patience, Leisure, and Pledge . . . . . . . . . . . . . . 37 85 B.4.1. Patience . . . . . . . . . . . . . . . . . . . . . . 37 86 B.4.2. Leisure . . . . . . . . . . . . . . . . . . . . . . . 38 87 B.4.3. Pledge . . . . . . . . . . . . . . . . . . . . . . . 38 88 B.4.4. Option Formats . . . . . . . . . . . . . . . . . . . 39 89 Appendix C. The Cemetery (Things we won't do) . . . . . . . . . 39 90 C.1. Example envelope option: solving #230 . . . . . . . . . . 39 91 C.2. Example envelope option: proxy-elective options . . . . . 40 92 C.3. Stateful URI compression . . . . . . . . . . . . . . . . 41 93 Appendix D. Experimental Options . . . . . . . . . . . . . . . . 42 94 D.1. Options indicating absolute time . . . . . . . . . . . . 42 95 D.2. Representing Durations . . . . . . . . . . . . . . . . . 43 96 D.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 45 97 D.4. Pseudo-Floating Point . . . . . . . . . . . . . . . . . . 45 98 D.5. A Duration Type for CoAP . . . . . . . . . . . . . . . . 46 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 101 1. Introduction 103 The CoRE WG is tasked with standardizing an Application Protocol for 104 Constrained Networks/Nodes, CoAP [RFC7252]. This protocol is 105 intended to provide RESTful [REST] services not unlike HTTP 106 [RFC2616], while reducing the complexity of implementation as well as 107 the size of packets exchanged in order to make these services useful 108 in a highly constrained network of themselves highly constrained 109 nodes. 111 This objective requires restraint in a number of sometimes 112 conflicting ways: 114 o reducing implementation complexity in order to minimize code size, 116 o reducing message sizes in order to minimize the number of 117 fragments needed for each message (in turn to maximize the 118 probability of delivery of the message), the amount of 119 transmission power needed and the loading of the limited-bandwidth 120 channel, 122 o reducing requirements on the environment such as stable storage, 123 good sources of randomness or user interaction capabilities. 125 This draft attempts to address a number of problems not yet 126 adequately solved in [RFC7252]. The solutions proposed to these 127 problems are somewhat interrelated and are therefore presented in one 128 draft. As of the current version of the draft, the main body is 129 almost empty, since few significant problems remain with CoAP or its 130 satellite specifications. 132 The appendix contains the "CoAP cemetery" (Appendix C, possibly later 133 to move into its own draft), documenting roads that the WG decided 134 not to take, in order to spare readers from reinventing them in vain. 135 There is also a "CoAP museum" (Appendix B), which documents previous 136 forms of proposals part of which did make it into the main documents 137 in one form or another. Finally, the "CoAP nursery" (Appendix A) 138 contains half- to fully-baked proposals that might become interesting 139 as the basis for future extensions. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 The term "byte" is used in its now customary sense as a synonym for 146 "octet". 148 2. Observing Resources in CoAP 150 (Co-Author for this section: Matthias Kovatsch) 152 There are two open issues related to -observe 153 [I-D.ietf-core-observe]: 155 o mixing freshness and observation lifetime, and 157 o non-cacheable resources. 159 To solve the first issue, we think that -observe should be clarified 160 as follows: 162 A server sends at least some notifications as confirmable messages. 163 Each confirmable notification is an opportunity for the server to 164 check if the client is still there. If the client acknowledges the 165 notification, it is assumed to be well and alive and still interested 166 in the resource. If it rejects the message with a reset message or 167 if it doesn't respond, it is assumed not longer to be interested and 168 is removed from the list of observers. So an observation 169 relationship can potentially go on forever, if the client 170 acknowledges each confirmable notification. If the server doesn't 171 send a notification for a while and wants to check if the client is 172 still there, it may send a confirmable notification with the current 173 resource state to check that. 175 So there is no mixing of freshness and lifetime going on. 177 The other issue is a bit less trivial to solve. The problem is that 178 normal CoAP and -observe actually have very different freshness 179 models: 181 Normally, when a client wants to know the current state of a 182 resource, it retrieves a representation, uses it and stores it in its 183 cache. Later, when it wants to know the current state again, it can 184 either use the stored representation provided that it's still fresh, 185 or retrieve a new representation, use it and store it in its cache. 187 If a server knows when the state of the resource will change the next 188 time, it can set the Max-Age of the representation to an accurate 189 time span. So the change of the resource state will coincide with 190 the expiration of the freshness of the representation stored in the 191 client's cache (ignoring network latency). 193 But if the resource changes its state unpredictably at any time, the 194 server can set the Max-Age only to an estimate. If the state then 195 actually changes before the freshness expires, the client wrongly 196 believes it has fresh information. Conversely, if the freshness 197 expires and the client wants to know the current state, the client 198 wrongly believes it has to make a new request although the 199 representation is actually still fresh (this is defused by ETag 200 validation). 202 -observe doesn't have these kinds of problems: the server does not 203 have to predict when the resource will change its state the next 204 time. It just sends a notification when it does. The new 205 representation invalidates the old representation stored in the 206 client's cache. So the client always has a fresh representation that 207 it can use when it wants to know the current resource state without 208 ever having to make a request. An explicit Max-Age is not needed for 209 determining freshness. 211 But -observe has a different set of problems: 213 The first problem is that the resource may change its state more 214 often than there is bandwidth available or the client can handle. 215 Thus, -observe cannot make any guarantee that a client will see every 216 state change. The solution is that -observe guarantees that the 217 client will eventually see the latest state change, and follows a 218 best effort approach to enable the client to see as many state 219 changes as possible. 221 The second problem is that, when a notification doesn't arrive for a 222 while, the client does not know if the resource did not change its 223 state or if the server lost its state and forgot that the client is 224 interested in the resource. We propose the following solution: With 225 each notification that the server sends, it makes a promise to send 226 another notification, and that it will send this next notification at 227 latest after a certain time span. This time span is included with 228 each notification. So when no notification arrives for a while and 229 the time span has not expired yet, the client assumes that the 230 resource did not change its state. If the time span has expired, no 231 notification has arrived and the client wants to know the current 232 state of the resource, it has to make a new request. 234 The third problem is that, when an intermediary is observing a 235 resource and wants to create a response from a representation stored 236 in its cache, it needs to specify a Max-Age. But the intermediary 237 cannot predict when it will receive the next notification, because 238 the next notification can arrive at any time. Unlike the origin 239 server, it also doesn't have the application-specific knowledge that 240 the origin server has. We propose the following solution: With each 241 notification a server sends, it includes a value that an intermediary 242 should use to calculate the Max-Age. 244 To summarize: 246 o A notification doesn't have a Max-Age; it's fresh until the next 247 notification arrives. A notification is the promise for another 248 notification that will arrive at latest after Next-Notification- 249 At-Latest. This value is included with every notification. The 250 promise includes that the server attempts to transmit a 251 notification to the client for the promised time span, even if the 252 client does not seem to respond, e.g., due to a temporary network 253 outage. 255 o A notification also contains another value, called Max-Age-Hint. 256 This value is used by a cache to calculate a Max-Age for the 257 representation if needed. In a cache, the Max-Age-Hint of a 258 representation is counted down like Max-Age. When it reaches 259 zero, however, the representation can be still used to satisfy 260 requests, but is non-cacheable (i.e., Max-Age is 0). The Max-Age- 261 Hint must be less than or equal to Next-Notification-At-Latest. 263 We see two possible ways to encode Next-Notification-At-Latest and 264 Max-Age-Hint in a message: 266 o The first way is to require the values of Next-Notification-At- 267 Latest and Max-Age-Hint to be the same, although they are 268 conceptually unrelated. Then, a single option in the message can 269 be used to hold both values. 271 o The second way is to include two options, one for Next- 272 Notification-At-Latest and one for Max-Age-Hint. Since Next- 273 Notification-At-Latest is less than or equal to Max-Age-Hint, the 274 first option should indicates Max-Age-Hint, and the second option 275 Next-Notification-At-Latest minus Max-Age-Hint with a default 276 value of 0. 278 3. The Base-Uri Option 280 A proxy that forwards a response with embedded URIs may need to 281 indicate a base URI relative to which the embedded URIs need to be 282 interpreted that is different from the original request URI. E.g., 283 when the proxy forwarded the request to a multicast address, it may 284 need to indicate which specific server sent the response. A similar 285 requirement is the need to provide a request URI relative to which 286 the Location-* options can be interpreted. 288 The Base-Uri Option can be used in a response to provide this 289 information. It is structured like the Proxy-Uri option, but it is 290 elective and safe to forward (whether it is a cache-key is 291 irrelevant, as it is a response option only). 293 +--------+----------+-----------+ 294 | Number | Name | Reference | 295 +--------+----------+-----------+ 296 | TBD | Base-Uri | [RFCXXXX] | 297 +--------+----------+-----------+ 299 4. CoAP Response Sets 301 A proxy may receive multiple responses to a multicast request and may 302 want to make the entire response set available in its response. 304 A response set is represented in CBOR [RFC7049] as an array of 305 responses. 307 Each single response is represented as a map, keyed by integers. 308 Non-negative integers give the respective CoAP response options; for 309 these, the map values are coded according to the type given for the 310 option: as integers (for options of type uint), text strings (for 311 options of type string), or byte strings (for options of type opaque 312 and for options unknown to the proxy). The following negative 313 integers are defined as additional map keys for responses: 315 -1: payload, encoded as a byte string. If the content-format is 316 known to be a UTF-8 string (such as content formats 0 (text/ 317 plain), 40 (application/link-format) or 50 (application/json)), 318 the payload MAY alternatively be encoded as a text string. 320 -2: IP address of the end-point that sent the response. Coded as a 321 byte string of 16 bytes (IPv6) or 4 bytes (IPv4). 323 -3: Port number of the end-point that sent the response, coded as an 324 integer. A port number of 5683 MAY be elided. 326 -4: CoAP Response code, coded as an integer. A response code of 327 2.05 (value 69) MAY be elided. 329 An example for a response set (mixing IPv4 and IPv6 addresses for 330 illustration only), given in CBOR diagnostic notation: 332 [{ 333 12: 40, 334 14: 86400, 335 4: h'08154711', 336 -1: ";if=\"sensor\"", 337 -2: h'20010db800001234000000fffe007654' 338 },{ 339 12: 40, 340 14: 604800, 341 4: h'70dbd7f64469', 342 -1: ";if=\"sensor\"", 343 -2: h'c0000249' 344 }] 346 Encoded in CBOR, this leads to the following sequence of bytes: 348 82 # array(2) 349 a5 # map(5) 350 0c # unsigned(12) 351 18 28 # unsigned(40) 352 0e # unsigned(14) 353 1a 00015180 # unsigned(86400) 354 04 # unsigned(4) 355 44 # bytes(4) 356 08154711 357 20 # negative(0) 358 78 1c # text(28) 359 3c2f73656e736f72732f6c696768743e3b69663d2273656e736f7222 360 21 # negative(1) 361 50 # bytes(16) 362 20010db800001234000000fffe007654 363 a5 # map(5) 364 0c # unsigned(12) 365 18 28 # unsigned(40) 366 0e # unsigned(14) 367 1a 00093a80 # unsigned(604800) 368 04 # unsigned(4) 369 46 # bytes(6) 370 70dbd7f64469 371 20 # negative(0) 372 78 1b # text(27) 373 3c2f73656e736f72732f74656d703e3b69663d2273656e736f7222 374 21 # negative(1) 375 44 # bytes(4) 376 c0000249 378 5. Acknowledgements 380 This work was partially funded by the Klaus Tschira Foundation and by 381 Intel Corporation. 383 Of course, much of the content of this draft is the result of 384 discussions with the [RFC7252] authors. 386 Patience and Leisure were influenced by a mailing list discussion 387 with Esko Dijk, Kepeng Li, and Salvatore Loreto - thanks! 389 Michael Dorin found a bug in the efficient SMS encoding (and alerted 390 us to insufficient explanation). 392 6. References 394 6.1. Normative References 396 [I-D.ietf-core-observe] 397 Hartke, K., "Observing Resources in CoAP", draft-ietf- 398 core-observe-15 (work in progress), October 2014. 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 404 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 405 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 407 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 408 Encodings", RFC 4648, October 2006. 410 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 411 Values in Protocols", RFC 6256, May 2011. 413 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 414 Representation (CBOR)", RFC 7049, October 2013. 416 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 417 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 418 2014. 420 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 421 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 423 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 424 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 425 2014. 427 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 428 Application Protocol (CoAP)", RFC 7252, June 2014. 430 6.2. Informative References 432 [CoRE201] "Clarify use of retransmission window for duplicate 433 detection", CoRE ticket #201, 2012, 434 . 436 [CoRE214] "Adopt vendor-defined option into core-coap", CoRE ticket 437 #214, 2012, 438 . 440 [CoRE230] "Multiple Location options need to be processed as a 441 unit", CoRE ticket #230, 2012, 442 . 444 [CoRE241] "Proxy Safe & Cache Key indication for options", CoRE 445 ticket #241, 2012, 446 . 448 [REST] Fielding, R., "Architectural Styles and the Design of 449 Network-based Software Architectures", 2000. 451 [RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", RFC 452 1924, April 1996. 454 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 455 HTTP/1.1", RFC 2817, May 2000. 457 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 458 Interchange", RFC 5198, March 2008. 460 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 461 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 462 May 2008. 464 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 465 "Deprecating the "X-" Prefix and Similar Constructs in 466 Application Protocols", BCP 178, RFC 6648, June 2012. 468 Appendix A. The Nursery (Things that still need to ripen a bit) 470 A.1. Envelope Options 472 As of [RFC7252], options can take one of four types, two of which are 473 mostly identical: 475 o uint: A non-negative integer which is represented in network byte 476 order using a variable number of bytes (see [RFC7252] Appendix A); 478 o string: a sequence of bytes that is nominally a Net-Unicode string 479 [RFC5198]; 481 o opaque: a sequence of bytes. 483 o empty (not explicitly identified as a fourth type in [RFC7252]). 485 It turns out some options would benefit from some internal structure. 486 Also, it may be a good idea to be able to bundle multiple options 487 into one, in order to ensure consistency for a set of elective 488 options that need to be processed all or nothing (i.e., the option 489 becomes critical as soon as another option out of the set is 490 processed, too). 492 In this section, we introduce a fifth CoAP option type: Envelope 493 options. 495 An envelope option is a sequence of bytes that looks and is 496 interpreted exactly like a CoAP sequence of options. Instead of an 497 option count or an end-of-option marker, the sequence of options is 498 terminated by the end of the envelope option. 500 The nested options (options inside the envelope option) may come from 501 the same number space as the top-level CoAP options, or the envelope 502 option may define its own number space - this choice needs to be 503 defined for each envelope option. 505 If the top-level number space is used, the envelope option typically 506 will restrict the set of options that actually can be used in the 507 envelope. In particular, it is unlikely that an envelope option will 508 allow itself inside the envelope (this would be a recursive option). 510 Envelope options are a general, but simple mechanism. Some of its 511 potential uses are illustrated by two examples in the cemetery: 512 Appendix C.1 and Appendix C.2. (Each of these examples has its own 513 merits and demerits, which led us to decide not to pursue either of 514 them right now, but this should be discussed separately from the 515 concept of Envelope options employed in the examples.) 517 A.2. Payload-Length Option 519 Not all transport mappings may provide an unambiguous length of the 520 CoAP message. For UDP, it may also be desirable to pack more than 521 one CoAP message into one UDP payload (aggregation); in that case, 522 for all but the last message there needs to be a way to delimit the 523 payload of that message. 525 This can be solved using a new option, the Payload-Length option. If 526 this option is present, the value of this option is an unsigned 527 integer giving the length of the payload of the message (note that 528 this integer can be zero for a zero-length payload, which can in turn 529 be represented by a zero-length option value). (In the UDP 530 aggregation case, what would have been in the payload of this message 531 after "payload-length" bytes is then actually one or more additional 532 messages.) 534 A.3. URI Authorities with Binary Adresses 536 One problem with the way URI authorities are represented in the URI 537 syntax is that the authority part can be very bulky if it encodes an 538 IPv6 address in ASCII. 540 Proposal: Provide an option "Uri-Authority-Binary" that can be an 541 even number of bytes between 2 and 18 except 12 or 14. 543 o If the number of bytes is 2, the destination IP address of the 544 packet transporting the CoAP message is implied. 546 o If the number of bytes is 4 or 6, the first four bytes of the 547 option value are an IPv4 address in binary. 549 o If the number of bytes is 8 or 10, the first eight bytes are the 550 lower 64 bits of an IPv6 address; the upper eight bytes are 551 implied from the destination address of the packet transporting 552 the CoAP message. 554 o If the number of bytes is 16 or 18, the first 16 bytes are an IPv6 555 address. 557 o If two more bytes remain, this is a port number (as always in 558 network byte order). 560 The resulting authority is (conceptually translated into ASCII and) 561 used in place of an Uri-Authority option, or inserted into a Proxy- 562 Uri. Examples: 564 +-------------+------------------+---------+------------------------+ 565 | Proxy-Uri | Uri-Authority- | Uri- | URI | 566 | | Binary | Path | | 567 +-------------+------------------+---------+------------------------+ 568 | (none) | (none) | (none) | "/" | 569 | | | | | 570 | (none) | (none) | 'temp' | "/temp" | 571 | | | | | 572 | (none) | 2 bytes: 61616 | 'temp' | "coap://[DA]:61616/tem | 573 | | | | p" | 574 | | | | | 575 | (none) | 16 bytes: | temp | "coap://[2000::1]/temp | 576 | | 2000::1 | | " | 577 | | | | | 578 | 'http://' | 10 bytes: | (none) | "http://[DA::123:45]:6 | 579 | | ::123:45 + 616 | | 16" | 580 | | | | | 581 | 'http:///te | 18 bytes: | (none) | "http://[2000::1]:616/ | 582 | mp' | 2000::1 + 616 | | temp" | 583 +-------------+------------------+---------+------------------------+ 585 A.4. Length-aware number encoding (o256) 587 The number encoding defined in Appendix A of [RFC7252] has one 588 significant flaw: Every number has an infinite number of 589 representations, which can be derived by adding leading zero bytes. 590 This runs against the principle of minimizing unnecessary choice. 591 The resulting uncertainty in encoding ultimately leads to unnecessary 592 interoperability failures. (It also wastes a small fraction of the 593 encoding space, i.e., it wastes bytes.) 595 We could solve the first, but not the second, by outlawing leading 596 zeroes, but then we have to cope with error cases caused by illegal 597 values, another source of interoperability problems. 599 The number encoding "o256" defined in this section avoids this flaw. 600 The suggestion is not to replace CoAP's "uint" encoding wholesale 601 (CoAP is already too widely implemented for such a change), but to 602 consider this format for new options. 604 The basic requirements for such an encoding are: 606 o numbers are encoded as a sequence of zero or more bytes 608 o each number has exactly one encoding 609 o for a < b, encoding-size(a) <= encoding-size(b) -- i.e., with 610 larger numbers, the encoding only gets larger, never smaller 611 again. 613 o within each encoding size (0 bytes, 1 byte, etc.), lexicographical 614 ordering of the bytes is the same as numeric ordering 616 Obviously, there is only one encoding that satisfies all these 617 requirements. As illustrated by Figure 1, this is unambiguously 618 derived by 620 1. enumerating all possible byte sequences, ordered by length and 621 within the same length in lexicographic ordering, and, 623 2. assigning sequential cardinals. 625 0x'' -> 0 626 0x'00' -> 1 627 0x'01' -> 2 628 0x'02' -> 3 629 ... 630 0x'fe' -> 255 631 0x'ff' -> 256 632 0x'0000' -> 257 633 0x'0001' -> 258 634 ... 635 0x'fefd' -> 65534 636 0x'fefe' -> 65535 637 0x'feff' -> 65536 638 ... 639 0x'ffff' -> 65792 640 0x'000000' -> 65793 641 0x'000001' -> 65794 643 Figure 1: Enumerating byte sequences by length and then lexicographic 644 order 646 This results in an exceedingly simple algorithm: each byte is 647 interpreted in the base-256 place-value system, but stands for a 648 number between 1 and 256 instead of 0 to 255. We therefore call this 649 encoding "o256" (one-to-256). 0 is always encoded in zero bytes; 1 650 to 256 is one byte, 257 (0x101) to 65792 (0x10100) is two bytes, 651 65793 (0x10101) to 16843008 (0x1010100) is three bytes, etc. 653 To further illustrate the algorithmic simplicity, pseudocode for 654 encoding and decoding is given in Figure 2 and Figure 3, respectively 655 (in the encoder, "prepend" stands for adding a byte at the _leading_ 656 edge, the requirement for which is a result of the network byte 657 order). Note that this differs only in a single subtraction/addition 658 (resp.) of one from the canonical algorithm for Appendix A uints. 660 while num > 0 661 num -= 1 662 prepend(num & 0xFF) 663 num >>= 8 664 end 666 Figure 2: o256 encoder (pseudocode) 668 num = 0 669 each_byte do |b| 670 num <<= 8 671 num += b + 1 672 end 674 Figure 3: o256 decoder (pseudocode) 676 On a more philosophical note, it can be observed that o256 solves the 677 inverse problem of Self-Delimiting Numeric Values (SDNV) [RFC6256]: 678 SDNV encodes variable-length numbers together with their length 679 (allowing decoding without knowing their length in advance, deriving 680 delimiting information from the number encoding). o256 encodes 681 variable-length numbers when there is a way to separately convey the 682 length (as in CoAP options), encoding (and later deriving) a small 683 part of the numeric value into/from that size information. 685 A.5. SMS encoding 687 For use in SMS applications, CoAP messages can be transferred using 688 SMS binary mode. However, there is operational experience showing 689 that some environments cannot successfully send a binary mode SMS. 691 For transferring SMS in character mode (7-bit characters), 692 base64-encoding [RFC4648] is an obvious choice. 3 bytes of message 693 (24 bits) turn into 4 characters, which cosume 28 bits. The overall 694 overhead is approximately 17 %; the maximum message size is 120 bytes 695 (160 SMS characters). 697 If a more compact encoding is desired, base85 encoding can be 698 employed (however, probably not the version defined in [RFC1924] -- 699 instead, the version used in tools such as btoa and PDF should be 700 chosen). However, this requires division operations. Also, the 701 base85 character set includes several characters that cannot be 702 transferred in a single 7-bit unit in SMS and/or are known to cause 703 operational problems. A modified base85 character set can be defined 704 to solve the latter problem. 4 bytes of message (32 bits) turn into 705 5 characters, which consume 35 bits. The overall overhead is 706 approximately 9.3 %; the resulting maximum message size is 128 bytes 707 (160 SMS characters). 709 Base64 and base85 do not make use of the fact that much CoAP data 710 will be ASCII-based. Therefore, we define the following experimental 711 SMS encoding. 713 A.5.1. ASCII-optimized SMS encoding 715 Not all 128 theoretically possible SMS characters are operationally 716 free of problems. We therefore define: 718 Shunned code characters: @ sign, as it maps to 0x00 720 LF and CR signs (0x0A, 0x0D) 722 uppercase C cedilla (0x09), as it is often mistranslated in 723 gateways 725 ESC (0x1B), as it is used in certain character combinations only 727 Some ASCII characters cannot be transferred in the base SMS character 728 set, as their code positions are taken by non-ASCII characters. 729 These are simply encoded with their ASCII code positions, e.g., an 730 underscore becomes a section mark (even though underscore has a 731 different code position in the SMS character set). 733 Equivalently translated input bytes: $, @, [, \, ], ^, _, `, {, |, 734 }, ~, DEL 736 In other words, bytes 0x20 to 0x7F are encoded into the same code 737 positions in the 7-bit character set. 739 Out of the remaining code characters, the following SMS characters 740 are available for encoding: 742 Non-equivalently translated (NET) code characters: 0x01 to 0x08, (8 743 characters) 745 0x0B, 0x0C, (2 characters) 747 0x0E to 0x1A, (13 characters) 749 0x1C to 0x1F, (4 characters) 751 Of the 27 NET code characters, 18 are taken as prefix characters (see 752 below), and 8 are defined as directly translated characters: 754 Directly translated bytes: Equivalently translated input bytes are 755 represented as themselves 757 0x00 to 0x07 are represented as 0x01 to 0x08 759 This leaves 0x08 to 0x1F and 0x80 to 0xFF. Of these, the bytes 0x80 760 to 0x87 and 0xA0 to 0xFF are represented as the bytes 0x00 to 0x07 761 (represented by characters 0x01 to 0x08) and 0x20 to 0x7F, with a 762 prefix of 1 (see below). The characters 0x08 to 0x1F are represented 763 as the characters 0x28 to 0x3F with a prefix of 2 (see below). The 764 characters 0x88 to 0x9F are represented as the characters 0x48 to 765 0x5F with a prefix of 2 (see below). (Characters 0x01 to 0x08, 0x20 766 to 0x27, 0x40 to 0x47, and 0x60 to 0x7f with a prefix of 2 are 767 reserved for future extensions, which could be used for some 768 backreferencing or run-length compression.) 770 Bytes that do not need a prefix (directly translated bytes) are sent 771 as is. Any byte that does need a prefix (i.e., 1 or 2) is preceded 772 by a prefix character, which provides a prefix for this and the 773 following two bytes as follows: 775 +------+-----+---+------+-----+ 776 | char | pfx | . | char | pfx | 777 +------+-----+---+------+-----+ 778 | 0x0B | 100 | . | 0x15 | 200 | 779 | | | | | | 780 | 0x0C | 101 | . | 0x16 | 201 | 781 | | | | | | 782 | 0x0E | 102 | . | 0x17 | 202 | 783 | | | | | | 784 | 0x0F | 110 | . | 0x18 | 210 | 785 | | | | | | 786 | 0x10 | 111 | . | 0x19 | 211 | 787 | | | | | | 788 | 0x11 | 112 | . | 0x1A | 212 | 789 | | | | | | 790 | 0x12 | 120 | . | 0x1C | 220 | 791 | | | | | | 792 | 0x13 | 121 | . | 0x1D | 221 | 793 | | | | | | 794 | 0x14 | 122 | . | 0x1E | 222 | 795 +------+-----+---+------+-----+ 797 Table 1: SMS prefix character assignment 799 (This leaves one non-shunned character, 0x1F, for future extension.) 800 The coding overhead of this encoding for random bytes is similar to 801 Base85, without the need for a division/multiplication. For bytes 802 that are mostly ASCII characters, the overhead can easily become 803 negative. (Conversely, for bytes that are more likely to be non- 804 ASCII than in a random sequence of bytes, the overhead becomes 805 greater.) 807 So, for instance, for the CoAP message in Figure 4: 809 ver tt code mid 810 1 ack 2.05 17033 811 content_type 40 812 token sometok 813 3c 2f 3e 3b 74 69 74 6c 65 3d 22 47 65 6e 65 72 |;title="Gener| 814 61 6c 20 49 6e 66 6f 22 3b 63 74 3d 30 2c 3c 2f |al Info";ct=0,;if="clock"| 816 3b 72 74 3d 22 54 69 63 6b 73 22 3b 74 69 74 6c |;rt="Ticks";titl| 817 65 3d 22 49 6e 74 65 72 6e 61 6c 20 43 6c 6f 63 |e="Internal Cloc| 818 6b 22 3b 63 74 3d 30 2c 3c 2f 61 73 79 6e 63 3e |k";ct=0,| 819 3b 63 74 3d 30 |;ct=0 | 821 Figure 4: CoAP response message as captured and decoded 823 The 116 byte unencoded message is shown as ASCII characters in 824 Figure 5 (\xDD stands for the byte with the hex digits DD): 826 bEB\x89\x11(\xA7sometok;title="General Info";ct=0, 827 ;if="clock";rt="Ticks";title="Internal Clock";ct=0,;ct=0 829 Figure 5: CoAP response message shown as unencoded characters 831 The only non-ASCII characters in this example are in the beginning of 832 the message. According to the translation instructions above, the 833 four bytes: 835 89 11 ( A7 837 need the prefixes: 839 2 2 0 1 841 As each prefix character always covers three unencoded bytes, we need 842 the prefix characters for 220 and 100, which are \x1C and \x0B, 843 respectively (Table 1). 845 The equivalent SMS encoding is shown as equivalent-coded SMS 846 characters in Figure 6 (7 bits per character, \x1C is the 220 prefix 847 and \x0B is the 100 prefix, the rest is shown in equivalent 848 encoding), adding two characters of prefix overhead, for a total 849 length of 118 7-bit characters or 104 (103.25 plus padding) bytes: 851 bEB\x1CI1(\x0B'sometok;title="General Info";ct=0, 852 ;if="clock";rt="Ticks";title="Internal Clock";ct=0,;ct=0 854 Figure 6: CoAP response message shown as SMS-encoded characters 856 A.6. CONNECT 858 [RFC2817] defines the HTTP CONNECT method to establish a TCP tunnel 859 through a proxy so that end-to-end TLS connections can be made 860 through the proxy. Recently, a requirement for similar functionality 861 has been discussed for CoAP. This section defines a straw-man 862 CONNECT method and related methods and response codes for CoAP. 864 (IANA considerations for this section TBD.) 866 A.6.1. Requesting a Tunnel with CONNECT 868 CONNECT is allocated as a new method code in the "CoAP Method Codes" 869 registry. When a client makes a CONNECT request to an intermediary, 870 the intermediary evaluates the Uri-Host, Uri-Port, and/or the 871 authority part of the Proxy-Uri Options in a way that is defined by 872 the security policy of the intermediary. If the security policy 873 allows the allocation of a tunnel based on these parameters, the 874 method returns an empty payload and a response code of 2.30 Tunnel 875 Established. Other possible response codes include 4.03 Forbidden. 877 It may be the case that the intermediary itself can only reach the 878 requested origin server through another intermediary. In this case, 879 the first intermediary SHOULD make a CONNECT request of that next 880 intermediary, requesting a tunnel to the authority. A proxy MUST NOT 881 respond with any 2.xx status code unless it has either a direct or 882 tunnel connection established to the authority. 884 An origin server which receives a CONNECT request for itself MAY 885 respond with a 2.xx status code to indicate that a tunnel is 886 established to itself. 888 Code 2.30 "Tunnel Established" is allocated as a new response code in 889 the "CoAP Response Codes" registry. 891 A.6.2. Using a CONNECT Tunnel 893 Any successful (2.xx) response to a CONNECT request indicates that 894 the intermediary has established a tunnel to the requested host and 895 port. The tunnel is bound to the requesting end-point and the Token 896 supplied in the request (as always, the default Token is admissible). 897 The tunnel can be used by the client by making a DATAGRAM request. 899 DATAGRAM is allocated as a new method code in the "CoAP Method Codes" 900 registry. When a client makes a DATAGRAM request to an intermediary, 901 the intermediary looks up the tunnel bound to the client end-point 902 and Token supplied in the DATAGRAM request (no other Options are 903 permitted). If a tunnel is found and the intermediary's security 904 policy permits, the intermediary forwards the payload of the DATAGRAM 905 request as the UDP payload towards the host and port established for 906 the tunnel. No response is defined for this request (note that the 907 request can be given as a CON or NON request; for CON, there will be 908 an ACK on the message layer if the tunnel exists). 910 The security policy on the intermediary may restrict the allowable 911 payloads based on its security policy, possibly considering host and 912 port. An inadmissible payload SHOULD cause a 4.03 Forbidden response 913 with a diagnostic message as payload. 915 The UDP payload of any datagram received from the tunnel and admitted 916 by the security policy is forwarded to the client as the payload of a 917 2.31 "Datagram Received" response. The response does not carry any 918 Option except for Token, which identifies the tunnel towards the 919 client. 921 Code 2.31 "Datagram Received" is allocated as a new response code in 922 the "CoAP Response Codes" registry. 924 An origin server that has established a tunnel to itself processes 925 the CoAP payloads of related DATAGRAM requests as it would process an 926 incoming UDP payload, and forwards what would be outgoing UDP 927 payloads in 2.31 "Datagram Received" responses. 929 A.6.3. Closing down a CONNECT Tunnel 931 A 2.31 "Datagram Received" response may be replied to with a RST, 932 which closes down the tunnel. Similarly, the Token used in the 933 tunnel may be reused by the client for a different purpose, which 934 also closes down the tunnel. 936 Appendix B. The Museum (Things we did, but maybe not exactly this way) 938 B.1. Getting rid of artificial limitations 940 _Artificial limitations_ are limitations of a protocol or system that 941 are not rooted in limitations of actual capabilities, but in 942 arbitrary design decisions. Proper system design tries to avoid 943 artificial limitations, as these tend to cause complexity in systems 944 that need to work with these limitations. 946 E.g., the original UNIX filesystem had an artificial limitation of 947 the length of a path name component to 14 bytes. This led to a 948 cascade of workarounds in programs that manipulate file names: E.g., 949 systematically replacing a ".el" extension in a filename with a 950 ".elc" for the compiled file might exceed the limit, so all ".el" 951 files were suddenly limited to 13-byte filenames. 953 Note that, today, there still is a limitation in most file system 954 implementations, typically at 255. This just happens to be high 955 enough to rarely be of real-world concern; we will refer to this case 956 as a "painless" artificial limitation. 958 CoAP-08 had two highly recognizable artificial limitations in its 959 protocol encoding 961 o The number of options in a single message is limited to 15 max. 963 o The length of an option is limited to 270 max. 965 It has been argued that the latter limitation causes few problems, 966 just as the 255-byte path name component limitation in filenames 967 today causes few problems. Appendix B.1.1 provided a design to 968 extend this; as a precaution to future extensions of this kind, the 969 current encoding for length 270 (eight ones in the extension byte) 970 could be marked as reserved today. Since, Matthias Kovatsch has 971 proposed a simpler scheme that seems to gain favor in the WG, see 972 Appendix B.1.4. 974 The former limitation has been solved in CoAP-09. A historical 975 discussion of other approaches for going beyond 15 options is in 976 Appendix B.1.2. Appendix B.1.3 discusses implementation. 978 B.1.1. Beyond 270 bytes in a single option 980 The authors would argue that 270 as the maximum length of an option 981 is already beyond the "painless" threshold. 983 If that is not the consensus of the WG, the scheme can easily be 984 extended as in Figure 7: 986 for 15..269: 987 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 988 | Option Delta | 1 1 1 1 | Length - 15 | 989 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 990 | Option Value ... 991 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 993 for 270..65805: 994 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 995 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 996 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 997 | Length - 270 (in network byte order) | 998 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 999 | Option Value ... 1000 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1002 Figure 7: Ridiculously Long Option Header 1004 The infinite number of obvious variations on this scheme are left as 1005 an exercise to the reader. 1007 Again, as a precaution to future extensions, the current encoding for 1008 length 270 (eight ones in the extension byte) could be marked as 1009 reserved today. 1011 B.1.2. Beyond 15 options 1013 (This section keeps discussion that is no longer needed as we have 1014 agreed to do what is documented in Appendix B.1.3). 1016 The limit of 15 options is motivated by the fixed four-bit field "OC" 1017 that is used for indicating the number of options in the fixed-length 1018 CoAP header (Figure 8). 1020 0 1 2 3 1021 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 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 |Ver| T | OC | Code | Message ID | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Options (if any) ... 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Payload (if any) ... 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 Figure 8: Four-byte fixed header in a CoAP Message 1032 Note that there is another fixed four-bit field in CoAP: the option 1033 length (Figure 9 - note that this figure is not to the same scale as 1034 the previous figure): 1036 0 1 2 3 4 5 6 7 1037 +---+---+---+---+---+---+---+---+ 1038 | Option Delta | Length | for 0..14 1039 +---+---+---+---+---+---+---+---+ 1040 | Option Value ... 1041 +---+---+---+---+---+---+---+---+ 1043 Figure 9: Short Option Header 1045 Since 15 is inacceptable for a maximum option length, the all-ones 1046 value (15) was taken out of the set of allowable values for the short 1047 header, and a long header was introduced that allows the insertion of 1048 an extension byte (Figure 10): 1050 for 15..270: 1051 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1052 | Option Delta | 1 1 1 1 | Length - 15 | 1053 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1054 | Option Value ... 1055 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1057 Figure 10: Long Option Header 1059 We might want to use the same technique for the CoAP header as well. 1060 There are two obvious places where the extension byte could be 1061 placed: 1063 1. right after the byte carrying the OC field, so the structure is 1064 the same as for the option header; 1066 2. right after the fixed-size CoAP header. 1068 Both solutions lose the fixed-size-ness of the CoAP header. 1070 Solution 1 has the disadvantage that the CoAP header is also changing 1071 in structure: The extension byte is wedged between the first and the 1072 second byte of the CoAP header. This is unfortunate, as the number 1073 of options only comes into play when the option processing begins, so 1074 it is more natural to use solution 2 (Figure 11): 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 |Ver| T | 15 | Code | Message ID | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | OC - 15 | Options ... 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Payload (if any) ... 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Figure 11: Extended header for CoAP Messages with 15+ options 1088 This would allow for up to 270 options in a CoAP message, which is 1089 very likely way beyond the "painless" threshold. 1091 B.1.2.1. Implementation considerations 1093 For a message decoder, this extension creates relatively little pain, 1094 as the number of options only becomes interesting when the encoding 1095 turns to the options part of the message, which is then simply lead 1096 in by the extension byte if the four-bit field is 15. 1098 For a message encoder, this extension is not so rosy. If the encoder 1099 is constructing the message serially, it may not know in advance 1100 whether the number of options will exceed 14. None of the following 1101 implementation strategies is particularly savory, but all of them do 1102 work: 1104 1. Encode the options serially under the assumption that the number 1105 of options will be 14 or less. When the 15th option needs to be 1106 encoded, abort the option encoding, and restart it from scratch 1107 one byte further to the left. 1109 2. Similar to 1, except that the bytes already encoded are all moved 1110 one byte to right, the extension byte is inserted, and the option 1111 encoding process is continued. 1113 3. The encoder always leaves space for the extension byte (at least 1114 if it can't prove the number will be less thatn 14). If the 1115 extension byte is not needed, an Option 0 with length 0 is 1116 encoded instead (i.e., one byte is wasted - this option is 1117 elective and will be ignored by the receiver). 1119 As a minimum, to enable strategy 3, the option 0 should be reserved 1120 at least for the case of length=0. 1122 B.1.2.2. What should we do now? 1124 As a minimum proposal for the next version of CoAP, the value 15 for 1125 OC should be marked as reserved today. 1127 B.1.2.3. Alternatives 1129 One alternative that has been discussed previously is to have an 1130 "Options" Option, which allows the carriage of multiple options in 1131 the belly of a single one. This could also be used to carry more 1132 than 15 options. However: 1134 o The conditional introduction of an Options option has 1135 implementation considerations that are likely to be more severe 1136 than the ones listed above; 1138 o since 270 bytes may not be enough for the encoding of _all_ 1139 options, the "Options" option would need to be repeatable. This 1140 creates many different ways to encode the same message, leading to 1141 combinatorial explosion in test cases for ensuring 1142 interoperability. 1144 B.1.2.4. Alternative: Going to a delimiter model 1146 Another alternative is to spend the additional byte not as an 1147 extended count, but as an option terminator. 1149 B.1.3. Implementing the option delimiter for 15 or more options 1151 Implementation note: As can be seen from the proof of concept code 1152 in Figure 12, the actual implementation cost for a decoder is 1153 around 4 lines of code (or about 8-10 machine code instructions). 1155 while numopt > 0 1156 nextbyte = ... get next byte 1158 if numopt == 15 # new 1159 break if nextbyte == 0xF0 # new 1160 else # new 1161 numopt -= 1 1162 end # new 1164 ... decode delta and length from nextbyte and handle them 1165 end 1167 Figure 12: Implementing the Option Terminator 1169 Similarly, creating the option terminator needs about four more lines 1170 (not marked "old" in the C code in Figure 13). 1172 b0 = 0x40 + (tt << 4); /* old */ 1173 buffer[0] = b0 + 15; /* guess first byte */ 1175 .... encode options .... /* old */ 1177 if (option_count >= 15 || first_fragment_already_shipped) 1178 buffer[pos++] = 0xF0; /* use delimiter */ 1179 else /* save a byte: */ 1180 buffer[0] = b0 + option_count; /* old: backpatch */ 1182 Figure 13: Creating the Option Terminator 1184 B.1.4. Option Length encoding beyond 270 bytes 1186 For option lengths beyond 270 bytes, we reserve the value 255 of an 1187 extension byte to mean "add 255, read another extension byte" 1188 Figure 14. While this causes the length of the option header to grow 1189 linearly with the size of the option value, only 0.4 % of that size 1190 is used. With a focus on short options, this encoding is justified. 1192 for 15..269: 1193 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1194 | Option Delta | 1 1 1 1 | Length - 15 | 1195 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1196 | Option Value ... 1197 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1199 for 270..524: 1200 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1201 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 1202 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1203 | Length - 270 | Option Value ... 1204 +---+---+---+---+---+---+---+---+ 1205 | 1206 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1208 for 525..779: 1209 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1210 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 1211 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1212 | 1 1 1 1 1 1 1 1 | Length - 525 | 1213 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1214 | Option Value ... 1215 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1217 for 780..1034: 1218 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1219 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 1220 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1221 | 1 1 1 1 1 1 1 1 | 1 1 1 1 1 1 1 1 | 1222 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1223 | Length - 780 | Option Value ... 1224 +---+---+---+---+---+---+---+---+ 1225 | 1226 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1228 Figure 14: Options beyond 270 bytes 1230 Options that are longer than 1034 bytes MUST NOT be sent; an option 1231 that has 255 (all one bits) in the field called "Length - 780" MUST 1232 be rejected upon reception as an invalid option. 1234 In the process, the maximum length of all options that are currently 1235 set at 270 should now be set to a carefully chosen value. With the 1236 purely encoding-based limit gone, Uri-Proxy should now be restored to 1237 be a non-repeatable option. 1239 A first proposal for a new set of per-option length restrictions 1240 follows: 1242 +--------+---------------------+-----+------+--------+--------+ 1243 | number | name | min | max | type | repeat | 1244 +--------+---------------------+-----+------+--------+--------+ 1245 | 1 | content_type | 0 | 2 | uint | - | 1246 | | | | | | | 1247 | 2 | max_age | 0 | 4 | uint | - | 1248 | | | | | | | 1249 | 3 | proxy_uri | 1 | 1023 | string | - | 1250 | | | | | | | 1251 | 4 | etag | 1 | 8 | opaque | yes | 1252 | | | | | | | 1253 | 5 | uri_host | 1 | 255 | string | - | 1254 | | | | | | | 1255 | 6 | location_path | 0 | 255 | string | yes | 1256 | | | | | | | 1257 | 7 | uri_port | 0 | 2 | uint | - | 1258 | | | | | | | 1259 | 8 | location_query | 0 | 255 | string | yes | 1260 | | | | | | | 1261 | 9 | uri_path | 0 | 255 | string | yes | 1262 | | | | | | | 1263 | 10 | observe | 0 | 2 | uint | - | 1264 | | | | | | | 1265 | 11 | token | 1 | 8 | opaque | - | 1266 | | | | | | | 1267 | 12 | accept | 0 | 2 | uint | yes | 1268 | | | | | | | 1269 | 13 | if_match | 0 | 8 | opaque | yes | 1270 | | | | | | | 1271 | 14 | registered_elective | 1 | 1023 | opaque | yes | 1272 | | | | | | | 1273 | 15 | uri_query | 1 | 255 | string | yes | 1274 | | | | | | | 1275 | 17 | block2 | 0 | 3 | uint | - | 1276 | | | | | | | 1277 | 18 | size | 0 | 4 | uint | - | 1278 | | | | | | | 1279 | 19 | block1 | 0 | 3 | uint | - | 1280 | | | | | | | 1281 | 21 | if_none_match | 0 | 0 | empty | - | 1282 | | | | | | | 1283 | 25 | registered_critical | 1 | 1023 | opaque | yes | 1284 +--------+---------------------+-----+------+--------+--------+ 1286 (Option 14 with a length of 0 is a fencepost only.) 1288 B.2. Registered Option 1290 CoAP's option encoding is highly efficient, but works best with small 1291 option numbers that do not require much fenceposting. The CoAP 1292 Option Number Registry therefore has a relatively heavyweight 1293 registration requirement: "IETF Review" as described in [RFC5226]. 1295 However, there is also considerable benefit in a much looser registry 1296 policy, enabling a first-come-first-served policy for a relatively 1297 large option number space. 1299 Here, we discuss two solutions that enable such a registry. One is 1300 to define a separate mechanism for registered options, discussed in 1301 Appendix B.2.1. Alternatively, we could make it easier to use a 1302 larger main option number space, discussed in Appendix B.2.2. 1304 B.2.1. A Separate Suboption Number Space 1306 This alternative defines a separate space of suboption numbers, with 1307 an expert review [RFC5226] (or even first-come-first-served) 1308 registration policy. If expert review is selected for this registry, 1309 it would be with a relatively loose policy delegated to the expert. 1310 This draft proposes leaving the registered suboption numbers 0-127 to 1311 expert review with a policy that mainly focuses on the availability 1312 of a specification, and 128-16383 for first-come-first-served where 1313 essentially only a name is defined. 1315 The "registered" options are used in conjunction with this suboption 1316 number registry. They use two normal CoAP option numbers, one for 1317 options with elective semantics (Registered-Elective) and one for 1318 options with critical semantics (Registered-Critical). The suboption 1319 numbers are not separate, i.e. one registered suboption number might 1320 have some elective semantics and some other critical semantics (e.g., 1321 for the request and the response leg of an exchange). The option 1322 value starts with an SDNV [RFC6256] of the registered suboption 1323 number. (Note that there is no need for an implementation to 1324 understand SDNVs, it can treat the prefixes as opaque. One could 1325 consider the SDNVs as a suboption prefix allocation guideline for 1326 IANA as opposed to a number encoding.) 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 |1 0 0 0 0 0 0 1|0 1 1 1 0 0 1 1| value... | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 \___SDNV of registered number___/ 1333 Figure 15: Example option value for registered option 1335 Note that a Registered Option cannot be empty, because there would be 1336 no space for the SDNV. Also, the empty option 14 is reserved for 1337 fenceposting ([RFC7252], section 3.2). (Obviously, once a 1338 Registered-Elective Option is in use, there is never a need for a 1339 fence-post for option number 14.) 1341 The Registered-Elective and Registered-Critical Options are 1342 repeatable. 1344 +-----+----------+---------------------+---------+--------+---------+ 1345 | No. | C/E | Name | Format | Length | Default | 1346 +-----+----------+---------------------+---------+--------+---------+ 1347 | 14 | Elective | Registered-Elective | (see | 1-1023 | (none) | 1348 | | | | above) | B | | 1349 | | | | | | | 1350 | 25 | Critical | Registered-Critical | (see | 1-1023 | (none) | 1351 | | | | above) | B | | 1352 +-----+----------+---------------------+---------+--------+---------+ 1354 This solves CoRE issue #214 [CoRE214]. (How many options we need 1355 will depend on the resolution of #241 [CoRE241].) 1357 B.2.2. Opening Up the Option Number Space 1359 The disadvantage of the registered-... options is that there is a 1360 significant syntactic difference between options making use of this 1361 space and the usual standard options. This creates a problem not 1362 unlike that decried in [RFC6648]. 1364 The alternative discussed in this section reduces the distance by 1365 opening up the main Option number space instead. 1367 There is still a significant incentive to use low-numbered Options. 1368 However, the proposal reduces the penalty for using a high-numbered 1369 Option to two or three bytes. More importantly, using a cluster of 1370 related high-numbered options only carries a total penalty of two or 1371 three bytes. 1373 The main reason high-numbered options are expensive to use and thus 1374 the total space is relatively limited is that the option delta 1375 mechanism only allows increasing the current option number by up to 1376 14 per one-byte fencepost. To use, e.g., Option number 1234 together 1377 with the usual set of low-numbered Options, one needs to insert 88 1378 fence-post bytes. This is prohibitive. 1380 Enabling first-come-first-served probably requires easily addressing 1381 a 16-bit option number space, with some potential increase later in 1382 the lifetime of the protocol (say, 10 to 15 years from now). 1384 To enable the use of large option numbers, one needs a way to advance 1385 the Option number in bigger steps than possible by the Option Delta. 1386 So we propose a new construct, the Long Jump construct, to move the 1387 Option number forward. 1389 B.2.2.1. Long Jump construct 1391 The following construct can occur in front of any Option: 1393 0 1 2 3 4 5 6 7 1394 +---+---+---+---+---+---+---+---+ 1395 | 1 1 1 1 | 0 0 0 1 | 0xf1 (Delta = 15) 1396 +---+---+---+---+---+---+---+---+ 1398 0 1 2 3 4 5 6 7 1399 +---+---+---+---+---+---+---+---+ 1400 | 1 1 1 1 | 0 0 1 0 | 0xf2 1401 +---+---+---+---+---+---+---+---+ 1402 | Long Jump Value | (Delta/8)-2 1403 +---+---+---+---+---+---+---+---+ 1405 0 1 2 3 4 5 6 7 1406 +---+---+---+---+---+---+---+---+ 1407 | 1 1 1 1 | 0 0 1 1 | 0xf3 1408 +---+---+---+---+---+---+---+---+ 1409 | Long Jump Value, MSB | 1410 +---+---+---+---+---+---+---+---+ (Delta/8)-258 1411 | Long Jump Value, LSB | 1412 +---+---+---+---+---+---+---+---+ 1414 Figure 16: Long Jump Format 1416 This construct is not by itself an Option. It can occur in front of 1417 any Option to increase the current Option number that then goes into 1418 its Option number calculation. The increase is done in multiples of 1419 eight. More specifically, the actual addition to the current Option 1420 number is computed as follows: 1422 Delta = ((Long Jump Value) + N) * 8 1424 where N is 2 for the one-byte version and N is 258 for the two-byte 1425 version. 1427 A Long Jump MUST be followed by an actual Option, i.e., it MUST NOT 1428 be followed by another Long Jump or an end-of-options indicator. A 1429 message violating this MUST be rejected as malformed. 1431 Long Jumps do NOT count as Options in the Option Count field of the 1432 header (i.e., they cannot by themselves end the Option sequence). 1434 B.2.2.2. Discussion 1436 Adding a mechanism at this late stage creates concerns of backwards 1437 compatibility. A message sender never needs to implement long-jumps 1438 unless it wants to make use of a high-numbered option. So this 1439 mechanism can be added once a high-numbered option is added. A 1440 message receiver, though, would more or less unconditionally have to 1441 implement the mechanism, leading to unconditional additional 1442 complexity. There are good reasons to minimize this, as follows: 1444 o The increase in multiples of eight allows looking at an option and 1445 finding out whether it is critical or not even if the Long Jump 1446 value has just been skipped (as opposed to having been processed 1447 fully). (It also allows accessing up to approximately 2048 1448 options with a two-byte Long Jump.) This allows a basic 1449 implementation that does not implement any high-numbered options 1450 to simply ignore long jumps and any elective options behind them, 1451 while still properly reacting to critical options. 1453 o There is probably a good reason to disallow long-jumps that lead 1454 to an option number of 42 and less, enabling simple receivers to 1455 do the above simplification. 1457 o It might seem obvious to remove the fenceposting mechanism 1458 altogether in favor of long jumps. This is not advisable: 1459 Fenceposting already has zero implementation effort at the 1460 receiver, and the overhead at the sender is very limited (it is 1461 just a third kind of jump, at one byte per jump). Beyond 42, 1462 senders can ignore the existence of fenceposts if they want 1463 (possibly obviating the need for more complex base-14 arithmetic). 1465 There is no need for a finer granularity than 8, as the Option 1466 construct following can also specify a Delta of 0..14. (A 1467 granularity of 16 will require additional fenceposting where an 1468 option delta of 15 would happen to be required otherwise, which we 1469 have reserved. It can be argued that 16 is still the better choice, 1470 as fenceposting is already in the code path.) 1472 The Long Jump construct takes 0xf1 and 0xf2 from the space available 1473 for initial bytes of Options. (Note that we previously took 0xf0 to 1474 indicate end-of-options for OC=15.) 1476 Varying N with the length as defined above makes it unambiguous 1477 whether a one- or two-byte Long Jump is to be used. Setting N=2 for 1478 the one-byte version makes it clear that a Delta of 8 is to be 1479 handled the usual way (i.e., by Option Delta itself and/or 1480 fenceposting). If the delta is not small and not 7 modulo 8, there 1481 is still a choice between using the smaller multiple of 8 and a 1482 larger Delta in the actual Option or v.v., this biases the choice 1483 towards a larger Long Jump and a smaller following Delta, which is 1484 also easier to implement as it reduces the number of choice points. 1486 B.2.2.3. Example 1488 The following sequence of bytes would encode a Uri-Path Option of 1489 "foo" followed by Options 1357 (value "bar") and 1360 (value "baz"): 1491 93 65 6f 6f Option 9 (0 + 9, "foo") 1492 f1 a6 Long Jump by 1344 1493 43 62 61 72 Option 1357 (9 + 1344 + 4, "bar") 1494 33 62 61 7a Option 1360 (1357 + 3, "baz") 1496 Figure 17: Example using a Long Jump construct 1498 where f1 a6 is the long jump forward by (0xa6+2)*8=1344 option 1499 numbers. The total option count (OC) for the CoAP header is 3. Note 1500 that even if f1 a6 is skipped, the 1357 (which then appears as an 1501 Option number 13) is clearly visible as Critical. 1503 B.2.2.4. IANA considerations 1505 With the scheme proposed above, we could have three tiers of Option 1506 Numbers, differing in their allocation policy [RFC5226]: 1508 +---------------+-------------------------+ 1509 | Option Number | Policy | 1510 +---------------+-------------------------+ 1511 | 0..255 | Standards Action | 1512 | | | 1513 | 256..2047 | Designated Expert | 1514 | | | 1515 | 2048..65535 | First Come First Served | 1516 +---------------+-------------------------+ 1518 For the inventor of a new option, this would provide a small 1519 incentive to go through the designated expert for some minimal cross- 1520 checking in order to be able to use the two-byte long-jump. 1522 This draft adds option numbers to Table 2 of [RFC7252]: 1524 +--------+---------------------+-----------+ 1525 | Number | Name | Reference | 1526 +--------+---------------------+-----------+ 1527 | 14 | Registered-Elective | [RFCXXXX] | 1528 | | | | 1529 | 25 | Registered-Critical | [RFCXXXX] | 1530 +--------+---------------------+-----------+ 1532 Table 2: New CoAP Option Numbers 1534 This draft adds a suboption registry, initially empty. 1536 +------------+-----------------------------+-----------+ 1537 | Number | Name | Reference | 1538 +------------+-----------------------------+-----------+ 1539 | 0..127 | (allocate on export review) | [RFCXXXX] | 1540 | | | | 1541 | 128..16383 | (allocate fcfs) | [RFCXXXX] | 1542 +------------+-----------------------------+-----------+ 1544 Table 3: CoAP Suboption Numbers 1546 B.3. Enabling Protocol Evolution 1548 To enable a protocol to evolve, it is critical that new capabilities 1549 can be introduced without requiring changes in components that don't 1550 really care about the capability. One such probem is exhibited by 1551 CoAP options: If a proxy does not understand an elective option in a 1552 request, it will not be able to forward it to the origin server, 1553 rendering the new option ineffectual. Worse, if a proxy does not 1554 understand a critical option in a request, it will not be able to 1555 operate on the request, rendering the new option damaging. 1557 As a conclusion to the Ticket #230 discussion in the June 4th interim 1558 call, we decided to solve the identification of options that a proxy 1559 can safely forward even if not understood (previously called Proxy- 1560 Elective). 1562 The proposal is to encode this information in the option number, just 1563 like the way the information that an option is critical is encoded 1564 now. This leads to two bits with semantics: the lowest bit continues 1565 to be the critical bit, and the next higher bit is now the "unsafe" 1566 bit (i.e., this option is not safe to forward unless understood by 1567 the proxy). 1569 Another consideration (for options that are not unsafe to forward) is 1570 whether the option should serve as a cache key in a request. HTTP 1571 has a vary header that indicates in the response which header fields 1572 were considered by the origin server to be cache keys. In order to 1573 avoid this complexity, we should be able to indicate this information 1574 right in the option number. However, reserving another bit is 1575 wasteful, in particular as there are few safe-to-forward options that 1576 are not cache-keys. 1578 Therefore, we propose the following bit allocation in an option 1579 number: 1581 xxx nnn UC 1583 (where xxx is a variable length prefix, as option numbers are not 1584 bounded upwards). UC is the unsafe and critical bits. For U=0 only, 1585 if nnn is equal to 111 binary, the option does not serve as a cache 1586 key (for U=1, the proxy has to know the option to act on it, so there 1587 is no point in indicating whether it is a cache key). There is no 1588 semantic meaning of xxx. 1590 Note that clients and servers are generally not interested in this 1591 information. A proxy may use an equivalent of the following C code 1592 to derive the characteristics of an option number "onum": 1594 Critical = (onum & 1); 1595 UnSafe = (onum & 2); 1596 NoCache = ((onum & 0x1e) == 0x1c); 1598 Discussion: This requires a renumbering of all options. 1600 This renumbering may also be considered as an opportunity to make 1601 the numbering straight again shortly before nailing down the 1602 protocol 1604 In particular, Content-Type is now probably better considered to 1605 be elective. 1607 B.3.1. Potential new option number allocation 1609 We want to give one example for a revised allocation of option 1610 numbers. Option numbers are given as decimal numbers, one each for 1611 xxx, nnn, and UC, with the UC values as follows 1612 +-----------+------------+------------------------------------+ 1613 | UC binary | UC decimal | meaning | 1614 +-----------+------------+------------------------------------+ 1615 | 00 | 0 | (safe, elective, 111=no-cache-key) | 1616 | | | | 1617 | 01 | 1 | (safe, critical, 111=no-cache-key) | 1618 | | | | 1619 | 10 | 2 | (unsafe, elective) | 1620 | | | | 1621 | 11 | 3 | (unsafe, critical) | 1622 +-----------+------------+------------------------------------+ 1624 The table is: 1626 +-----+---------+-------+-------------------+-----------------------+ 1627 | New | xx nnn | Old | Name | Comment | 1628 | | UC | | | | 1629 +-----+---------+-------+-------------------+-----------------------+ 1630 | 4 | 0 1 0 | 1 | Content-Type | category change | 1631 | | | | | (elective) | 1632 | | | | | | 1633 | 8 | 0 2 0 | 4 | ETag | | 1634 | | | | | | 1635 | 12 | 0 3 0 | 12 | Accept | | 1636 | | | | | | 1637 | 16 | 0 4 0 | 6 | Location-Path | | 1638 | | | | | | 1639 | 20 | 0 5 0 | 8 | Location-Query | | 1640 | | | | | | 1641 | 24 | 0 6 0 | - | (unused) | | 1642 | | | | | | 1643 | 28 | 0 7 0 | 18 | Size | needs nnn=111 | 1644 | | | | | | 1645 | 32 | 1 0 0 | 20/22 | Patience | | 1646 | | | | | | 1647 | 64 | 2 x 0 | - | Location-reserved | (nnn = 0..3, 4 | 1648 | | | | | reserved numbers) | 1649 | | | | | | 1650 | 1 | 0 0 1 | 13 | If-Match | | 1651 | | | | | | 1652 | 5 | 0 1 1 | 21 | If-None-Match | | 1653 | | | | | | 1654 | 2 | 0 0 2 | 2 | Max-Age | | 1655 | | | | | | 1656 | 6 | 0 1 2 | 10 | Observe | | 1657 | | | | | | 1658 | 10 | 0 2 2 | xx | Observe-2 | | 1659 | | | | | | 1660 | 14 | 0 3 2 | xx | (unused) | was fencepost | 1661 | | | | | | 1662 | 3 | 0 0 3 | 3 | Proxy-Uri | | 1663 | | | | | | 1664 | 7 | 0 1 3 | 5 | Uri-Host | | 1665 | | | | | | 1666 | 11 | 0 2 3 | 7 | Uri-Port | | 1667 | | | | | | 1668 | 15 | 0 3 3 | 9 | Uri-Path | | 1669 | | | | | | 1670 | 19 | 0 4 3 | 15 | Uri-Query | | 1671 | | | | | | 1672 | 23 | 0 5 3 | 11 | Token | | 1673 | | | | | | 1674 | 27 | 0 6 3 | 17 | Block2 | | 1675 | | | | | | 1676 | 31 | 0 7 3 | 19 | Block1 | yes, we can use | 1677 | | | | | nnn=111 with U=1 | 1678 +-----+---------+-------+-------------------+-----------------------+ 1680 B.4. Patience, Leisure, and Pledge 1682 A number of options might be useful for controlling the timing of 1683 interactions. 1685 (This section also addresses core-coap ticket #177.) 1687 B.4.1. Patience 1689 A client may have a limited time period in which it can actually make 1690 use of the response for a request. Using the Patience option, it can 1691 provide an (elective) indication how much time it is willing to wait 1692 for the response from the server, giving the server license to ignore 1693 or reject the request if it cannot fulfill it in this period. 1695 If the server knows early that it cannot fulfill the request in the 1696 time requested, it MAY indicate this with a 5.04 "Timeout" response. 1697 For non-safe methods (such as PUT, POST, DELETE), the server SHOULD 1698 indicate whether it has fulfilled the request by either responding 1699 with 5.04 "Timeout" (and not further processing the request) or by 1700 processing the request normally. 1702 Note that the value of the Patience option should be chosen such that 1703 the client will be able to make use of the result even in the 1704 presence of the expected network delays for the request and the 1705 response. Similarly, when a proxy receives a request with a Patience 1706 option and cannot fulfill that request from its cache, it may want to 1707 adjust the value of the option before forwarding it to an upstream 1708 server. 1710 (TBD: The various cases that arise when combining Patience with 1711 Observe.) 1713 The Patience option is elective. Hence, a client MUST be prepared to 1714 receive a normal response even after the chosen Patience period (plus 1715 an allowance for network delays) has elapsed. 1717 B.4.2. Leisure 1719 Servers generally will compute an internal value that we will call 1720 Leisure, which indicates the period of time that will be used for 1721 responding to a request. A Patience option, if present, can be used 1722 as an upper bound for the Leisure. Leisure may be non-zero for 1723 congestion control reasons, in particular for responses to multicast 1724 requests. For these, the server should have a group size estimate G, 1725 a target rate R (which both should be chosen conservatively) and an 1726 estimated response size S; a rough lower bound for Leisure can then 1727 be computed as follows: 1729 lb_Leisure = S * G / R 1731 Figure 18: Computing a lower bound for the Leisure 1733 E.g., for a multicast request with link-local scope on an 2.4 GHz 1734 IEEE 802.15.4 (6LoWPAN) network, G could be (relatively 1735 conservatively) set to 100, S to 100 bytes, and the target rate to 8 1736 kbit/s = 1 kB/s. The resulting lower bound for the Leisure is 10 1737 seconds. 1739 To avoid response implosion, responses to multicast requests SHOULD 1740 be dithered within a Leisure period chosen by the server to fall 1741 between these two bounds. 1743 Currently, we don't foresee a need to signal a value for Leisure from 1744 client to server (beyond the signalling provided by Patience) or from 1745 server to client, but an appropriate Option might be added later. 1747 B.4.3. Pledge 1749 In a basic observation relationship [I-D.ietf-core-observe], the 1750 server makes a pledge to keep the client in the observation 1751 relationship for a resource at least until the max-age for the 1752 resource is reached. 1754 To save the client some effort in re-establishing observation 1755 relationships each time max-age is reached, the server MAY want to 1756 extend its pledge beyond the end of max-age by signalling in a 1757 response/notification an additional time period using the Pledge 1758 Option, in parallel to the Observe Option. 1760 The Pledge Option MUST NOT be used unless the server can make a 1761 reasonable promise not to lose the observation relationship in this 1762 time frame. 1764 Currently, we don't foresee a need to signal a value for Pledge from 1765 client to server, but an appropriate behavior might be added later 1766 for this option when sent in a request. 1768 B.4.4. Option Formats 1770 +-----+----------+----------+-----------------+--------+---------+ 1771 | No. | C/E | Name | Format | Length | Default | 1772 +-----+----------+----------+-----------------+--------+---------+ 1773 | 22 | Elective | Patience | Duration in mis | 1 B | (none) | 1774 | | | | | | | 1775 | 24 | Elective | Pledge | Duration in s | 1 B | 0 | 1776 +-----+----------+----------+-----------------+--------+---------+ 1778 All timing options use the Duration data type (see Appendix D.2), 1779 however Patience (and Leisure, if that ever becomes an option) uses a 1780 timebase of mibiseconds (mis = 1/1024 s) instead of seconds. (This 1781 reduces the range of the Duration from ~ 91 days to 128 minutes.) 1783 Implementation note: As there are no strong accuracy requirements on 1784 the clocks employed, making use of any existing time base of 1785 milliseconds is a valid implementation approach (2.4 % off). 1787 None of the options may be repeated. 1789 Appendix C. The Cemetery (Things we won't do) 1791 This annex documents roads that the WG decided not to take, in order 1792 to spare readers from reinventing them in vain. 1794 C.1. Example envelope option: solving #230 1796 Ticket #230 [CoRE230] points out a design flaw of [RFC7252]: When we 1797 split the elective Location option of draft -01 into multiple 1798 elective options, we made it possible that an implementation might 1799 process some of these and ignore others, leading to an incorrect 1800 interpretation of the Location expressed by the server. 1802 There are several more or less savory solutions to #230. 1804 Each of the elective options that together make up the Location could 1805 be defined in such a way that it makes a requirement on the 1806 processing of the related option (essentially revoking their elective 1807 status once the option under consideration is actually processed). 1808 This falls flat as soon as another option is defined that would also 1809 become part of the Location: existing implementations would not know 1810 that the new option is also part of the cluster that is re- 1811 interpreted as critical. The potential future addition of Location- 1812 Host and Location-Port makes this a valid consideration. 1814 A better solution would be to define an elective Envelope Option 1815 called Location. Within a Location Option, the following top-level 1816 options might be allowed (now or in the future): 1818 o Uri-Host 1820 o Uri-Port 1822 o Uri-Path 1824 o Uri-Query 1826 This would unify the code for interpreting the top-level request 1827 options that indicate the request URI with the code that interprets 1828 the Location URI. 1830 The four options listed are all critical, while the envelope is 1831 elective. This gives exactly the desired semantics: If the envelope 1832 is processed at all (which is elective), the nested options are 1833 critical and all need to be processed. 1835 C.2. Example envelope option: proxy-elective options 1837 Another potential application of envelope options is motivated by the 1838 observation that new critical options might not be implemented by all 1839 proxies on the CoAP path to an origin server. So that this does not 1840 become an obstacle to introducing new critical options that are of 1841 interest only to client and origin server, the client might want to 1842 mark some critical options proxy-elective, i.e. elective for a proxy 1843 but still critical for the origin server. 1845 One way to do this would be an Envelope option, the Proxy-Elective 1846 Option. A client might bundle a number of critical options into a 1847 critical Proxy-Elective Option. A proxy that processes the message 1848 is obliged to process the envelope (or reject the message), where 1849 processing means passing on the nested options towards the origin 1850 server (preferably again within a Proxy-Elective option). It can 1851 pass on the nested options, even ones unknown to the proxy, knowing 1852 that the client is happy with proxies not processing all of them. 1854 (The assumption here is that the Proxy-Elective option becomes part 1855 of the base standard, so all but the most basic proxies would know 1856 how to handle it.) 1858 C.3. Stateful URI compression 1860 Is the approximately 25 % average saving achievable with Huffman- 1861 based URI compression schemes worth the complexity? Probably not, 1862 because much higher average savings can be achieved by introducing 1863 state. 1865 Henning Schulzrinne has proposed for a server to be able to supply a 1866 shortened URI once a resource has been requested using the full- 1867 length URI. Let's call such a shortened referent a _Temporary 1868 Resource Identifier_, _TeRI_ for short. This could be expressed by a 1869 response option as shown in Figure 19. 1871 0 1872 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | duration | TeRI... 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 Figure 19: Option for offering a TeRI in a response 1879 The TeRI offer option indicates that the server promises to offer 1880 this resources under the TeRI given for at least the time given as 1881 the duration. Another TeRI offer can be made later to extend the 1882 duration. 1884 Once a TeRI for a URI is known (and still within its lifetime), the 1885 client can supply a TeRI instead of a URI in its requests. The same 1886 option format as an offer could be used to allow the client to 1887 indicate how long it believes the TeRI will still be valid (so that 1888 the server can decide when to update the lifetime duration). TeRIs 1889 in requests could be distinguished from URIs e.g. by using a 1890 different option number. 1892 Proposal: Add a TeRI option that can be used in CoAP requests and 1893 responses. 1895 Add a way to indicate a TeRI and its duration in a link-value. 1897 Do not add any form of stateless URI encoding. 1899 Benefits: Much higher reduction of message size than any stateless 1900 URI encoding could achieve. 1902 As the use of TeRIs is entirely optional, minimal complexity nodes 1903 can get by without implementing them. 1905 Drawbacks: Adds considerable state and complexity to the protocol. 1907 It turns out that real CoAP URIs are short enough that TeRIs are 1908 not needed. 1910 (Discuss the security implications of TeRIs.) 1912 Appendix D. Experimental Options 1914 This annex documents proposals that need significant additional 1915 discussion before they can become part of (or go back to) the main 1916 CoAP specification. They are not dead, but might die if there turns 1917 out to be no good way to solve the problem. 1919 D.1. Options indicating absolute time 1921 HTTP has a number of headers that may indicate absolute time: 1923 o "Date", defined in Section 14.18 in [RFC2616] (Section 9.3 in 1924 [RFC7230]), giving the absolute time a response was generated; 1926 o "Last-Modified", defined in Section 14.29 in [RFC2616], 1927 (Section 6.6 in [RFC7232], giving the absolute time of when the 1928 origin server believes the resource representation was last 1929 modified; 1931 o "If-Modified-Since", defined in Section 14.25 in [RFC2616], "If- 1932 Unmodified-Since", defined in Section 14.28 in [RFC2616], and "If- 1933 Range", defined in Section 14.27 in [RFC2616] can be used to 1934 supply absolute time to gate a conditional request; 1936 o "Expires", defined in Section 14.21 in [RFC2616] (Section 3.3 in 1937 [RFC7234]), giving the absolute time after which a response is 1938 considered stale. 1940 o The more obscure headers "Retry-After", defined in Section 14.37 1941 in [RFC2616], and "Warning", defined in section 14.46 in 1942 [RFC2616], also may employ absolute time. 1944 [RFC7252] defines a single "Date" option, which however "indicates 1945 the creation time and date of a given resource representation", i.e., 1946 is closer to a "Last-Modified" HTTP header. HTTP's caching rules 1948 [RFC7234] make use of both "Date" and "Last-Modified", combined with 1949 "Expires". The specific semantics required for CoAP needs further 1950 consideration. 1952 In addition to the definition of the semantics, an encoding for 1953 absolute times needs to be specified. 1955 In UNIX-related systems, it is customary to indicate absolute time as 1956 an integer number of seconds, after midnight UTC, January 1, 1970. 1957 Unless negative numbers are employed, this time format cannot 1958 represent time values prior to January 1, 1970, which probably is not 1959 required for the uses ob absolute time in CoAP. 1961 If a 32-bit integer is used and allowance is made for a sign-bit in a 1962 local implementation, the latest UTC time value that can be 1963 represented by the resulting 31 bit integer value is 03:14:07 on 1964 January 19, 2038. If the 32-bit integer is used as an unsigned 1965 value, the last date is 2106-02-07, 06:28:15. 1967 The reach can be extended by: - moving the epoch forward, e.g. by 40 1968 years (= 1262304000 seconds) to 2010-01-01. This makes it impossible 1969 to represent Last-Modified times in that past (such as could be 1970 gatewayed in from HTTP). - extending the number of bits, e.g. by one 1971 more byte, either always or as one of two formats, keeping the 32-bit 1972 variant as well. 1974 Also, the resolution can be extended by expressing time in 1975 milliseconds etc., requiring even more bits (e.g., a 48-bit unsigned 1976 integer of milliseconds would last well after year 9999.) 1978 For experiments, an experimental "Date" option is defined with the 1979 semantics of HTTP's "Last-Modified". It can carry an unsigned 1980 integer of 32, 40, or 48 bits; 32- and 40-bit integers indicate the 1981 absolute time in seconds since 1970-01-01 00:00 UTC, while 48-bit 1982 integers indicate the absolute time in milliseconds since 1970-01-01 1983 00:00 UTC. 1985 However, that option is not really that useful until there is a "If- 1986 Modified-Since" option as well. 1988 (Also: Discuss nodes without clocks.) 1990 D.2. Representing Durations 1992 Various message types used in CoAP need the representation of 1993 *durations*, i.e. of the length of a timespan. In SI units, these 1994 are measured in seconds. CoAP durations represent integer numbers of 1995 seconds, but instead of representing these numbers as integers, a 1996 more compact single-byte pseudo-floating-point (pseudo-FP) 1997 representation is used (Figure 20). 1999 0 1 2 3 4 5 6 7 2000 +---+---+---+---+---+---+---+---+ 2001 | 0... value | 2002 +---+---+---+---+---+---+---+---+ 2004 +---+---+---+---+---+---+---+---+ 2005 | 1... mantissa | exponent | 2006 +---+---+---+---+---+---+---+---+ 2008 Figure 20: Duration in (8,4) pseudo-FP representation 2010 If the high bit is clear, the entire n-bit value (including the high 2011 bit) is the decoded value. If the high bit is set, the mantissa 2012 (including the high bit, with the exponent field cleared out but 2013 still present) is shifted left by the exponent to yield the decoded 2014 value. 2016 The (n,e)-pseudo-FP format can be decoded with a single line of code 2017 (plus a couple of constant definitions), as demonstrated in 2018 Figure 21. 2020 #define N 8 2021 #define E 4 2022 #define HIBIT (1 << (N - 1)) 2023 #define EMASK ((1 << E) - 1) 2024 #define MMASK ((1 << N) - 1 - EMASK) 2026 #define DECODE_8_4(r) (r < HIBIT ? r : (r & MMASK) << (r & EMASK)) 2028 Figure 21: Decoding an (8,4) pseudo-FP value 2030 Note that a pseudo-FP encoder needs to consider rounding; different 2031 applications of durations may favor rounding up or rounding down the 2032 value encoded in the message. 2034 The highest pseudo-FP value, represented by an all-ones byte (0xFF), 2035 is reserved to indicate an indefinite duration. The next lower value 2036 (0xEF) is thus the highest representable value and is decoded as 2037 7340032 seconds, a little more than 12 weeks. 2039 D.3. Rationale 2041 Where CPU power and memory is abundant, a duration can almost always 2042 be adequately represented by a non-negative floating-point number 2043 representing that number of seconds. Historically, many APIs have 2044 also used an integer representation, which limits both the resolution 2045 (e.g., if the integer represents the duration in seconds) and often 2046 the range (integer machine types have range limits that may become 2047 relevant). UNIX's "time_t" (which is used for both absolute time and 2048 durations) originally was a signed 32-bit value of seconds, but was 2049 later complemented by an additional integer to add microsecond 2050 ("struct timeval") and then later nanosecond ("struct timespec") 2051 resolution. 2053 Three decisions need to be made for each application of the concept 2054 of duration: 2056 o the *resolution*. What rounding error is acceptable? 2058 o the *range*. What is the maximum duration that needs to be 2059 represented? 2061 o the *number of bits* that can be expended. 2063 Obviously, these decisions are interrelated. Typically, a large 2064 range needs a large number of bits, unless resolution is traded. For 2065 most applications, the actual requirement for resolution are limited 2066 for longer durations, but can be more acute for shorter durations. 2068 D.4. Pseudo-Floating Point 2070 Constrained systems typically avoid the use of floating-point (FP) 2071 values, as 2073 o simple CPUs often don't have support for floating-point datatypes 2075 o software floating-point libraries are expensive in code size and 2076 slow. 2078 In addition, floating-point datatypes used to be a significant 2079 element of market differentiation in CPU design; it has taken the 2080 industry a long time to agree on a standard floating point 2081 representation. 2083 These issues have led to protocols that try to constrain themselves 2084 to integer representation even where the ability of a floating point 2085 representation to trade range for resolution would be beneficial. 2087 The idea of introducing _pseudo-FP_ is to obtain the increased range 2088 provided by embedding an exponent, without necessarily getting stuck 2089 with hardware datatypes or inefficient software floating-point 2090 libraries. 2092 For the purposes of this draft, we define an (n,e)-pseudo-FP as a 2093 fixed-length value of n bits, e of which may be used for an exponent. 2094 Figure 20 illustrates an (8,4)-pseudo-FP value. 2096 If the high bit is clear, the entire n-bit value (including the high 2097 bit) is the decoded value. If the high bit is set, the mantissa 2098 (including the high bit, but with the exponent field cleared out) is 2099 shifted left by the exponent to yield the decoded value. 2101 The (n,e)-pseudo-FP format can be decoded with a single line of code 2102 (plus a couple of constant definition), as demonstrated in Figure 21. 2104 Only non-negative numbers can be represented by this format. It is 2105 designed to provide full integer resolution for values from 0 to 2106 2^(n-1)-1, i.e., 0 to 127 in the (8,4) case, and a mantissa of n-e 2107 bits from 2^(n-1) to (2^n-2^e)*2^(2^e-1), i.e., 128 to 7864320 in the 2108 (8,4) case. By choosing e carefully, resolution can be traded 2109 against range. 2111 Note that a pseudo-FP encoder needs to consider rounding; different 2112 applications of durations may favor rounding up or rounding down the 2113 value encoded in the message. This requires a little more than a 2114 single line of code (which is left as an exercise to the reader, as 2115 the most efficient expression depends on hardware details). 2117 D.5. A Duration Type for CoAP 2119 CoAP needs durations in a number of places. In [RFC7252], durations 2120 occur in the option "Subscription-lifetime" as well as in the option 2121 "Max-age". (Note that the option "Date" is not a duration, but a 2122 point in time.) Other durations of this kind may be added later. 2124 Most durations relevant to CoAP are best expressed with a minimum 2125 resolution of one second. More detailed resolutions are unlikely to 2126 provide much benefit. 2128 The range of lifetimes and caching ages are probably best kept below 2129 the order of magnitude of months. An (8,4)-pseudo-FP has the maximum 2130 value of 7864320, which is about 91 days; this appears to be adequate 2131 for a subscription lifetime and probably even for a maximum cache 2132 age. Figure 22 shows the values that can be expressed. (If a larger 2133 range for the latter is indeed desired, an (8,5)-pseudo-FP could be 2134 used; this would last 15 milleniums, at the cost of having only 3 2135 bits of accuracy for values larger than 127 seconds.) 2137 Proposal: A single duration type is used throughout CoAP, based on 2138 an (8,4)-pseudo-FP giving a duration in seconds. 2140 Benefits: Implementations can use a single piece of code for 2141 managing all CoAP-related durations. 2143 In addition, length information never needs to be managed for 2144 durations that are embedded in other data structures: All 2145 durations are expressed by a single byte. 2147 It might be worthwhile to reserve one duration value, e.g. 0xFF, for 2148 an indefinite duration. 2150 Duration Seconds Encoded 2151 ----------- ---------- ------- 2152 00:00:00 0x00000000 0x00 2153 00:00:01 0x00000001 0x01 2154 00:00:02 0x00000002 0x02 2155 00:00:03 0x00000003 0x03 2156 00:00:04 0x00000004 0x04 2157 00:00:05 0x00000005 0x05 2158 00:00:06 0x00000006 0x06 2159 00:00:07 0x00000007 0x07 2160 00:00:08 0x00000008 0x08 2161 00:00:09 0x00000009 0x09 2162 00:00:10 0x0000000a 0x0a 2163 00:00:11 0x0000000b 0x0b 2164 00:00:12 0x0000000c 0x0c 2165 00:00:13 0x0000000d 0x0d 2166 00:00:14 0x0000000e 0x0e 2167 00:00:15 0x0000000f 0x0f 2168 00:00:16 0x00000010 0x10 2169 00:00:17 0x00000011 0x11 2170 00:00:18 0x00000012 0x12 2171 00:00:19 0x00000013 0x13 2172 00:00:20 0x00000014 0x14 2173 00:00:21 0x00000015 0x15 2174 00:00:22 0x00000016 0x16 2175 00:00:23 0x00000017 0x17 2176 00:00:24 0x00000018 0x18 2177 00:00:25 0x00000019 0x19 2178 00:00:26 0x0000001a 0x1a 2179 00:00:27 0x0000001b 0x1b 2180 00:00:28 0x0000001c 0x1c 2181 00:00:29 0x0000001d 0x1d 2182 00:00:30 0x0000001e 0x1e 2183 00:00:31 0x0000001f 0x1f 2184 00:00:32 0x00000020 0x20 2185 00:00:33 0x00000021 0x21 2186 00:00:34 0x00000022 0x22 2187 00:00:35 0x00000023 0x23 2188 00:00:36 0x00000024 0x24 2189 00:00:37 0x00000025 0x25 2190 00:00:38 0x00000026 0x26 2191 00:00:39 0x00000027 0x27 2192 00:00:40 0x00000028 0x28 2193 00:00:41 0x00000029 0x29 2194 00:00:42 0x0000002a 0x2a 2195 00:00:43 0x0000002b 0x2b 2196 00:00:44 0x0000002c 0x2c 2197 00:00:45 0x0000002d 0x2d 2198 00:00:46 0x0000002e 0x2e 2199 00:00:47 0x0000002f 0x2f 2200 00:00:48 0x00000030 0x30 2201 00:00:49 0x00000031 0x31 2202 00:00:50 0x00000032 0x32 2203 00:00:51 0x00000033 0x33 2204 00:00:52 0x00000034 0x34 2205 00:00:53 0x00000035 0x35 2206 00:00:54 0x00000036 0x36 2207 00:00:55 0x00000037 0x37 2208 00:00:56 0x00000038 0x38 2209 00:00:57 0x00000039 0x39 2210 00:00:58 0x0000003a 0x3a 2211 00:00:59 0x0000003b 0x3b 2212 00:01:00 0x0000003c 0x3c 2213 00:01:01 0x0000003d 0x3d 2214 00:01:02 0x0000003e 0x3e 2215 00:01:03 0x0000003f 0x3f 2216 00:01:04 0x00000040 0x40 2217 00:01:05 0x00000041 0x41 2218 00:01:06 0x00000042 0x42 2219 00:01:07 0x00000043 0x43 2220 00:01:08 0x00000044 0x44 2221 00:01:09 0x00000045 0x45 2222 00:01:10 0x00000046 0x46 2223 00:01:11 0x00000047 0x47 2224 00:01:12 0x00000048 0x48 2225 00:01:13 0x00000049 0x49 2226 00:01:14 0x0000004a 0x4a 2227 00:01:15 0x0000004b 0x4b 2228 00:01:16 0x0000004c 0x4c 2229 00:01:17 0x0000004d 0x4d 2230 00:01:18 0x0000004e 0x4e 2231 00:01:19 0x0000004f 0x4f 2232 00:01:20 0x00000050 0x50 2233 00:01:21 0x00000051 0x51 2234 00:01:22 0x00000052 0x52 2235 00:01:23 0x00000053 0x53 2236 00:01:24 0x00000054 0x54 2237 00:01:25 0x00000055 0x55 2238 00:01:26 0x00000056 0x56 2239 00:01:27 0x00000057 0x57 2240 00:01:28 0x00000058 0x58 2241 00:01:29 0x00000059 0x59 2242 00:01:30 0x0000005a 0x5a 2243 00:01:31 0x0000005b 0x5b 2244 00:01:32 0x0000005c 0x5c 2245 00:01:33 0x0000005d 0x5d 2246 00:01:34 0x0000005e 0x5e 2247 00:01:35 0x0000005f 0x5f 2248 00:01:36 0x00000060 0x60 2249 00:01:37 0x00000061 0x61 2250 00:01:38 0x00000062 0x62 2251 00:01:39 0x00000063 0x63 2252 00:01:40 0x00000064 0x64 2253 00:01:41 0x00000065 0x65 2254 00:01:42 0x00000066 0x66 2255 00:01:43 0x00000067 0x67 2256 00:01:44 0x00000068 0x68 2257 00:01:45 0x00000069 0x69 2258 00:01:46 0x0000006a 0x6a 2259 00:01:47 0x0000006b 0x6b 2260 00:01:48 0x0000006c 0x6c 2261 00:01:49 0x0000006d 0x6d 2262 00:01:50 0x0000006e 0x6e 2263 00:01:51 0x0000006f 0x6f 2264 00:01:52 0x00000070 0x70 2265 00:01:53 0x00000071 0x71 2266 00:01:54 0x00000072 0x72 2267 00:01:55 0x00000073 0x73 2268 00:01:56 0x00000074 0x74 2269 00:01:57 0x00000075 0x75 2270 00:01:58 0x00000076 0x76 2271 00:01:59 0x00000077 0x77 2272 00:02:00 0x00000078 0x78 2273 00:02:01 0x00000079 0x79 2274 00:02:02 0x0000007a 0x7a 2275 00:02:03 0x0000007b 0x7b 2276 00:02:04 0x0000007c 0x7c 2277 00:02:05 0x0000007d 0x7d 2278 00:02:06 0x0000007e 0x7e 2279 00:02:07 0x0000007f 0x7f 2280 00:02:08 0x00000080 0x80 2281 00:02:24 0x00000090 0x90 2282 00:02:40 0x000000a0 0xa0 2283 00:02:56 0x000000b0 0xb0 2284 00:03:12 0x000000c0 0xc0 2285 00:03:28 0x000000d0 0xd0 2286 00:03:44 0x000000e0 0xe0 2287 00:04:00 0x000000f0 0xf0 2288 00:04:16 0x00000100 0x81 2289 00:04:48 0x00000120 0x91 2290 00:05:20 0x00000140 0xa1 2291 00:05:52 0x00000160 0xb1 2292 00:06:24 0x00000180 0xc1 2293 00:06:56 0x000001a0 0xd1 2294 00:07:28 0x000001c0 0xe1 2295 00:08:00 0x000001e0 0xf1 2296 00:08:32 0x00000200 0x82 2297 00:09:36 0x00000240 0x92 2298 00:10:40 0x00000280 0xa2 2299 00:11:44 0x000002c0 0xb2 2300 00:12:48 0x00000300 0xc2 2301 00:13:52 0x00000340 0xd2 2302 00:14:56 0x00000380 0xe2 2303 00:16:00 0x000003c0 0xf2 2304 00:17:04 0x00000400 0x83 2305 00:19:12 0x00000480 0x93 2306 00:21:20 0x00000500 0xa3 2307 00:23:28 0x00000580 0xb3 2308 00:25:36 0x00000600 0xc3 2309 00:27:44 0x00000680 0xd3 2310 00:29:52 0x00000700 0xe3 2311 00:32:00 0x00000780 0xf3 2312 00:34:08 0x00000800 0x84 2313 00:38:24 0x00000900 0x94 2314 00:42:40 0x00000a00 0xa4 2315 00:46:56 0x00000b00 0xb4 2316 00:51:12 0x00000c00 0xc4 2317 00:55:28 0x00000d00 0xd4 2318 00:59:44 0x00000e00 0xe4 2319 01:04:00 0x00000f00 0xf4 2320 01:08:16 0x00001000 0x85 2321 01:16:48 0x00001200 0x95 2322 01:25:20 0x00001400 0xa5 2323 01:33:52 0x00001600 0xb5 2324 01:42:24 0x00001800 0xc5 2325 01:50:56 0x00001a00 0xd5 2326 01:59:28 0x00001c00 0xe5 2327 02:08:00 0x00001e00 0xf5 2328 02:16:32 0x00002000 0x86 2329 02:33:36 0x00002400 0x96 2330 02:50:40 0x00002800 0xa6 2331 03:07:44 0x00002c00 0xb6 2332 03:24:48 0x00003000 0xc6 2333 03:41:52 0x00003400 0xd6 2334 03:58:56 0x00003800 0xe6 2335 04:16:00 0x00003c00 0xf6 2336 04:33:04 0x00004000 0x87 2337 05:07:12 0x00004800 0x97 2338 05:41:20 0x00005000 0xa7 2339 06:15:28 0x00005800 0xb7 2340 06:49:36 0x00006000 0xc7 2341 07:23:44 0x00006800 0xd7 2342 07:57:52 0x00007000 0xe7 2343 08:32:00 0x00007800 0xf7 2344 09:06:08 0x00008000 0x88 2345 10:14:24 0x00009000 0x98 2346 11:22:40 0x0000a000 0xa8 2347 12:30:56 0x0000b000 0xb8 2348 13:39:12 0x0000c000 0xc8 2349 14:47:28 0x0000d000 0xd8 2350 15:55:44 0x0000e000 0xe8 2351 17:04:00 0x0000f000 0xf8 2352 18:12:16 0x00010000 0x89 2353 20:28:48 0x00012000 0x99 2354 22:45:20 0x00014000 0xa9 2355 1d 01:01:52 0x00016000 0xb9 2356 1d 03:18:24 0x00018000 0xc9 2357 1d 05:34:56 0x0001a000 0xd9 2358 1d 07:51:28 0x0001c000 0xe9 2359 1d 10:08:00 0x0001e000 0xf9 2360 1d 12:24:32 0x00020000 0x8a 2361 1d 16:57:36 0x00024000 0x9a 2362 1d 21:30:40 0x00028000 0xaa 2363 2d 02:03:44 0x0002c000 0xba 2364 2d 06:36:48 0x00030000 0xca 2365 2d 11:09:52 0x00034000 0xda 2366 2d 15:42:56 0x00038000 0xea 2367 2d 20:16:00 0x0003c000 0xfa 2368 3d 00:49:04 0x00040000 0x8b 2369 3d 09:55:12 0x00048000 0x9b 2370 3d 19:01:20 0x00050000 0xab 2371 4d 04:07:28 0x00058000 0xbb 2372 4d 13:13:36 0x00060000 0xcb 2373 4d 22:19:44 0x00068000 0xdb 2374 5d 07:25:52 0x00070000 0xeb 2375 5d 16:32:00 0x00078000 0xfb 2376 6d 01:38:08 0x00080000 0x8c 2377 6d 19:50:24 0x00090000 0x9c 2378 7d 14:02:40 0x000a0000 0xac 2379 8d 08:14:56 0x000b0000 0xbc 2380 9d 02:27:12 0x000c0000 0xcc 2381 9d 20:39:28 0x000d0000 0xdc 2382 10d 14:51:44 0x000e0000 0xec 2383 11d 09:04:00 0x000f0000 0xfc 2384 12d 03:16:16 0x00100000 0x8d 2385 13d 15:40:48 0x00120000 0x9d 2386 15d 04:05:20 0x00140000 0xad 2387 16d 16:29:52 0x00160000 0xbd 2388 18d 04:54:24 0x00180000 0xcd 2389 19d 17:18:56 0x001a0000 0xdd 2390 21d 05:43:28 0x001c0000 0xed 2391 22d 18:08:00 0x001e0000 0xfd 2392 24d 06:32:32 0x00200000 0x8e 2393 27d 07:21:36 0x00240000 0x9e 2394 30d 08:10:40 0x00280000 0xae 2395 33d 08:59:44 0x002c0000 0xbe 2396 36d 09:48:48 0x00300000 0xce 2397 39d 10:37:52 0x00340000 0xde 2398 42d 11:26:56 0x00380000 0xee 2399 45d 12:16:00 0x003c0000 0xfe 2400 48d 13:05:04 0x00400000 0x8f 2401 54d 14:43:12 0x00480000 0x9f 2402 60d 16:21:20 0x00500000 0xaf 2403 66d 17:59:28 0x00580000 0xbf 2404 72d 19:37:36 0x00600000 0xcf 2405 78d 21:15:44 0x00680000 0xdf 2406 84d 22:53:52 0x00700000 0xef 2407 91d 00:32:00 0x00780000 0xff (reserved) 2409 Figure 22 2411 Authors' Addresses 2413 Carsten Bormann 2414 Universitaet Bremen TZI 2415 Postfach 330440 2416 Bremen D-28359 2417 Germany 2419 Phone: +49-421-218-63921 2420 Email: cabo@tzi.org 2421 Klaus Hartke 2422 Universitaet Bremen TZI 2423 Postfach 330440 2424 Bremen D-28359 2425 Germany 2427 Phone: +49-421-218-63905 2428 Email: hartke@tzi.org