[core] Strictness of RFC7959

[Christian Amsüss]

Hello block-wise authors,
hello CoRE,

I am uncertain about the behavior RFC7959 actually prescribes to
servers: How liberal is it for servers about which blocks can be acted
on together (or when to send 4.08 Request Entity Incomplete)?

The last paragraph of section 2.4 implies that the Cache-Key[1] is what
messages are grouped by (which makes sense and would make the
specification of Request-Tag much shorter), but nowhere else is the
cache key mentioned in the document.

What is the expected behavior of a server (or let's say proxy, as the
proxy needs to do block-wise too but doesn't need to know elective
options) in presence of similar-but-not-quite-alike messages from the
same source that could be a blockwise operation? Group by URI? By
Cach-Key? By all options unless it knows it's irrelevant from the
option's description? May the server choose depending on the
application?

And can I rely on that behavior in echo-request-tag?

Best regards
Christian

[1]: Actually Cache-Key without request body after RFC7252 errata, as
that body is not represented in Block2 phase when combining.

[Christian Amsüss]

Hello CoRE, hello lwig-coap authors,

Post by Christian Amsüss
I am uncertain about the behavior RFC7959 actually prescribes to
servers: How liberal is it for servers about which blocks can be acted
on together (or when to send 4.08 Request Entity Incomplete)?

At small discussion during the hackathon, there seemed to be a tendency
toward interpreting Block1 to be keyed by (endpoint, endpoint,
cache-key) rather than (endpoint, endpoint, path) -- however, that might
not be fully explicit in RFC7959, and might call for either implentation
guidance or even clarification by an update.

To get this started, I propose the following paragraphs for lwig-coap
(which might easily be moved around to other documents if they fit
better there):

---

### 3.4.1 Proxying without deeper understanding of proxy operations

Proxies can not ignore the Block options -- by specification, because
Block are not safe-to-forward, and by rationale of messages from
different clients being understood by the server to constitute an atomic
operation.

A proxy can, however, <!-- and I do not have the formal means to prove
it --> ensure that this does not happen by adding an option that
prevents such confusion. Appending a Request-Tag (see
{{I-D.ietf-core-echo-request-tag}}) that is derived from the requester's
endpoint is one way to do that.

### 3.4.2 Atomic blockwise operations

When an implementation does need to assemble blocks from block-wise
transfers, applications need to form a key by which to identify messages
that can be grouped together. This "Block Key" at least contains:

* The source endpoint (eg. IP address and port in the UDP case)
* The destination endpoint
* The Cache-Key (as updated in {{RFC7252}})
* All options that are proxy unsafe and not explicitly described as safe
for blockwise assembly.

The only known options safe for blockwise assembly are the Block1 and
Block2 options.

For the Block1 phase, the request payload is excluded from the key
generation as it is just being assembled.

If a message is received that is not the start of a blockwise operation,
has a Block Key that is not known, and the implementation needs to act
atomically on a request body, it can only answer 4.08 Request Entity
Incomplete.

Conversely, clients should be aware that requests whose Block Key
matches can be interpreted by the server atomically. This especially
affects proxies (see 3.4.1).

---

If the statements in this do not correctly reflect the intention of
RFC7959, we should discuss this further to arrive with paragraphs that
do.

Best regards
Christian