draft-ietf-core-block-02.txt   draft-ietf-core-block-03.txt 
CoRE Working Group Z. Shelby, Ed. CoRE Working Group C. Bormann
Internet-Draft Sensinode Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track C. Bormann Intended status: Standards Track Z. Shelby, Ed.
Expires: September 15, 2011 Universitaet Bremen TZI Expires: November 5, 2011 Sensinode
March 14, 2011 May 3, 2011
Blockwise transfers in CoAP Blockwise transfers in CoAP
draft-ietf-core-block-02 draft-ietf-core-block-03
Abstract Abstract
CoAP is a RESTful transfer protocol for constrained nodes and CoAP is a RESTful transfer protocol for constrained nodes and
networks. CoAP is based on datagram transport, which limits the networks. CoAP is based on datagram transport, which limits the
maximum size of resource representations that can be transferred maximum size of resource representations that can be transferred
without too much fragmentation. The Block option provides a minimal without too much fragmentation. The Block options provide a minimal
way to transfer larger representations in a block-wise fashion. way to transfer larger representations in a block-wise fashion.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on November 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Block-wise transfers . . . . . . . . . . . . . . . . . . . . . 5 2. Block-wise transfers . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Block Option . . . . . . . . . . . . . . . . . . . . . 5 2.1. The Block Options . . . . . . . . . . . . . . . . . . . . 5
2.2. Using the Block Option . . . . . . . . . . . . . . . . . . 7 2.2. Using the Block Options . . . . . . . . . . . . . . . . . 7
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. HTTP Mapping Considerations . . . . . . . . . . . . . . . 15 3.1. HTTP Mapping Considerations . . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . . 18 5.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . . 18
5.2. Mitigating Amplification Attacks . . . . . . . . . . . . . 19 5.2. Mitigating Amplification Attacks . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Backwards Compatibility . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The CoRE WG is tasked with standardizing an Application Protocol for The CoRE WG is tasked with standardizing an Application Protocol for
Constrained Networks/Nodes, CoAP. This protocol is intended to Constrained Networks/Nodes, CoAP. This protocol is intended to
provide RESTful [REST] services not unlike HTTP [RFC2616], while provide RESTful [REST] services not unlike HTTP [RFC2616], while
reducing the complexity of implementation as well as the size of reducing the complexity of implementation as well as the size of
packets exchanged in order to make these services useful in a highly packets exchanged in order to make these services useful in a highly
constrained network of themselves highly constrained nodes. constrained network of themselves highly constrained nodes.
skipping to change at page 3, line 41 skipping to change at page 3, line 41
addition, not all resource representations will fit into a single addition, not all resource representations will fit into a single
link layer packet of a constrained network, which may cause link layer packet of a constrained network, which may cause
adaptation layer fragmentation even if IP layer fragmentation is not adaptation layer fragmentation even if IP layer fragmentation is not
required. Using fragmentation (either at the adaptation layer or at required. Using fragmentation (either at the adaptation layer or at
the IP layer) to enable the transport of larger representations is the IP layer) to enable the transport of larger representations is
possible up to the maximum size of the underlying datagram protocol possible up to the maximum size of the underlying datagram protocol
(such as UDP), but the fragmentation/reassembly process loads the (such as UDP), but the fragmentation/reassembly process loads the
lower layers with conversation state that is better managed in the lower layers with conversation state that is better managed in the
application layer. application layer.
This specification defines a CoAP option to enable _block-wise_ This specification defines a pair of CoAP options to enable _block-
access to resource representations. The Block option provides a wise_ access to resource representations. The Block options provide
minimal way to transfer larger resource representations in a block- a minimal way to transfer larger resource representations in a block-
wise fashion. The overriding objective is to avoid creating wise fashion. The overriding objective is to avoid creating
conversation state at the server for block-wise GET requests. (It is conversation state at the server for block-wise GET requests. (It is
impossible to fully avoid creating conversation state for POST/PUT, impossible to fully avoid creating conversation state for POST/PUT,
if the creation/replacement of resources is to be atomic; where that if the creation/replacement of resources is to be atomic; where that
property is not needed, there is no need to create server property is not needed, there is no need to create server
conversation state in this case, either.) conversation state in this case, either.)
In summary, this specification adds a Block option to CoAP that can In summary, this specification adds a pair of Block options to CoAP
be used for block-wise transfers. Benefits of using this option that can be used for block-wise transfers. Benefits of using these
include: options include:
o Transfers larger than can be accommodated in constrained-network o Transfers larger than can be accommodated in constrained-network
link-layer packets can be performed in smaller blocks. link-layer packets can be performed in smaller blocks.
o No hard-to-manage conversation state is created at the adaptation o No hard-to-manage conversation state is created at the adaptation
layer or IP layer for fragmentation. layer or IP layer for fragmentation.
o The transfer of each block is acknowledged, enabling o The transfer of each block is acknowledged, enabling
retransmission if required. retransmission if required.
o Both sides have a say in the block size that actually will be o Both sides have a say in the block size that actually will be
used. used.
o The resulting exchanges are easy to understand using packet o The resulting exchanges are easy to understand using packet
analyzer tools and thus quite accessible to debugging. analyzer tools and thus quite accessible to debugging.
o If needed, the Block option can also be used as is to provide o If needed, the Block options can also be used as is to provide
random access to power-of-two sized blocks within a resource random access to power-of-two sized blocks within a resource
representation. representation.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, BCP 14 document are to be interpreted as described in RFC 2119, BCP 14
[RFC2119] and indicate requirement levels for compliant CoAP [RFC2119] and indicate requirement levels for compliant CoAP
implementations. implementations.
In this document, the term "byte" is used in its now customary sense In this document, the term "byte" is used in its now customary sense
as a synonym for "octet". as a synonym for "octet".
Where bit arithmetic is explained, this document uses the notation Where bit arithmetic is explained, this document uses the notation
familiar from the programming language C, except that the operator familiar from the programming language C, except that the operator
"^" stands for exponentiation. "^" stands for exponentiation.
2. Block-wise transfers 2. Block-wise transfers
2.1. The Block Option 2.1. The Block Options
+------+-----+-------+-----------+--------+---------------+ +------+----------+--------+--------+--------+---------------+
| Type | C/E | Name | Data type | Length | Default | | Type | C/E | Name | Format | Length | Default |
+------+-----+-------+-----------+--------+---------------+ +------+----------+--------+--------+--------+---------------+
| 13 | C | Block | uint | 1-3 B | 0 (see below) | | 19 | Critical | Block1 | uint | 1-3 B | 0 (see below) |
+------+-----+-------+-----------+--------+---------------+ | | | | | | |
| 17 | Critical | Block2 | uint | 1-3 B | 0 (see below) |
+------+----------+--------+--------+--------+---------------+
Implementation of the Block option is intended to be optional. Table 1: Block Option Numbers
The Block1 Option pertains to request payloads, and the Block2 Option
pertains to response payloads. (Note that either option can be used
in both requests and responses, see more below.)
Implementation of either Block option is intended to be optional.
However, when it is present in a CoAP message, it MUST be processed However, when it is present in a CoAP message, it MUST be processed
(or the message rejected); therefore it is identified as a critical (or the message rejected); therefore it is identified as a critical
option. option.
The size of the blocks should not be fixed by the protocol. On the The size of the blocks should not be fixed by the protocol. On the
other hand, implementation should be as simple as possible. The other hand, implementation should be as simple as possible. The
Block option therefore supports a small range of power-of-two block Block options therefore support a small range of power-of-two block
sizes, from 2^4 (16) to 2^11 (2048) bytes. One of these eight values sizes, from 2^4 (16) to 2^10 (1024) bytes. One of these eight values
can be encoded in three bits (0 for 2^4 to 7 for 2^11 bytes), which can be encoded in three bits (0 for 2^4 to 6 for 2^10 bytes), which
we call the "SZX" (size exponent); the actual block size is then "1 we call the "SZX" (size exponent); the actual block size is then "1
<< (SZX + 4)". << (SZX + 4)". (The actual size of the final block in a block-wise
transfer may be less than or equal to the power-of-two block size.)
When a representation is larger than can be comfortably transferred When a resource representation is larger than can be comfortably
in a single UDP datagram, the Block option can be used to indicate a transferred in a single UDP datagram, a Block option can be used to
block-wise transfer. Block is a 1-, 2- or 3-byte integer, the four indicate a block-wise transfer. The value of the option is a 1-, 2-
least significant bits of which indicate the size and whether the or 3-byte integer, the four least significant bits of which indicate
current block-wise transfer is the last block being transferred (M or the size and whether the current block-wise transfer is the last
"more" bit). The option value divided by sixteen is the number of block being transferred (indicated by the M or "more" bit). The
the block currently being transferred, starting from zero, i.e., the option value divided by sixteen (the NUM field) is the number of the
current transfer is about the "size" bytes starting at byte "block block currently being transferred, starting from zero. The current
number << (SZX + 4)". The default value of the Block Option is zero, transfer is therefore about the "size" bytes starting at byte "block
indicating that the current block is the first (block number 0) and number << (SZX + 4)" (although the power-of-two size need not be
only (M bit not set) block of the transfer; however, there is no reached in the final block). The default value of each of the Block
explicit size implied by this default value. options is zero, indicating that the current block is the first
(block number 0) and only (M bit not set) block of the transfer;
however, there is no explicit size implied by this default value.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| NUM |M| SZX | | NUM |M| SZX |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUM |M| SZX | | NUM |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUM |M| SZX | | NUM |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Block option Figure 1: Block option value
(Note that, as an implementation convenience, the option value with (Note that, as an implementation convenience, the option value with
the last 4 bits masked out, shifted to the left by the value of SZX, the last 4 bits masked out, shifted to the left by the value of SZX,
gives the byte position of the block.) gives the byte position of the block.)
NUM: Block Number. The block number is a variable-size (4, 12, or NUM: Block Number. The block number is a variable-size (4, 12, or
20 bit) unsigned integer indicating the block number being 20 bit) unsigned integer indicating the block number being
requested or provided. Block number 0 indicates the first block requested or provided. Block number 0 indicates the first block
of a representation. of a representation.
M: More Flag. This flag, if unset, indicates that this block is the M: More Flag. This flag, if unset, indicates that this block is the
last in a representation. When set it indicates that there are last in a representation. When set it indicates that there are
one or more additional blocks available. When the block option is one or more additional blocks available. When a Block2 Option is
used in a request to retrieve a specific block number, the M bit used in a request to retrieve a specific block number, the M bit
MUST be sent as zero and ignored on reception. MUST be sent as zero and ignored on reception. (In a Block1
Option in a response, the M flag is used to indicate atomicity,
see below.)
SZX: Block Size. The block size is a three-bit unsigned integer SZX: Block Size. The block size is a three-bit unsigned integer
indicating the size of a block to the power of two. Thus block indicating the size of a block to the power of two. Thus block
size = 2^(SZX + 4). As there are three bits available for SZX, size = 2^(SZX + 4). The allowed values of SZX are 0 to 6, i.e.,
the minimum block size is 2^(0+4) = 16 and the maximum is 2^(7+4) the minimum block size is 2^(0+4) = 16 and the maximum is 2^(6+4)
= 2048. = 1024. The value 7 for SZX (which would indicate a block size of
2048) is reserved, i.e. MUST NOT be sent and MUST lead to a 4.00
Bad Request response code upon reception in a request.
The Block option is used in one of three roles: The Block options are used in one of three roles:
o In the request for a GET, the Block option gives the block number o In a request (e.g., GET), the Block2 Option gives the block number
requested and suggests a block size (block number 0) or echoes the requested to be returned in the response and suggests a block size
block size of previous blocks received (block numbers other than (in the case of block number 0) or echoes the block size of
0). previous blocks received (in the case of block numbers other than
0). In thise case, the M bit has no function and MUST be set to
zero.
o In the response for a GET or in the request for a PUT or POST, the o A Block2 Option in a response (e.g., for GET), or a Block1 Option
Block option describes what block number is contained in the in a request (e.g., PUT or POST), describes what block number is
payload, and whether further blocks are required to complete the contained in the payload of this message, and whether further
transfer of that body (M bit). If the M bit is set, the size of blocks are required to complete the transfer of that body (M bit).
the payload body in bytes MUST indeed be the power of two given by If the M bit is set, the size of the payload body in bytes MUST
the block size. With certain exceptions given below, all blocks indeed be the power of two given by the block size. With certain
for a REST transfer MUST use the same block size, except for the exceptions given below, all blocks for a REST transfer MUST use
last block (M bit not set). the same block size, except for the last block (M bit not set).
o In the response for a PUT or POST, the Block option indicates what o In a response, the Block1 Option indicates what block number is
block number is being acknowledged. In this case, if the M bit is being acknowledged (e.g., for a PUT or POST request). In this
set it indicates that this response does not carry the final case, if the M bit is set it indicates that this response does not
response to the request; this can occur when the M bit was set in carry the final response to the request; this can occur when the M
the request and the server implements PUT/POST atomically (i.e., bit was set in the request and the server implements the request
acts only upon reception of the last block). Conversely, if the M atomically (i.e., acts only upon reception of the last block of
bit is unset, it indicates the block-wise request was enacted now, payload). Conversely, if the M bit is unset, it indicates the
and the response carries the final response to this request (and block-wise request was enacted now, and the response carries the
to any previous ones with the M bit set in this sequence of block- final response to this request (and to any previous ones with the
wise transfers). Finally, the block size given in such a Block M bit set in the response's Block1 Option in this sequence of
option indicates the largest block size preferred by the server block-wise transfers). Finally, the block size given in such a
for transfers toward the resource that is the same or smaller than Block1 Option indicates the largest block size preferred by the
the one used in the initial exchange; the client SHOULD use this server for transfers toward the resource that is the same or
block size or a smaller one in all further PUT/POST requests in smaller than the one used in the initial exchange; the client
the transfer sequence. SHOULD use this block size or a smaller one in all further
requests in the transfer sequence.
2.2. Using the Block Option 2.2. Using the Block Options
Using the Block option, a single REST operation can be split into Using one or both Block options, a single REST operation can be split
multiple CoAP message exchanges. Each of these message exchanges into multiple CoAP message exchanges. Each of these message
uses their own CoAP Message ID. exchanges uses their own CoAP Message ID.
When a GET is answered with a response carrying a Block option with When a request is answered with a response carrying a Block2 Option
the M bit set, the requester may retrieve additional blocks of the with the M bit set, the requester may retrieve additional blocks of
resource representation by sending requests with a Block option the resource representation by sending further requests with the same
giving the block number desired. In such a Block option, the M bit options and a Block2 Option giving the block number and block size
MUST be sent as zero and ignored on reception. desired. In a request, the client MUST set the M bit of a Block2
Option to zero and the server MUST ignore it on reception.
To influence the block size used in response to a GET request, the To influence the block size used in a response, the requester also
requester uses the Block option, giving the desired size, a block uses the Block2 Option, giving the desired size, a block number of
number of zero and an M bit of zero. A server SHOULD use the block zero and an M bit of zero. A server MUST use the block size
size indicated or a smaller size. Any further block-wise requests indicated or a smaller size. Any further block-wise requests for
for blocks beyond the first one MUST indicate the same block size blocks beyond the first one MUST indicate the same block size that
that was used by the server in the response for the first request was used by the server in the response for the first request that
that gave a desired size using a Block option. gave a desired size using a Block2 Option.
Once the Block option is used by the requester, all GET requests in a Once the Block2 Option is used by the requester, all requests in a
single transfer MUST ultimately use the same size, except that there single block-wise transfer MUST ultimately use the same size, except
may not be enough content to fill the last block (the one returned that there may not be enough content to fill the last block (the one
with the M bit not set). (Note that the client may start using the returned with the M bit not set). (Note that the client may start
Block option in a second request after a first request without a using the Block2 Option in a second request after a first request
Block option resulted in a Block option in the response.) The server without a Block2 Option resulted in a Block option in the response.)
SHOULD use the block size indicated in the request option or a The server SHOULD use the block size indicated in the request option
smaller size, but the requester MUST take note of the actual block or a smaller size, but the requester MUST take note of the actual
size used in the response it receives to its initial GET and proceed block size used in the response it receives to its initial request
to use it in subsequent GETs; the server behavior MUST ensure that and proceed to use it in subsequent requests. The server behavior
this client behavior results in the same block size for all responses MUST ensure that this client behavior results in the same block size
in a sequence (except for the last one with the M bit not set, and for all responses in a sequence (except for the last one with the M
possibly the first one if the initial request did not contain a Block bit not set, and possibly the first one if the initial request did
option). not contain a Block2 Option).
Block-wise transfers can be used to GET resources the representations Block-wise transfers can be used to GET resources the representations
of which are entirely static (not changing over time at all, such as of which are entirely static (not changing over time at all, such as
in a schema describing a device), or for dynamically changing in a schema describing a device), or for dynamically changing
resources. In the latter case, the Block option SHOULD be used in resources. In the latter case, the Block2 Option SHOULD be used in
conjunction with the ETag option, to ensure that the blocks being conjunction with the ETag Option, to ensure that the blocks being
reassembled are from the same version of the representation. When reassembled are from the same version of the representation: The
reassembling the representation from the blocks being exchanged, the server SHOULD include an ETag option in each response. If an ETag
reassembler MUST compare ETag options. If the ETag options do not option is available, the client's reassembler, when reassembling the
match in a GET transfer, the requester has the option of attempting representation from the blocks being exchanged, MUST compare ETag
to retrieve fresh values for the blocks it retrieved first. To Options. If the ETag Options do not match in a GET transfer, the
minimize the resulting inefficiency, the server MAY cache the current requester has the option of attempting to retrieve fresh values for
value of a representation for an ongoing sequence of requests, but the blocks it retrieved first. To minimize the resulting
there is no requirement for the server to establish any state. The inefficiency, the server MAY cache the current value of a
client MAY facilitate identifying the sequence by using the Token representation for an ongoing sequence of requests, but there is no
option with a non-default value. requirement for the server to establish any state. The client MAY
facilitate identifying the sequence by using the Token Option with a
non-default value.
In a PUT or POST transfer, the Block option refers to the body in the In a request with a request payload (e.g., PUT or POST), the Block1
request, i.e., there is no way to perform a block-wise retrieval of Option refers to the body in the request.
the body of the response. Servers that do need to supply large
bodies in response to PUT/POST SHOULD therefore be employing
mechanisms such as providing a location for a resource that can be
used in a GET to obtain that information.
In a PUT or POST transfer response, the block size given in the Block In response to a request with a payload (e.g., a PUT or POST
option indicates the block size preference of the server for this transfer), the block size given in the Block1 Option indicates the
resource. Obviously, at this point the first block has already been block size preference of the server for this resource. Obviously, at
transferred without benefit of this knowledge. Still, the client this point the first block has already been transferred by the client
SHOULD heed the preference and use the block size preferred by the without benefit of this knowledge. Still, the client SHOULD heed the
server or a smaller one. Note that any reduction in the block size preference and use the block size preferred by the server or a
may mean that the second request starts with a block number larger smaller one. Note that any reduction in the block size may mean that
than one, as the first request already transferred multiple blocks as the second request starts with a block number larger than one, as the
counted in the smaller size. first request already transferred multiple blocks as counted in the
smaller size.
In a PUT or POST transfer that is intended to be implemented in an In a blockwise transfer of a request payload (e.g., a PUT or POST)
atomic fashion at the server, the actual creation/replacement takes that is intended to be implemented in an atomic fashion at the
place at the time the final block, i.e. a block with the M bit unset, server, the actual creation/replacement takes place at the time the
final block, i.e. a block with the M bit unset in the Block1 Option,
is received. If not all previous blocks are available at the server is received. If not all previous blocks are available at the server
at this time, the transfer fails and error code 4.08 (Request Entity at this time, the transfer fails and error code 4.08 (Request Entity
Incomplete) MUST be returned. The error code 4.13 (Request Entity Incomplete) MUST be returned. The error code 4.13 (Request Entity
Too Large) can be returned at any time by a server that does not Too Large) can be returned at any time by a server that does not
currently have the resources to store blocks for a block-wise PUT or currently have the resources to store blocks for a block-wise request
POST transfer that it would intend to implement in an atomic fashion. payload transfer that it would intend to implement in an atomic
fashion.
If multiple concurrently proceeding block-wise PUT or POST operations If multiple concurrently proceeding block-wise request payload
are possible, the requester SHOULD use the Token option to clearly transfer (e.g., PUT or POST) operations are possible, the requester
separate the different sequences. In this case, when reassembling SHOULD use the Token Option to clearly separate the different
the representation from the blocks being exchanged to enable atomic sequences. In this case, when reassembling the representation from
processing, the reassembler MUST compare any Token options present the blocks being exchanged to enable atomic processing, the
(and, as usual, taking an absent Token option to default to the empty reassembler MUST compare any Token Options present (and, as usual,
Token). If atomic processing is not desired, there is no need to taking an absent Token Option to default to the empty Token). If
process the Token option (but it is still returned in the response as atomic processing is not desired, there is no need to process the
usual). Token Option (but it is still returned in the response as usual).
3. Examples 3. Examples
This section gives a number of short examples with message flows for This section gives a number of short examples with message flows for
a block-wise GET, and for a PUT or POST. These examples demonstrate a block-wise GET, and for a PUT or POST. These examples demonstrate
the basic operation, the operation in the presence of the basic operation, the operation in the presence of
retransmissions, and examples for the operation of the block size retransmissions, and examples for the operation of the block size
negotiation. negotiation.
In all these examples, a block option is shown in a decomposed way In all these examples, a Block option is shown in a decomposed way
separating the block number (NUM), more bit (M), and block size separating the kind of Block option (1 or 2), block number (NUM),
exponent (2^(SZX+4)) by slashes. E.g., a block option value of 33 more bit (M), and block size exponent (2^(SZX+4)) by slashes. E.g.,
would be shown as 2/0/32, or a block option value of 59 would be a Block2 Option value of 33 would be shown as 2/2/0/32), or a Block1
shown as 3/1/128. Option value of 59 would be shown as 1/3/1/128.
The first example (Figure 2) shows a GET request that is split into The first example (Figure 2) shows a GET request that is split into
three blocks. The server proposes a block size of 128, and the three blocks. The server proposes a block size of 128, and the
client agrees. The first two ACKs contain 128 bytes of payload each, client agrees. The first two ACKs contain 128 bytes of payload each,
and third ACK contains between 1 and 128 bytes. and third ACK contains between 1 and 128 bytes.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], GET, /status ------> | | CON [MID=1234], GET, /status ------> |
| | | |
| <------ ACK [MID=1234], 2.00 OK, 0/1/128 | | <------ ACK [MID=1234], 2.05 Content, 2/0/1/128 |
| | | |
| CON [MID=1235], GET, /status, 1/0/128 ------> | | CON [MID=1235], GET, /status, 2/1/0/128 ------> |
| | | |
| <------ ACK [MID=1235], 2.00 OK, 1/1/128 | | <------ ACK [MID=1235], 2.05 Content, 2/1/1/128 |
| | | |
| CON [MID=1236], GET, /status, 2/0/128 ------> | | CON [MID=1236], GET, /status, 2/2/0/128 ------> |
| | | |
| <------ ACK [MID=1236], 2.00 OK, 2/0/128 | | <------ ACK [MID=1236], 2.05 Content, 2/2/0/128 |
Figure 2: Simple blockwise GET Figure 2: Simple blockwise GET
In the second example (Figure 3), the client anticipates the In the second example (Figure 3), the client anticipates the
blockwise transfer (e.g., because of a size indication in the link- blockwise transfer (e.g., because of a size indication in the link-
format description) and sends a size proposal. All ACK messages format description) and sends a size proposal. All ACK messages
except for the last carry 64 bytes of payload; the last one carries except for the last carry 64 bytes of payload; the last one carries
between 1 and 64 bytes. between 1 and 64 bytes.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], GET, /status, 0/0/64 ------> | | CON [MID=1234], GET, /status, 2/0/0/64 ------> |
| | | |
| <------ ACK [MID=1234], 2.00 OK, 0/1/64 | | <------ ACK [MID=1234], 2.05 Content, 2/0/1/64 |
| | | |
| CON [MID=1235], GET, /status, 1/0/64 ------> | | CON [MID=1235], GET, /status, 2/1/0/64 ------> |
| | | |
| <------ ACK [MID=1235], 2.00 OK, 1/1/64 | | <------ ACK [MID=1235], 2.05 Content, 2/1/1/64 |
: : : :
: ... : : ... :
: : : :
| CON [MID=1238], GET, /status, 4/0/64 ------> | | CON [MID=1238], GET, /status, 2/4/0/64 ------> |
| | | |
| <------ ACK [MID=1238], 2.00 OK, 4/1/64 | | <------ ACK [MID=1238], 2.05 Content, 2/4/1/64 |
| | | |
| CON [MID=1239], GET, /status, 5/0/64 ------> | | CON [MID=1239], GET, /status, 2/5/0/64 ------> |
| | | |
| <------ ACK [MID=1239], 2.00 OK, 5/0/64 | | <------ ACK [MID=1239], 2.05 Content, 2/5/0/64 |
Figure 3: Blockwise GET with early negotiation Figure 3: Blockwise GET with early negotiation
In the third example (Figure 4), the client is surprised by the need In the third example (Figure 4), the client is surprised by the need
for a blockwise transfer, and unhappy with the size chosen for a blockwise transfer, and unhappy with the size chosen
unilaterally by the server. As it did not send a size proposal unilaterally by the server. As it did not send a size proposal
initially, the negotiation only influences the size from the second initially, the negotiation only influences the size from the second
message exchange. Since the client already obtained both the first message exchange onward. Since the client already obtained both the
and second 64-byte block in the first 128-byte exchange, it goes on first and second 64-byte block in the first 128-byte exchange, it
requesting the third 64-byte block ("2/0/64"). None of this is (or goes on requesting the third 64-byte block ("2/0/64"). None of this
needs to be) understood by the server, which simply responds to the is (or needs to be) understood by the server, which simply responds
requests as it best can. to the requests as it best can.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], GET, /status ------> | | CON [MID=1234], GET, /status ------> |
| | | |
| <------ ACK [MID=1234], 2.00 OK, 0/1/128 | | <------ ACK [MID=1234], 2.05 Content, 2/0/1/128 |
| | | |
| CON [MID=1235], GET, /status, 2/0/64 ------> | | CON [MID=1235], GET, /status, 2/2/0/64 ------> |
| | | |
| <------ ACK [MID=1235], 2.00 OK, 2/1/64 | | <------ ACK [MID=1235], 2.05 Content, 2/2/1/64 |
| | | |
| CON [MID=1236], GET, /status, 3/0/64 ------> | | CON [MID=1236], GET, /status, 2/3/0/64 ------> |
| | | |
| <------ ACK [MID=1236], 2.00 OK, 3/1/64 | | <------ ACK [MID=1236], 2.05 Content, 2/3/1/64 |
| | | |
| CON [MID=1237], GET, /status, 4/0/64 ------> | | CON [MID=1237], GET, /status, 2/4/0/64 ------> |
| | | |
| <------ ACK [MID=1237], 2.00 OK, 4/1/64 | | <------ ACK [MID=1237], 2.05 Content, 2/4/1/64 |
| | | |
| CON [MID=1238], GET, /status, 5/0/64 ------> | | CON [MID=1238], GET, /status, 2/5/0/64 ------> |
| | | |
| <------ ACK [MID=1238], 2.00 OK, 5/0/64 | | <------ ACK [MID=1238], 2.05 Content, 2/5/0/64 |
Figure 4: Blockwise GET with late negotiation Figure 4: Blockwise GET with late negotiation
In all these (and the following) cases, retransmissions are handled In all these (and the following) cases, retransmissions are handled
by the CoAP message exchange layer, so they don't influence the block by the CoAP message exchange layer, so they don't influence the block
operations (Figure 5, Figure 6). operations (Figure 5, Figure 6).
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], GET, /status ------> | | CON [MID=1234], GET, /status ------> |
| | | |
| <------ ACK [MID=1234], 2.00 OK, 0/1/128 | | <------ ACK [MID=1234], 2.05 Content, 2/0/1/128 |
| | | |
| CON [MID=1235], GE///////////////////////// | | CON [MID=1235], GE///////////////////////// |
| | | |
| (timeout) | | (timeout) |
| | | |
| CON [MID=1235], GET, /status, 2/0/64 ------> | | CON [MID=1235], GET, /status, 2/2/0/64 ------> |
| | | |
| <------ ACK [MID=1235], 2.00 OK, 2/1/64 | | <------ ACK [MID=1235], 2.05 Content, 2/2/1/64 |
: : : :
: ... : : ... :
: : : :
| CON [MID=1238], GET, /status, 5/0/64 ------> | | CON [MID=1238], GET, /status, 2/5/0/64 ------> |
| | | |
| <------ ACK [MID=1238], 2.00 OK, 5/0/64 | | <------ ACK [MID=1238], 2.05 Content, 2/5/0/64 |
Figure 5: Blockwise GET with late negotiation and lost CON Figure 5: Blockwise GET with late negotiation and lost CON
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], GET, /status ------> | | CON [MID=1234], GET, /status ------> |
| | | |
| <------ ACK [MID=1234], 2.00 OK, 0/1/128 | | <------ ACK [MID=1234], 2.05 Content, 2/0/1/128 |
| | | |
| CON [MID=1235], GET, /status, 2/0/64 ------> | | CON [MID=1235], GET, /status, 2/2/0/64 ------> |
| | | |
| /////////////////////////////////OK, 2/1/64 | | //////////////////////////////////tent, 2/2/1/64 |
| | | |
| (timeout) | | (timeout) |
| | | |
| CON [MID=1235], GET, /status, 2/0/64 ------> | | CON [MID=1235], GET, /status, 2/2/0/64 ------> |
| | | |
| <------ ACK [MID=1235], 2.00 OK, 2/1/64 | | <------ ACK [MID=1235], 2.05 Content, 2/2/1/64 |
: : : :
: ... : : ... :
: : : :
| CON [MID=1238], GET, /status, 5/0/64 ------> | | CON [MID=1238], GET, /status, 2/5/0/64 ------> |
| | | |
| <------ ACK [MID=1238], 2.00 OK, 5/0/64 | | <------ ACK [MID=1238], 2.05 Content, 2/5/0/64 |
Figure 6: Blockwise GET with late negotiation and lost ACK Figure 6: Blockwise GET with late negotiation and lost ACK
The following examples demonstrate a PUT exchange; a POST exchange The following examples demonstrate a PUT exchange; a POST exchange
looks the same, with different requirements on atomicity/idempotence. looks the same, with different requirements on atomicity/idempotence.
To ensure that the blocks relate to the same version of the resource To ensure that the blocks relate to the same version of the resource
representation carried in the request, the client in Figure 7 sets representation carried in the request, the client in Figure 7 sets
the Token to "v17" in all requests. Note that, as with the GET, the the Token to "v17" in all requests. Note that, as with the GET, the
responses to the requests that have a more bit in the request block responses to the requests that have a more bit in the request Block2
option are provisional; only the final response tells the client that Option are provisional; only the final response tells the client that
the PUT succeeded. the PUT succeeded.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], PUT, /options, v17, 0/1/128 ------> | | CON [MID=1234], PUT, /options, v17, 1/0/1/128 ------> |
| | | |
| <------ ACK [MID=1234], 2.04 Changed, 0/1/128 | | <------ ACK [MID=1234], 2.04 Changed, 1/0/1/128 |
| | | |
| CON [MID=1235], PUT, /options, v17, 1/1/128 ------> | | CON [MID=1235], PUT, /options, v17, 1/1/1/128 ------> |
| | | |
| <------ ACK [MID=1235], 2.04 Changed, 1/1/128 | | <------ ACK [MID=1235], 2.04 Changed, 1/1/1/128 |
| | | |
| CON [MID=1236], PUT, /options, v17, 2/0/128 ------> | | CON [MID=1236], PUT, /options, v17, 1/2/0/128 ------> |
| | | |
| <------ ACK [MID=1236], 2.04 Changed, 2/0/128 | | <------ ACK [MID=1236], 2.04 Changed, 1/2/0/128 |
Figure 7: Simple atomic blockwise PUT Figure 7: Simple atomic blockwise PUT
A stateless server that simply builds/updates the resource in place A stateless server that simply builds/updates the resource in place
(statelessly) may indicate this by not setting the more bit in the (statelessly) may indicate this by not setting the more bit in the
response (Figure 8); in this case, the response codes are valid response (Figure 8); in this case, the response codes are valid
separately for each block being updated. This is of course only an separately for each block being updated. This is of course only an
acceptable behavior of the server if the potential inconsistency acceptable behavior of the server if the potential inconsistency
present during the run of the message exchange sequence does not lead present during the run of the message exchange sequence does not lead
to problems, e.g. because the resource being created or changed is to problems, e.g. because the resource being created or changed is
not yet or not currently in use. not yet or not currently in use.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], PUT, /options, v17, 0/1/128 ------> | | CON [MID=1234], PUT, /options, v17, 1/0/1/128 ------> |
| | | |
| <------ ACK [MID=1234], 2.04 Changed, 0/0/128 | | <------ ACK [MID=1234], 2.04 Changed, 1/0/0/128 |
| | | |
| CON [MID=1235], PUT, /options, v17, 1/1/128 ------> | | CON [MID=1235], PUT, /options, v17, 1/1/1/128 ------> |
| | | |
| <------ ACK [MID=1235], 2.04 Changed, 1/0/128 | | <------ ACK [MID=1235], 2.04 Changed, 1/1/0/128 |
| | | |
| CON [MID=1236], PUT, /options, v17, 2/0/128 ------> | | CON [MID=1236], PUT, /options, v17, 1/2/0/128 ------> |
| | | |
| <------ ACK [MID=1236], 2.04 Changed, 2/0/128 | | <------ ACK [MID=1236], 2.04 Changed, 1/2/0/128 |
Figure 8: Simple stateless blockwise PUT Figure 8: Simple stateless blockwise PUT
Finally, a server receiving a blockwise PUT or POST may want to Finally, a server receiving a blockwise PUT or POST may want to
indicate a smaller block size preference (Figure 9). In this case, indicate a smaller block size preference (Figure 9). In this case,
the client SHOULD continue with a smaller block size; if it does, it the client SHOULD continue with a smaller block size; if it does, it
MUST adjust the block number to properly count in that smaller size. MUST adjust the block number to properly count in that smaller size.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], PUT, /options, v17, 0/1/128 ------> | | CON [MID=1234], PUT, /options, v17, 1/0/1/128 ------> |
| | | |
| <------ ACK [MID=1234], 2.04 Changed, 0/1/32 | | <------ ACK [MID=1234], 2.04 Changed, 1/0/1/32 |
| | | |
| CON [MID=1235], PUT, /options, v17, 4/1/32 ------> | | CON [MID=1235], PUT, /options, v17, 1/4/1/32 ------> |
| | | |
| <------ ACK [MID=1235], 2.04 Changed, 4/1/32 | | <------ ACK [MID=1235], 2.04 Changed, 1/4/1/32 |
| | | |
| CON [MID=1236], PUT, /options, v17, 5/1/32 ------> | | CON [MID=1236], PUT, /options, v17, 1/5/1/32 ------> |
| | | |
| <------ ACK [MID=1235], 2.04 Changed, 5/1/32 | | <------ ACK [MID=1235], 2.04 Changed, 1/5/1/32 |
| | | |
| CON [MID=1237], PUT, /options, v17, 6/0/32 ------> | | CON [MID=1237], PUT, /options, v17, 1/6/0/32 ------> |
| | | |
| <------ ACK [MID=1236], 2.04 Changed, 6/0/32 | | <------ ACK [MID=1236], 2.04 Changed, 1/6/0/32 |
Figure 9: Simple atomic blockwise PUT with negotiation Figure 9: Simple atomic blockwise PUT with negotiation
3.1. HTTP Mapping Considerations 3.1. HTTP Mapping Considerations
In this subsection, we give some brief examples for the influence the In this subsection, we give some brief examples for the influence the
Block Option might have on intermediaries that map between CoAP and Block options might have on intermediaries that map between CoAP and
HTTP. HTTP.
For mapping CoAP requests to HTTP, the intermediary may want to map For mapping CoAP requests to HTTP, the intermediary may want to map
the block-wise transfer into a single HTTP transfer. E.g., for a GET the block-wise transfer into a single HTTP transfer. E.g., for a GET
request, the intermediary could perform the HTTP request once the request, the intermediary could perform the HTTP request once the
first block has been requested and could then fulfill all further first block has been requested and could then fulfill all further
block requests out of its cache. A constrained implementation may block requests out of its cache. A constrained implementation may
not be able to cache the entire object and may use a combination of not be able to cache the entire object and may use a combination of
TCP flow control and (in particular if timeouts occur) HTTP range TCP flow control and (in particular if timeouts occur) HTTP range
requests to obtain the information necessary for the next block requests to obtain the information necessary for the next block
skipping to change at page 17, line 5 skipping to change at page 16, line 14
For mapping HTTP to CoAP, the intermediary may want to map a single For mapping HTTP to CoAP, the intermediary may want to map a single
HTTP transfer into a block-wise transfer. If the HTTP client is too HTTP transfer into a block-wise transfer. If the HTTP client is too
slow delivering a request body on a PUT or POST, the CoAP server slow delivering a request body on a PUT or POST, the CoAP server
might time out and return a 4.08 response code, which in turn maps might time out and return a 4.08 response code, which in turn maps
well to an HTTP 408 status code (again, 4.13 maps to 413). HTTP well to an HTTP 408 status code (again, 4.13 maps to 413). HTTP
range requests received on the HTTP side may be served out of a cache range requests received on the HTTP side may be served out of a cache
and/or mapped to GET requests that request a sequence of blocks and/or mapped to GET requests that request a sequence of blocks
overlapping the range. overlapping the range.
(Note that, while the semantics of CoAP 4.08 and HTTP 408 differ,
this difference is largely due to the different way the two protocols
are mapped to transport. HTTP has an underlying TCP connection,
which supplies connection state, so a HTTP 408 status code can
immediately be used to indicate that a timeout occurred during
transmitting a request through that active TCP connection. The CoAP
4.08 response code indicates one or more missing blocks, which may be
due to timeouts or resource constraints; as there is no connection
state, there is no way to deliver such a response immediately;
instead, it is delivered on the next block transfer. Still, HTTP 408
is probably the best mapping back to HTTP, as the timeout is the most
likely cause for a CoAP 4.08. Note that there is no way to
distinguish a timeout from a missing block for a server without
creating additional state, the need for which we want to avoid.)
4. IANA Considerations 4. IANA Considerations
This draft adds the following option number to the CoAP Option This draft adds the following option number to the CoAP Option
Numbers registry of [I-D.ietf-core-coap]: Numbers registry of [I-D.ietf-core-coap]:
+--------+-------+-----------+ +--------+--------+-----------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+-------+-----------+ +--------+--------+-----------+
| 13 | Block | [RFCXXXX] | | 17 | Block2 | [RFCXXXX] |
+--------+-------+-----------+ | | | |
| 19 | Block1 | [RFCXXXX] |
+--------+--------+-----------+
Table 1: CoAP Option Numbers Table 2: CoAP Option Numbers
This draft adds the following response code to the CoAP Response This draft adds the following response code to the CoAP Response
Codes registry of [I-D.ietf-core-coap]: Codes registry of [I-D.ietf-core-coap]:
+------+--------------------------------+-----------+ +------+--------------------------------+-----------+
| Code | Description | Reference | | Code | Description | Reference |
+------+--------------------------------+-----------+ +------+--------------------------------+-----------+
| 136 | 4.08 Request Entity Incomplete | [RFCXXXX] | | 136 | 4.08 Request Entity Incomplete | [RFCXXXX] |
+------+--------------------------------+-----------+ +------+--------------------------------+-----------+
Table 2: CoAP Response Codes Table 3: CoAP Response Codes
5. Security Considerations 5. Security Considerations
Providing access to blocks within a resource may lead to surprising Providing access to blocks within a resource may lead to surprising
vulnerabilities. Where requests are not implemented atomically, an vulnerabilities. Where requests are not implemented atomically, an
attacker may be able to exploit a race condition or confuse a server attacker may be able to exploit a race condition or confuse a server
by inducing it to use a partially updated resource representation. by inducing it to use a partially updated resource representation.
Partial transfers may also make certain problematic data invisible to Partial transfers may also make certain problematic data invisible to
intrusion detection systems; it is RECOMMENDED that an intrusion intrusion detection systems; it is RECOMMENDED that an intrusion
detection system (IDS) that analyzes resource representations detection system (IDS) that analyzes resource representations
transferred by CoAP implement the Block option to gain access to transferred by CoAP implement the Block options to gain access to
entire resource representations. Still, approaches such as entire resource representations. Still, approaches such as
transferring even-numbered blocks on one path and odd-numbered blocks transferring even-numbered blocks on one path and odd-numbered blocks
on another path, or even transferring blocks multiple times with on another path, or even transferring blocks multiple times with
different content and obtaining a different interpretation of different content and obtaining a different interpretation of
temporal order at the IDS than at the server, may prevent an IDS from temporal order at the IDS than at the server, may prevent an IDS from
seeing the whole picture. These kinds of attacks are well understood seeing the whole picture. These kinds of attacks are well understood
from IP fragmentation and TCP segmentation; CoAP does not add from IP fragmentation and TCP segmentation; CoAP does not add
fundamentally new considerations. fundamentally new considerations.
Where access to a resource is only granted to clients making use of a Where access to a resource is only granted to clients making use of a
skipping to change at page 21, line 5 skipping to change at page 20, line 11
a 10-byte request might result in an 80-byte response (with a 64-byte a 10-byte request might result in an 80-byte response (with a 64-byte
block) instead of a 1016-byte response, considerably reducing the block) instead of a 1016-byte response, considerably reducing the
amplification provided. amplification provided.
6. Acknowledgements 6. Acknowledgements
Much of the content of this draft is the result of discussions with Much of the content of this draft is the result of discussions with
the [I-D.ietf-core-coap] authors, and via many CoRE WG discussions. the [I-D.ietf-core-coap] authors, and via many CoRE WG discussions.
Tokens were suggested by Gilman Tolle and refined by Klaus Hartke. Tokens were suggested by Gilman Tolle and refined by Klaus Hartke.
Charles Palmer provided extensive editorial comments to a previous
version of this draft, some of which the authors hope to have covered
in this version.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank, Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", "Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-05 (work in progress), March 2011. draft-ietf-core-coap-05 (work in progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 22, line 5 skipping to change at page 22, line 5
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
7.2. Informative References 7.2. Informative References
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000. Network-based Software Architectures", 2000.
Authors' Addresses Appendix A. Backwards Compatibility
Zach Shelby (editor) (This section to be removed by RFC editor or on July 1st, 2011.)
Sensinode
Kidekuja 2
Vuokatti 88600
Finland
Phone: +358407796297 An earlier version of this draft used a single option:
Email: zach@sensinode.com
+------+----------+-------+--------+--------+---------------+
| Type | C/E | Name | Format | Length | Default |
+------+----------+-------+--------+--------+---------------+
| 13 | Critical | Block | uint | 1-3 B | 0 (see below) |
+------+----------+-------+--------+--------+---------------+
This option was interpreted as either Block1 or Block2 depending on
context:
o In the request for a GET, the original Block Option was
interpreted as a Block2 Option, i.e. to give the block number
requested and suggest a block size (block number 0) or echo the
block size of previous blocks received (block numbers other than
0).
o In the response for a GET, the original Block Option was
interpreted as a Block2 Option, i.e. to describes what block
number is contained in the response payload, and whether further
blocks are required to complete the transfer of that body (M bit).
o In the request for a PUT or POST, the original Block Option was
interpreted as a Block1 Option, i.e. to describes what block
number is contained in the request payload, and whether further
blocks are required to complete the transfer of that body (M bit).
o In the response for a PUT or POST, the original Block Option was
interpreted as a Block1 Option, i.e. to indicate what block number
is being acknowledged and to indicate whether the response is
final (M bit).
In summary, the semantics was dependent on the method code in a
request, and on the method code of the corresponding request in a
response. This lack of a direction indication also made it
impossible to transfer large PUT/POST responses in a block-wise
manner, because the original Block Option was already "spent" for
block-wise transfer of the request payload.
For interoperability with implementations of the previous draft-
block, implementations may honor original Block Options (option
number 13) until July 1st, 2011, at which time the option number 13
will be available for reallocation.
Authors' Addresses
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Fax: +49-421-218-7000 Fax: +49-421-218-7000
Email: cabo@tzi.org Email: cabo@tzi.org
Zach Shelby (editor)
Sensinode
Kidekuja 2
Vuokatti 88600
Finland
Phone: +358407796297
Email: zach@sensinode.com
 End of changes. 98 change blocks. 
236 lines changed or deleted 317 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/