RFC7959 - Block1 Option in Error Response 4.08 (Request Entity Incomplete)

[boaks]

Though I'm currently over the Californium implementation:

Is it considered to use the Block1 option in an error response with 4.08 for a put/post block1 request?

I read RFC7959, 2.5, 2.9.2, and 3.2 and miss that. Hope I didn't over-read it.

[mrdeep1]

I would not expect Block1 to be in an error response, but there is not a MUST NOT that I am aware of. Its general usage in a response is to indicate that another block SZX should be used.

As token matching takes place for any response, then it is possible to determine which specific request including Block1 generated the error response. It certainly is not defined that a Block1 in an 4.08 error response indicates this is the missing block, or this is the last block received etc. so likely to break different implementations if supported.

As a side note, draft-ietf-core-new-block (to-be-9177) extends the 4.08 response to include the missing set of Q-Block1 packets in the diagnostic payload if you are looking for something like that - see to-be-9177 Section 5.

[chrysn]

I agree with mrdeep1's assessment.

Note that there can't practically be a Block2 in an error response: reassembling a Block2 reliably needs an ETag, and that can't be present in an error response as per 7252 section 5.10.6.1.

That "missing set" format is something I consider rather useful also for classical block operation.

[boaks]

That "missing set" format is something I consider rather useful also for classical block operation.

For block1, the first missing block should do it.

I would recommend, to rather split the resources than to use block1 too frequently. In my experience, a lot of the superior robustness of CoAP is based on a single, rather small message. And with that, I'm not sure, if such an improvement pays off.

[mrdeep1]

I agree that if all can fit into one message, that is a better way to go, but not always easy to do. This was one of the reasons for coming up with to-be-rfc9177 to provide a robust way of transferring multiple payloads for a body where CoAP has to work in lossy environments when networks are under attack - in particular uni-directional network loss. An issue that the DOTS work had to solve.

[boaks]

If there is "more" data than fits into a single message , the main question from FMPOV is:

Could that data be split into smaller parts, each useful on it's own?

That was also the question that time ago, when the discussion about that transfer in DOTS started.
Blockwise is not generally bad. If it's possible to split the data into smaller useful messages, then the application may benefit from processing that smaller messages before all the other messages arrives. And that makes an application fast and robust. If it's not possible, to split the data, or takes to much effort, then using blockwise is an option to overcome that. For me, not the first choice. Only for GET on static resources (e.g. FOTA) blockwise is a good choice, if https is not available. Only, if a larger time to complete the download, maybe with breaks/interrupts, is possible.

[mrdeep1]

Could that data be split into smaller parts, each useful on it's own?
That was also the question that time ago, when the discussion about that transfer in DOTS started.

Yes, the main DOTS CoAP exchanges are all designed to fit into a single packet. Since then, the need for telemetry information to be exchanged under attack scenarios became apparent which was not so easy to fit into a single packet - see DOTS Telemetry

[boaks]

The discussion gets a little off topic, but interesting.
Your "see" is about 119 pages. Is it possible to narrow the scope to the description of the message, which could not be split into useful smaller messages?

[mrdeep1]

draft-ietf-dots-telemetry Section 9.1 and Section 9.2 indicate the potental fullness of the telemetry information that can be transferred. In practical terms, this is usually less than 10 payloads per body and a sparce set of information can fit in a single payload.