idnits 2.17.1 draft-bormann-coap-misc-01.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 25, 2010) is 5047 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-00 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational June 25, 2010 5 Expires: December 27, 2010 7 Miscellaneous additions to CoAP 8 draft-bormann-coap-misc-01 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, CoAP. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on December 27, 2010. 32 Copyright Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. A Compact Accept Option . . . . . . . . . . . . . . . . . . . 4 51 3. Representing Durations . . . . . . . . . . . . . . . . . . . . 5 52 3.1. Pseudo-Floating Point . . . . . . . . . . . . . . . . . . 5 53 3.2. A Duration Type for CoAP . . . . . . . . . . . . . . . . . 7 54 4. URI encoding . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 4.1. An efficient stateless URI encoding . . . . . . . . . . . 8 56 4.2. Stateful URI compression . . . . . . . . . . . . . . . . . 10 57 5. Block-wise transfers . . . . . . . . . . . . . . . . . . . . . 12 58 5.1. The Block Option . . . . . . . . . . . . . . . . . . . . . 12 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 65 1. Introduction 67 The CoRE WG is tasked with standardizing an Application Protocol for 68 Constrained Networks/Nodes, CoAP. This protocol is intended to 69 provide RESTful [REST] services not unlike HTTP [RFC2616], while 70 reducing the complexity of implementation as well as the size of 71 packets exchanged in order to make these services useful in a highly 72 constrained network of themselves highly constrained nodes. 74 This objective requires restraint in a number of sometimes 75 conflicting ways: 77 o reducing implementation complexity in order to minimize code size, 79 o reducing message sizes in order to minimize the number of 80 fragments needed for each message (in turn to maximize the 81 probability of delivery of the message), the amount of 82 transmission power needed and the loading of the limited-bandwidth 83 channel, 85 o reducing requirements on the environment such as stable storage, 86 good sources of randomness or user interaction capabilities. 88 This draft attempts to address a number of problems not yet 89 adequately solved in [I-D.ietf-core-coap]. The solutions proposed to 90 these problems are somewhat interrelated and are therefore presented 91 in one draft. 93 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 94 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 95 and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] 96 and indicate requirement levels for compliant CoAP implementations. 98 2. A Compact Accept Option 100 A resource may be available in a number of representations. Without 101 some information from the client, a server has no easy way to decide 102 which of these would be best served. HTTP has an Accept: request 103 header that a client can use to indicate the media types supported, 104 allowing the server to decide. This header is somewhat unpopular as, 105 for a web browser, there are too many media types to choose from, so 106 -- even with wildcards -- there is no meaningful information to put 107 there. (This has changed a bit for AJAX calls, which may indeed have 108 a specific media type preference.) It is unlikely that machine-to- 109 machine communication would have the same problem. 111 A similar function to the HTTP Accept: header could be added to CoAP 112 as an option in a much simpler way. The CoAP Accept option would 113 simple carry a value that is a sequence of octets, each of which is 114 an acceptable media type for the client, in the order of preference 115 (see Figure 1). If no Accept option is given, the client does not 116 express a preference. 118 0 119 0 1 2 3 4 5 6 7 120 +-+-+-+-+-+-+-+-+ 121 | mediatype | 122 +-+-+-+-+-+-+-+-+ 124 0 1 125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | mediatype1 | mediatype2 | etc. 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Figure 1: Accept option value: A sequence of media types 132 Accept also has to be given an option type code, e.g. 7, in Table 2 133 of [I-D.ietf-core-coap]. 135 The other addition that would be required is an error code that 136 mirrors HTTP's "415 Unsupported Media Type". This is indeed already 137 listed as CoAP Code 35 in Table 3 of [I-D.ietf-core-coap]. 139 3. Representing Durations 141 Various message types used in CoAP need the representation of 142 *durations*, i.e. of the length of a timespan. In SI units, these 143 are measured in seconds. Where CPU power and memory is abundant, a 144 duration can almost always be adequately represented by a non- 145 negative floating-point number representing that number of seconds. 146 Historically, many APIs have also used an integer representation, 147 which limits both the resolution (e.g., if the integer represents the 148 duration in seconds) and often the range (integer machine types have 149 range limits that may become relevant). UNIX's "time_t" (which is 150 used for both absolute time and durations) originally was a signed 151 32-bit value of seconds, but was later complemented by an additional 152 integer to add microsecond ("struct timeval") and then later 153 nanosecond ("struct timespec") resolution. 155 Three decisions need to be made for each application of the concept 156 of duration: 158 o the *resolution*. What rounding error is acceptable? 160 o the *range*. What is the maximum duration that needs to be 161 represented? 163 o the *number of bits* that can be expended. 165 Obviously, these decisions are interrelated. Typically, a large 166 range needs a large number of bits, unless resolution is traded. For 167 most applications, the actual requirement for resolution are limited 168 for longer durations, but can be more acute for shorter durations. 170 3.1. Pseudo-Floating Point 172 Constrained systems typically avoid the use of floating-point (FP) 173 values, as 175 o simple CPUs often don't have support for floating-point datatypes 177 o software floating-point libraries are expensive in code size and 178 slow. 180 In addition, floating-point datatypes used to be a significant 181 element of market differentiation in CPU design; it has taken the 182 industry a long time to agree on a standard floating point 183 representation. 185 These issues have led to protocols that try to constrain themselves 186 to integer representation even where the ability of a floating point 187 representation to trade range for resolution would be beneficial. 189 The idea of introducing _pseudo-FP_ is to obtain the increased range 190 provided by embedding an exponent, without necessarily getting stuck 191 with hardware datatypes or inefficient software floating-point 192 libraries. 194 For the purposes of this draft, we define an (n,e)-pseudo-FP as a 195 fixed-length value of n bits, e of which may be used for an exponent. 196 Figure 2 illustrates an (8,4)-pseudo-FP value. 198 0 1 2 3 4 5 6 7 199 +---+---+---+---+---+---+---+---+ 200 | 0... value | 201 +---+---+---+---+---+---+---+---+ 203 +---+---+---+---+---+---+---+---+ 204 | 1... mantissa | exponent | 205 +---+---+---+---+---+---+---+---+ 207 Figure 2: An (8,4) pseudo-FP representation 209 If the high bit is clear, the entire n-bit value (including the high 210 bit) is the decoded value. If the high bit is set, the mantissa 211 (including the high bit, but with the exponent field cleared out) is 212 shifted left by the exponent to yield the decoded value. 214 The (n,e)-pseudo-FP format can be decoded with a single line of code 215 (plus a couple of constant definition), as demonstrated in Figure 3. 217 #define N 8 218 #define E 4 219 #define HIBIT (1 << (N - 1)) 220 #define EMASK ((1 << E) - 1) 221 #define MMASK ((1 << N) - 1 - EMASK) 223 #define DECODE_8_4(r) (r < HIBIT ? r : (r & MMASK) << (r & EMASK)) 225 Figure 3: Decoding an (8,4) pseudo-FP value 227 Only non-negative numbers can be represented by this format. It is 228 designed to provide full integer resolution for values from 0 to 229 2^(n-1)-1, i.e., 0 to 127 in the (8,4) case, and a mantissa of n-e 230 bits from 2^(n-1) to (2^n-2^e)*2^(2^e-1), i.e., 128 to 7864320 in the 231 (8,4) case. By choosing e carefully, resolution can be traded 232 against range. 234 Note that a pseudo-FP encoder needs to consider rounding; different 235 applications of durations may favor rounding up or rounding down the 236 value encoded in the message. This requires a little more than a 237 single line of code (which is left as an exercise to the reader, as 238 the most efficient expression depends on hardware details). 240 3.2. A Duration Type for CoAP 242 CoAP needs durations in a number of places. In [I-D.ietf-core-coap], 243 durations occur in the option "Subscription-lifetime" as well as in 244 the option "Max-age". (Note that the option "Date" is not a 245 duration, but a point in time.) Other durations of this kind may be 246 added later. 248 Most durations relevant to CoAP are best expressed with a minimum 249 resolution of one second. More detailed resolutions are unlikely to 250 provide much benefit. 252 The range of lifetimes and caching ages are probably best kept below 253 the order of magnitude of months. An (8,4)-pseudo-FP has the maximum 254 value of 7864320, which is about 91 days; this appears to be adequate 255 for a subscription lifetime and probably even for a maximum cache 256 age. (If a larger range for the latter is indeed desired, an (8,5)- 257 pseudo-FP could be used; this would last 15 milleniums, at the cost 258 of having only 3 bits of accuracy for values larger than 127 259 seconds.) 261 Proposal: A single duration type is used throughout CoAP, based on 262 an (8,4)-pseudo-FP giving a duration in seconds. 264 Benefits: Implementations can use a single piece of code for 265 managing all CoAP-related durations. 267 In addition, length information never needs to be managed for 268 durations that are embedded in other data structures: All 269 durations are expressed by a single byte. 271 4. URI encoding 273 In HTTP-based systems, URIs can reach significant lengths. While 274 CoAP-based systems may be able to sidestep the most egregious 275 excesses (mostly by simply applying REST principles), a URI such as 277 /.well-known/resources 279 can use up one third of the available payload in a CoAP message 280 transported in a single 6LoWPAN packet. Is there a way to encode 281 these URIs in a more efficient way? 283 Several proposals have been made on the CoRE mailing list, e.g. 284 applying the principle of base64-encoding [RFC4648] in reverse and 285 using only 6 bits per character. However, due to rounding errors and 286 occasional characters that are not in the 64-character subset chosen 287 to be efficiently encodable, the actual gains are limited. 288 Similarly, using 7 bits per character (assuming URIs contain only 289 ASCII characters) only gives a best-case gain of 12.5 %, and that 290 only in the case the URI is a multiple of 8 characters long. On the 291 other hand, the complexity (and danger of subtle interoperability 292 problems) is not entirely trivial. 294 We will proceed by first proposing an URI encoding that is slightly 295 more efficient than the abovementioned ones, then rejecting even that 296 for its unconvincing cost-benefit ratio, and finally taking up 297 Henning Schulzrinne's proposal to add state. 299 4.1. An efficient stateless URI encoding 301 There is very little redundancy by repetition in a typical URI, 302 rendering popular compression methods such as LZ77 (as implemented in 303 in the widely used DEFLATE algorithm [RFC1951]) rather ineffective. 305 For the short, non-repetitive data structures that URIs tend to be, 306 efficient stateless compression is pretty much confined to Huffman 307 (or, for even more complexity, arithmetic) coding. The complexity 308 can be reduced significantly by moving to n-ary Huffman coding, i.e., 309 optimizing not to the bit level, but to a larger level of 310 granularity. Informal experiments by the author show that a 16ary 311 Huffman coding is close to optimal for reasonable URI lengths. In 312 other words, basing the encoding on nibbles (4-bit half-bytes) is 313 both nearly optimal and relatively inexpensive to implement. 315 The actual letter frequencies that will occur in CoAP URIs are hard 316 to predict. As a stopgap, the author has analyzed an HTTP-based URI 317 corpus and found the following characters to occur with high 318 frequency: 320 %.aeinorst 322 In the encoding proposed, each of these ten highly-compressed 323 characters is represented by a single 4-bit nibble. As the % 324 character is used for hexadecimal encoding in URIs, two additional 325 nibbles are used to provide the numeric value of the two hexadecimal 326 numbers following the % character (the original URI will only be 327 properly reconstituted if these are upper-case as they should be 328 according to section 2.1 of the URI specification [RFC3986]; the 329 encoder can choose to send all three characters in dual-nibble format 330 if that matters). An encoder could also map non-ASCII characters to 331 this three-nibble form, even though they are not allowed in URIs. 332 This gives compatibility with the %-encoding required by [RFC3986]. 334 All other characters are represented by both of their nibbles. The 335 resulting sequence of nibbles is reconstituted into a sequence of 336 bytes in most-significant-nibble-first order. Any unused nibble in 337 the last byte of an encoding is set to 0. (Upon decoding, this 338 padding can be readily distinguished from another % combination as 339 this would require another byte after the last byte.) The encoding 340 is summarized in Figure 4. 342 0 1 343 0 1 2 3 4 5 6 7 8 9 0 1 344 +---+---+---+---+ 345 | 1, 8-F | .aeinorst 346 +---+---+---+---+ 189ABCDEF 348 +---+---+---+---+---+---+---+---+ 349 | 2-7 | 0-F | other ASCII 350 +---+---+---+---+---+---+---+---+ 352 +---+---+---+---+---+---+---+---+---+---+---+---+ 353 | 0 | 0-F | 0-F | %HH 354 +---+---+---+---+---+---+---+---+---+---+---+---+ 356 Figure 4: A nibble-based URI encoding 358 An example encoding for "/.well-known/resources" (where the initial 359 slash is left out, as proposed for abs-path URIs) is given in 360 Figure 5. While the more than 28 % savings in this example may seem 361 just an accident, the HTTP-based corpus indeed shows an average 362 savings of about 21.8 %, i.e. the sum of the lengths of the encoded 363 version of all URIs in the corpus is about 78.2 % of the sum of the 364 length of all URIs. (The savings should be noticeably higher with a 365 more RESTful selection of URIs than was available for this 366 experiment.) 367 0 1 2 368 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 369 / . w e l l - k n o w n / r e s o u r c e s 371 2e 77 65 6c 6c 2d 6b 6e 6f 77 6e 2f 72 65 73 6f 75 72 63 65 73 372 -> 373 1 77 9 6c 6c 2d 6b b c 77 b 2f d 9 e c 75 d 63 9 e 374 = 17 79 6c 6c 2d 6b bc 77 b2 fd 9e c7 5d 63 9e 376 Figure 5: Nibble-based URI encoding: 21 -> 15 bytes 378 4.2. Stateful URI compression 380 Is the approximately 25 % average saving achievable with Huffman- 381 based URI compression schemes worth the complexity? Probably not, 382 because much higher average savings can be achieved by introducing 383 state. 385 Henning Schulzrinne has proposed for a server to be able to supply a 386 shortened URI once a resource has been requested using the full- 387 length URI. Let's call such a shortened referent a _Temporary 388 Resource Identifier_, _TeRI_ for short. This could be expressed by a 389 response option as shown in Figure 6. 391 0 392 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | duration | TeRI... 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 6: Option for offering a TeRI in a response 399 The TeRI offer option indicates that the server promises to offer 400 this resources under the TeRI given for at least the time given as 401 the duration. Another TeRI offer can be made later to extend the 402 duration. 404 Once a TeRI for a URI is known (and still within its lifetime), the 405 client can supply a TeRI instead of a URI in its requests. The same 406 option format as an offer could be used to allow the client to 407 indicate how long it believes the TeRI will still be valid (so that 408 the server can decide when to update the lifetime duration). TeRIs 409 in requests could be distinguished from URIs e.g. by using a 410 different option number. 412 Proposal: Add a TeRI option that can be used in CoAP requests and 413 responses. 415 Add a way to indicate a TeRI and its duration in a link-value. 417 Do not add any form of stateless URI encoding. 419 Benefits: Much higher reduction of message size than any stateless 420 URI encoding could achieve. 422 As the use of TeRIs is entirely optional, minimal complexity nodes 423 can get by without implementing them. 425 5. Block-wise transfers 427 Not all resource representations will fit into a single link layer 428 packet of a constrained network. Using fragmentation (either at the 429 adaptation layer or at the IP layer) to enable the transport of 430 larger representations is possible up to the maximum size of a UDP 431 datagram, but the fragmentation/reassembly process loads the lower 432 layers with conversation state that is better managed in the 433 application layer. 435 This section proposes options to enable _block-wise_ access to 436 resource representations. The overriding objective is to avoid 437 creating conversation state at the server for block-wise GET 438 requests. (It is impossible to fully avoid creating conversation 439 state for POST/PUT, if the creation/replacement of resources is to be 440 atomic; where that property is not needed, there is no need to create 441 server conversation state in this case, either.) Also, 442 implementation of these options is intended to be optional. (The 443 details of which parts of the behavior need to be mandatory to enable 444 that optionality still are TBD, see below.) 446 The size of the blocks should not be fixed by the protocol. On the 447 other hand, implementation should be as simple as possible. We 448 therefore propose a small range of power-of-two block sizes, from 2^4 449 (16) to 2^11 (2048) bytes. One of these eight values can be encoded 450 in three bits (0 for 2^4 to 7 for 2^11 bytes), the "szx" (size 451 exponent); the actual block size is then "1 << (szx + 4)". 453 5.1. The Block Option 455 When a representation is larger than can be comfortably transferred 456 in a single UDP datagram, the Block option can be used to indicate a 457 block-wise transfer. Block is a 1-, 2- or 3-byte integer, the four 458 least significant bits of which indicate the size and whether the 459 current block-wise transfer is the last block being transferred (M or 460 "more" bit). The value divided by sixteen is the number of the block 461 currently being transferred, starting from zero, i.e., the current 462 transfer is about the "size" bytes starting at "blocknr << (szx + 463 4)". The default value of the Block option is zero, indicating that 464 the current block is the first (block number 0) and only (M bit not 465 set) block of the transfer; however, there is no explicit size 466 implied by this default value. 468 0 469 0 1 2 3 4 5 6 7 470 +-+-+-+-+-+-+-+-+ 471 |blocknr|M| szx | 472 +-+-+-+-+-+-+-+-+ 474 0 1 475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | block nr |M| szx | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 0 1 2 481 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | block nr |M| szx | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 7: Block option 488 (Note that the option with the last 4 bits masked out, shifted to the 489 left by the value of szx, gives the byte position of the block. The 490 author is not too sure whether that particularly is a feature.) 492 The block option is used in one of three roles: 494 o In the request for a GET, it gives the block number requested and 495 suggests a block size (block number 0) or echoes the block size of 496 previous blocks received (block numbers other than 0). 498 o In the response for a GET or in the request for a PUT or POST, it 499 describes what block number is contained in the payload, and 500 whether further blocks are part of that body (M bit). If the M 501 bit is set, the size of the payload body in bytes MUST indeed be 502 the power of two given by the block size. All blocks for a 503 transaction MUST use the same block size, except for the last 504 block (M bit not set). 506 o In the response for a PUT or POST, it indicates what block number 507 is being acknowledged. In this case, the M bit is set to indicate 508 that this response does not carry the final response to the 509 request; this can occur when the M bit was set in the request and 510 the server implements PUT/POST atomically (only with the receptin 511 of the last block). 513 In all cases, the block number logically extends the transaction ID, 514 i.e. the same transaction ID can be used for all exchanges for a 515 block-wise transfer. (For GET, and for PUT/POST where atomic 516 semantics are not needed, the requester is free to use different 517 transactions IDs for each block if desired.) 519 When a GET is answered with a response carrying a Block option with 520 the M bit set, the requestor may retrieve additional blocks by 521 sending requests with a Block option giving the block number desired. 522 In such a Block option, the M bit MUST be sent as zero and ignored on 523 reception. 525 To influence the block size used in response to a GET request, the 526 requestor uses the Block option, giving the desired size, a block 527 number of zero and an M bit of zero. A server SHOULD use the block 528 size indicated or a smaller size. Any further block-wise requests 529 for blocks beyond the first one MUST indicate the block size used in 530 the response for the first one. 532 If the Block option is used by the requestor, all GET requests in a 533 single transaction MUST use the same size. The server SHOULD use the 534 block size indicated in the request option, but the requestor MUST 535 take note of the actual block size used in the response; the server 536 MUST ensure that it uses the same block size for all responses in a 537 transaction (except for the last one with the M bit not set). [TBD: 538 decide whether the Block option can only be used in a response if a 539 Block option was in the request. Such a minimal block option could 540 be of length zero, i.e., would occupy just one byte for the type/ 541 length information, but is a bit redundant, so it would be nice to 542 leave this requirement out, but then every GET requestor has the 543 burden of having to cope with receiving Block options.] 545 Block-wise transfers SHOULD be used in conjunction with the Etag 546 option, unless the representation being exchanged is entirely static 547 (not changing over time at all, such as in a schema describing a 548 device). When reassembling the representation from the blocks being 549 exchanged, the reassembler MUST compare Etag options. If the Etag 550 options do not match in a GET transfer, the requestor has the option 551 of attempting to retrieve fresh values for the blocks it retrieved 552 first. To minimize the resulting inefficiency, the server MAY cache 553 the current value of a representation for an ongoing transaction, but 554 there is no requirement for the server to establish any state. The 555 server may offer a TeRI with the initial block to reduce the size of 556 further block-wise GET requests; this TeRI MAY be short-lived and 557 specific to the version of the representation being retrieved (which 558 would in effect freeze the representation of the resource 559 specifically for the purposes of this block-wise transfer). 561 In a PUT or POST transfer, the block option refers to the body in the 562 request, i.e., there is no way to perform a block-wise retrieval of 563 the body of the response. Servers that do need to supply large 564 bodies in response to PUT/POST SHOULD therefore be employing 565 redirects, possibly offering a TeRI. 567 In a PUT or POST transfer that is intended to be implemented in an 568 atomic fashion at the server, the actual creation/replacement takes 569 place at the time a block with the M bit unset is received. If not 570 all previous blocks are available at the server at this time, the 571 transfer fails and error code 4__ (TBD) MUST be returned. The error 572 code 4__ can also be returned at any time by a server that does not 573 currently have the resources to store blocks for a block-wise PUT or 574 POST transfer that it would intend to implement in an atomic fashion. 575 [TBD: a way for a server to derive the equivalent of an Etag for the 576 request body, so that when these do not match in a PUT or POST 577 transfer, the reassembler MUST discard older blocks. For now, the 578 transaction ID will have to suffice.] 580 Proposal: Add a Block option that can be used for block-wise 581 transfers. 583 Benefits: Transfers larger than can be accommodated in constrained- 584 network link-layer packets can be performed in smaller blocks. 586 No hard-to-manage conversation state is created at the adaptation 587 layer or IP layer for fragmentation. 589 The transfer of each block is acknowledged, enabling 590 retransmission if required. 592 Both sides have a say in the block size that actually will be 593 used. 595 6. Security Considerations 597 TBD. (Weigh the security implications of application layer block- 598 wise transfer against those of adaptation-layer or IP-layer 599 fragmentation. Discuss the implications of TeRIs. Also: Discuss 600 nodes without clocks.) 602 7. References 604 7.1. Normative References 606 [I-D.ietf-core-coap] 607 Shelby, Z., Frank, B., and D. Sturek, "Constrained 608 Application Protocol (CoAP)", draft-ietf-core-coap-00 609 (work in progress), June 2010. 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, March 1997. 614 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 615 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 616 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 618 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 619 Resource Identifier (URI): Generic Syntax", STD 66, 620 RFC 3986, January 2005. 622 7.2. Informative References 624 [REST] Fielding, R., "Architectural Styles and the Design of 625 Network-based Software Architectures", 2000. 627 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 628 version 1.3", RFC 1951, May 1996. 630 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 631 Encodings", RFC 4648, October 2006. 633 Author's Address 635 Carsten Bormann 636 Universitaet Bremen TZI 637 Postfach 330440 638 Bremen D-28359 639 Germany 641 Phone: +49-421-218-63921 642 Fax: +49-421-218-7000 643 Email: cabo@tzi.org