< draft-ietf-core-new-block-10.txt   draft-ietf-core-new-block-11.txt >
CoRE Working Group M. Boucadair CoRE Working Group M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track J. Shallow Intended status: Standards Track J. Shallow
Expires: October 16, 2021 April 14, 2021 Expires: October 30, 2021 April 28, 2021
Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Constrained Application Protocol (CoAP) Block-Wise Transfer Options for
Faster Transmission Faster Transmission
draft-ietf-core-new-block-10 draft-ietf-core-new-block-11
Abstract Abstract
This document specifies alternative Constrained Application Protocol This document specifies alternative Constrained Application Protocol
(CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.
These options are similar to the CoAP Block1 and Block2 Options These options are similar to the CoAP Block1 and Block2 Options
defined in RFC 7959, not a replacement for them, but do enable faster defined in RFC 7959, not a replacement for them, but do enable faster
transmission rates for large amounts of data with less packet transmission rates for large amounts of data with less packet
interchanges. Also, Q-Block1 and Q-Block2 Options support faster interchanges. Also, Q-Block1 and Q-Block2 Options support faster
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 October 16, 2021. This Internet-Draft will expire on October 30, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 16 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 16
4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 16 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 16
4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 16 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 16
4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16
5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16
6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 18 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 18
7. Congestion Control for Unreliable Transports . . . . . . . . 18 7. Congestion Control for Unreliable Transports . . . . . . . . 18
7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18
7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 19 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 19
8. Caching Considerations . . . . . . . . . . . . . . . . . . . 22 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 22
9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 23 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 24
10. Examples with Non-confirmable Messages . . . . . . . . . . . 23 10. Examples with Non-confirmable Messages . . . . . . . . . . . 24
10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 24 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 24
10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 24 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 24
10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 24 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 25
10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 25 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 25
10.1.4. Handling Recovery with Failure . . . . . . . . . . . 26 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 27
10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 27 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 27
10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 27 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 28
10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 28 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 28
10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 29 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 29
10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 30 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 30
10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 31 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 31
10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 31 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 31
10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 32 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 32
10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 33 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 33
11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 11. Security Considerations . . . . . . . . . . . . . . . . . . . 35
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 36 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 36
skipping to change at page 8, line 16 skipping to change at page 8, line 16
response (i.e., in that message to the payload of which it pertains), response (i.e., in that message to the payload of which it pertains),
it indicates a block-wise transfer and describes how this specific it indicates a block-wise transfer and describes how this specific
block-wise payload forms part of the entire body being transferred. block-wise payload forms part of the entire body being transferred.
If it is present in the opposite direction, it provides additional If it is present in the opposite direction, it provides additional
control on how that payload will be formed or was processed. control on how that payload will be formed or was processed.
To indicate support for Q-Block2 responses, the CoAP client MUST To indicate support for Q-Block2 responses, the CoAP client MUST
include the Q-Block2 Option in a GET or similar request (FETCH, for include the Q-Block2 Option in a GET or similar request (FETCH, for
example), the Q-Block2 Option in a PUT or similar request, or the example), the Q-Block2 Option in a PUT or similar request, or the
Q-Block1 Option in a PUT or similar request so that the server knows Q-Block1 Option in a PUT or similar request so that the server knows
that the client supports this Q-Block2 functionality should it need that the client supports this Q-Block functionality should it need to
to send back a body that spans multiple payloads. Otherwise, the send back a body that spans multiple payloads. Otherwise, the server
server would use the Block2 Option (if supported) to send back a would use the Block2 Option (if supported) to send back a message
message body that is too large to fit into a single IP packet body that is too large to fit into a single IP packet [RFC7959].
[RFC7959].
How a client decides whether it needs to include a Q-Block1 or How a client decides whether it needs to include a Q-Block1 or
Q-Block2 Option can be driven by a local configuration knob, Q-Block2 Option can be driven by a local configuration knob,
triggered by an application (DOTS, for example), etc. Such triggered by an application (DOTS, for example), etc. Such
considerations are out of the scope of the document. considerations are out of the scope of the document.
Implementation of the Q-Block1 and Q-Block2 Options is intended to be Implementation of the Q-Block1 and Q-Block2 Options is intended to be
optional. However, when it is present in a CoAP message, it MUST be optional. However, when it is present in a CoAP message, it MUST be
processed (or the message rejected). Therefore, Q-Block1 and processed (or the message rejected). Therefore, Q-Block1 and
Q-Block2 Options are identified as Critical options. Q-Block2 Options are identified as Critical options.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
starting from zero, until the body is complete (subject to any starting from zero, until the body is complete (subject to any
congestion control (Section 7)). Any missing payloads requested by congestion control (Section 7)). Any missing payloads requested by
the server must in addition be separately transmitted with increasing the server must in addition be separately transmitted with increasing
block numbers. block numbers.
The following Response Codes are used: The following Response Codes are used:
2.01 (Created) 2.01 (Created)
This Response Code indicates successful receipt of the entire body This Response Code indicates successful receipt of the entire body
and that the resource was created. The token used MUST be any and that the resource was created. The token used MUST be one of
token that was received in a request using the same Request-Tag. the tokens that were received in a request for this block-wise
However, it is desirable to provide the one used in the last exchange. However, it is desirable to provide the one used in the
received request, since that will aid any troubleshooting. The last received request, since that will aid any troubleshooting.
client should then release all of the tokens used for this body. The client should then release all of the tokens used for this
Note that the last received payload may not be the one with the body. Note that the last received payload may not be the one with
highest block number. the highest block number.
2.02 (Deleted) 2.02 (Deleted)
This Response Code indicates successful receipt of the entire body This Response Code indicates successful receipt of the entire body
and that the resource was deleted when using POST (Section 5.8.2 and that the resource was deleted when using POST (Section 5.8.2
[RFC7252]). The token used MUST be any token that was received in [RFC7252]). The token used MUST be one of the tokens that were
a request using the same Request-Tag. However, it is desirable to received in a request for this block-wise exchange. However, it
provide the one used in the last received request. The client is desirable to provide the one used in the last received request.
should then release all of the tokens used for this body. The client should then release all of the tokens used for this
body.
2.04 (Changed) 2.04 (Changed)
This Response Code indicates successful receipt of the entire body This Response Code indicates successful receipt of the entire body
and that the resource was updated. The token used MUST be any and that the resource was updated. The token used MUST be one of
token that was received in a request using the same Request-Tag. the tokens that were received in a request for this block-wise
However, it is desirable to provide the one used in the last exchange. However, it is desirable to provide the one used in the
received request. The client should then release all of the last received request. The client should then release all of the
tokens used for this body. tokens used for this body.
2.05 (Content) 2.05 (Content)
This Response Code indicates successful receipt of the entire This Response Code indicates successful receipt of the entire
FETCH request body (Section 2 of [RFC8132]) and that the FETCH request body (Section 2 of [RFC8132]) and that the
appropriate representation of the resource is being returned. The appropriate representation of the resource is being returned. The
token used MUST be any token that was received in a request using token used MUST be one of the tokens that were received in a
the same Request-Tag. However, it is desirable to provide the one request for this block-wise exchange. However, it is desirable to
used in the last received request. provide the one used in the last received request.
If the FETCH request includes the Observe Option, then the server If the FETCH request includes the Observe Option, then the server
MUST use the same token as used for the initial response for MUST use the same token as used for the initial response for
returning any Observe triggered responses so that the client can returning any Observe triggered responses so that the client can
match them up. match them up.
The client should then release all of the tokens used for this The client should then release all of the tokens used for this
body unless a resource is being observed. body unless a resource is being observed.
2.31 (Continue) 2.31 (Continue)
This Response Code can be used to indicate that all of the blocks This Response Code can be used to indicate that all of the blocks
up to and including the Q-Block1 Option block NUM (all having the up to and including the Q-Block1 Option block NUM (all having the
M bit set) have been successfully received. The token used MUST M bit set) have been successfully received. The token used MUST
be any token that was received in a request using the same be one of the tokens that were received in a request for this
Request-Tag. However, it is desirable to provide the one used in block-wise exchange. However, it is desirable to provide the one
the last received request. used in the last received request.
A response using this Response Code SHOULD NOT be generated for A response using this Response Code SHOULD NOT be generated for
every received Q-Block1 Option request (Section 7.2). It SHOULD every received Q-Block1 Option request (Section 7.2). It SHOULD
only be generated when all the payload requests are Non- only be generated when all the payload requests are Non-
confirmable and a set of MAX_PAYLOADS payloads have been received confirmable and a set of MAX_PAYLOADS payloads have been received
by the server. More details about the motivations for this by the server. More details about the motivations for this
optimization are discussed in Section 7.2. optimization are discussed in Section 7.2.
It SHOULD NOT be generated for CON. This Response Code SHOULD NOT be generated for CON.
4.00 (Bad Request) 4.00 (Bad Request)
This Response Code MUST be returned if the request does not This Response Code MUST be returned if the request does not
include neither a Request-Tag Option nor a Size1 Option but does include a Request-Tag Option or a Size1 Option but does include a
include a Q-Block1 option. Q-Block1 option.
4.02 (Bad Option) 4.02 (Bad Option)
Either this Response Code (in case of Confirmable request) or a This Response Code MUST be returned for a Confirmable request if
reset message (in case of Non-confirmable request) MUST be the server does not support the Q-Block Options. Note that a
returned if the server does not support the Q-Block Options. reset message must be sent in case of Non-confirmable request.
4.08 (Request Entity Incomplete) 4.08 (Request Entity Incomplete)
As a reminder, this Response Code returned without Content-Type As a reminder, this Response Code returned without Content-Type
"application/missing-blocks+cbor-seq" (Section 12.3) is handled as "application/missing-blocks+cbor-seq" (Section 12.3) is handled as
in Section 2.9.2 [RFC7959]. in Section 2.9.2 [RFC7959].
This Response Code returned with Content-Type "application/ This Response Code returned with Content-Type "application/
missing-blocks+cbor-seq" indicates that some of the payloads are missing-blocks+cbor-seq" indicates that some of the payloads are
missing and need to be resent. The client then retransmits the missing and need to be resent. The client then retransmits the
missing payloads using the same Request-Tag, Size1 and Q-Block1 to missing payloads using the same Request-Tag, Size1 and Q-Block1 to
specify the block NUM, SZX, and M bit as appropriate. specify the block NUM, SZX, and M bit as appropriate.
The Request-Tag value to use is determined by taking the token in The Request-Tag value to use is determined by taking the token in
the 4.08 (Request Entity Incomplete) response, locating the the 4.08 (Request Entity Incomplete) response, locating the
matching client request, and then using its Request-Tag. matching client request, and then using its Request-Tag.
The token used MUST be any token that was received in a request The token used MUST be one of the tokens that were received in a
using the same Request-Tag. However, it is desirable to provide request for this block-wise exchange. However, it is desirable to
the one used in the last received request. See Section 5 for provide the one used in the last received request. See Section 5
further information. for further information.
If the server has not received all the blocks of a body, but one If the server has not received all the blocks of a body, but one
or more NON payloads have been received, it SHOULD wait for up to or more NON payloads have been received, it SHOULD wait for up to
NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request
Entity Incomplete) response. Entity Incomplete) response.
4.13 (Request Entity Too Large) 4.13 (Request Entity Too Large)
This Response Code can be returned under similar conditions to This Response Code can be returned under similar conditions to
those discussed in Section 2.9.3 of [RFC7959]. those discussed in Section 2.9.3 of [RFC7959].
skipping to change at page 14, line 37 skipping to change at page 14, line 37
Section 4.6 discusses the use of Size2 Option. Section 4.6 discusses the use of Size2 Option.
The client may elect to request any detected missing blocks or just The client may elect to request any detected missing blocks or just
ignore the partial body. This decision is implementation specific. ignore the partial body. This decision is implementation specific.
The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)
after the last received payload for NON payloads before issuing a after the last received payload for NON payloads before issuing a
GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or
more Q-Block2 Options that define the missing blocks with the M bit more Q-Block2 Options that define the missing blocks with the M bit
unset. It is permissible to set the M bit to request this and later unset. The client MAY set the M bit to request this and later blocks
blocks from this MAX_PAYLOADS set. Further considerations related to from this MAX_PAYLOADS set. Further considerations related to the
the transmission timing for missing requests are discussed in transmission timing for missing requests are discussed in
Section 7.2. Section 7.2.
The requested missing block numbers MUST have an increasing block The missing block numbers requested by the client MUST have an
number in each additional Q-Block2 Option with no duplicates. The increasing block number in each additional Q-Block2 Option with no
server SHOULD respond with a 4.00 (Bad Request) to requests not duplicates. The server SHOULD respond with a 4.00 (Bad Request) to
adhering to this behavior. Note that the ordering constraint is requests not adhering to this behavior. Note that the ordering
meant to force the client to check for duplicates and remove them. constraint is meant to force the client to check for duplicates and
This also helps with troubleshooting. remove them. This also helps with troubleshooting.
For Confirmable responses, the client continues to acknowledge each For Confirmable responses, the client continues to acknowledge each
packet. Typically, the server acknowledges the initial request using packet. Typically, the server acknowledges the initial request using
an ACK with the payload, and then sends the subsequent payloads as an ACK with the payload, and then sends the subsequent payloads as
CON responses. The server will detect failure to send a packet, but CON responses. The server will detect failure to send a packet, but
the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate
GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as
needed. needed.
If the client receives a duplicate block with the same ETag, it MUST If the client receives a duplicate block with the same ETag, it MUST
skipping to change at page 16, line 12 skipping to change at page 16, line 12
appropriate, a 4.13 (Request Entity Too Large) is returned without appropriate, a 4.13 (Request Entity Too Large) is returned without
the Size1 Option. the Size1 Option.
4.5. Using Observe Option 4.5. Using Observe Option
For a request that uses Q-Block1, the Observe value [RFC7641] MUST be For a request that uses Q-Block1, the Observe value [RFC7641] MUST be
the same for all the payloads of the same body. This includes any the same for all the payloads of the same body. This includes any
missing payloads that are retransmitted. missing payloads that are retransmitted.
For a response that uses Q-Block2, the Observe value MUST be the same For a response that uses Q-Block2, the Observe value MUST be the same
for all the payloads of the same body. This includes payloads for all the payloads of the same body. This is different from Block2
transmitted following receipt of the 'Continue' Q-Block2 Option usage where the Observe value is only present in the first block
(Section 4.4) by the server. If a missing payload is requested, then (Section 3.4 of [RFC7959]). This includes payloads transmitted
both the request and response MUST NOT include the Observe Option. following receipt of the 'Continue' Q-Block2 Option (Section 4.4) by
the server. If a missing payload is requested by a client, then both
the request and response MUST NOT include the Observe Option.
4.6. Using Size1 and Size2 Options 4.6. Using Size1 and Size2 Options
Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating
the size of the representation transferred in requests and Size2 for the size of the representation transferred in requests and Size2 for
indicating the size of the representation transferred in responses. indicating the size of the representation transferred in responses.
The Size1 or Size2 option values MUST exactly represent the size of The Size1 or Size2 option values MUST exactly represent the size of
the data on the body so that any missing data can easily be the data on the body so that any missing data can easily be
determined. determined.
skipping to change at page 18, line 31 skipping to change at page 18, line 35
Implementation Note: By using 8-byte tokens, it is possible to Implementation Note: By using 8-byte tokens, it is possible to
easily minimize the number of tokens that have to be tracked by easily minimize the number of tokens that have to be tracked by
clients, by keeping the bottom 32 bits the same for the same body clients, by keeping the bottom 32 bits the same for the same body
and the upper 32 bits containing the current body's request number and the upper 32 bits containing the current body's request number
(incrementing every request, including every re-transmit). This (incrementing every request, including every re-transmit). This
allows the client to be alleviated from keeping all the per- allows the client to be alleviated from keeping all the per-
request-state, e.g., in Section 3 of [RFC8974]. request-state, e.g., in Section 3 of [RFC8974].
7. Congestion Control for Unreliable Transports 7. Congestion Control for Unreliable Transports
The transmission of the blocks of a body over an unreliable transport The transmission of all the blocks of a single body over an
MUST either all be Confirmable or all be Non-confirmable. This is unreliable transport MUST either all be Confirmable or all be Non-
meant to simplify the congestion control procedure. confirmable. This is meant to simplify the congestion control
procedure.
As a reminder, there is no need for CoAP-specific congestion control As a reminder, there is no need for CoAP-specific congestion control
for reliable transports [RFC8323]. for reliable transports [RFC8323].
7.1. Confirmable (CON) 7.1. Confirmable (CON)
Congestion control for CON requests and responses is specified in Congestion control for CON requests and responses is specified in
Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will
need to be increased from 1. However, the other CON congestion need to be increased from 1. However, the other CON congestion
control parameters will need to be tuned to cover this change. This control parameters will need to be tuned to cover this change. This
skipping to change at page 21, line 23 skipping to change at page 21, line 32
For Q-Block1 Option, if the server responds with a 2.31 (Continue) For Q-Block1 Option, if the server responds with a 2.31 (Continue)
Response Code for the latest payload sent, then the client can Response Code for the latest payload sent, then the client can
continue to send the next set of payloads without any delay. If the continue to send the next set of payloads without any delay. If the
server responds with a 4.08 (Request Entity Incomplete) Response server responds with a 4.08 (Request Entity Incomplete) Response
Code, then the missing payloads SHOULD be retransmitted before going Code, then the missing payloads SHOULD be retransmitted before going
into another NON_TIMEOUT delay prior to sending the next set of into another NON_TIMEOUT delay prior to sending the next set of
payloads. payloads.
For the server receiving NON Q-Block1 requests, it SHOULD send back a For the server receiving NON Q-Block1 requests, it SHOULD send back a
2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
payloads to prevent the client unnecessarily delaying. Otherwise the payloads to prevent the client unnecessarily delaying. If not all of
server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled the MAX_PAYLOADS payloads were received, the server SHOULD delay for
based on the repeat request count for a payload), before sending the NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request
4.08 (Request Entity Incomplete) Response Code for the missing count for a payload) before sending the 4.08 (Request Entity
payload(s). If this is a repeat for the 2.31 (Continue) response, Incomplete) Response Code for the missing payload(s). If this is a
the server SHOULD send a 4.08 (Request Entity Incomplete) response repeat for the 2.31 (Continue) response, the server SHOULD send a
detailing the missing payloads after the block number that would have 4.08 (Request Entity Incomplete) response detailing the missing
been indicated in the 2.31 (Continue). If the repeat request count payloads after the block number that would have been indicated in the
for a missing payload exceeds NON_MAX_RETRANSMIT, the server SHOULD 2.31 (Continue). If the repeat request count for a missing payload
discard the partial body and stop requesting the missing payloads. exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial
body and stop requesting the missing payloads.
It is likely that the client will start transmitting the next set of It is likely that the client will start transmitting the next set of
MAX_PAYLOADS payloads before the server times out on waiting for the MAX_PAYLOADS payloads before the server times out on waiting for the
last of the previous MAX_PAYLOADS payloads. On receipt of the first last of the previous MAX_PAYLOADS payloads. On receipt of the first
payload from the new set of MAX_PAYLOADS payloads, the server SHOULD payload from the new set of MAX_PAYLOADS payloads, the server SHOULD
send a 4.08 (Request Entity Incomplete) Response Code indicating any send a 4.08 (Request Entity Incomplete) Response Code indicating any
missing payloads from any previous MAX_PAYLOADS payloads. Upon missing payloads from any previous MAX_PAYLOADS payloads. Upon
receipt of the 4.08 (Request Entity Incomplete) Response Code, the receipt of the 4.08 (Request Entity Incomplete) Response Code, the
client SHOULD send the missing payloads before continuing to send the client SHOULD send the missing payloads before continuing to send the
remainder of the MAX_PAYLOADS payloads and then go into another remainder of the MAX_PAYLOADS payloads and then go into another
skipping to change at page 45, line 35 skipping to change at page 45, line 35
Acknowledgements Acknowledgements
Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their
comments. comments.
Special thanks to Christian Amsuess, Carsten Bormann, and Marco Special thanks to Christian Amsuess, Carsten Bormann, and Marco
Tiloca for their suggestions and several reviews, which improved this Tiloca for their suggestions and several reviews, which improved this
specification significantly. Thanks to Francesca Palombini for the specification significantly. Thanks to Francesca Palombini for the
AD review. AD review.
Thanks to Pete Resnick for the Gen-ART review.
Some text from [RFC7959] is reused for readers convenience. Some text from [RFC7959] is reused for readers convenience.
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
 End of changes. 23 change blocks. 
70 lines changed or deleted 76 lines changed or added

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