Description
The way RFC8323 is written defines BERT (ie. using block-wise's szx=7 to mean "indexed at 1024 byte blocks, but may have several of them in the payload") only for reliable transports.
As this would be useful in other applications outside TCP/WS, and as it is unlikely that any other extension to block-wise would scoop up this extension point of RFC7959 for unreliable transports in a different way, I suggest that the next update to 7959 just acknowledge that BERT is universal.
Concrete applications include:
-
Amortizing block-wise overheads in OSCORE: An OSCORE transfer can be inner- and outer-blockwised independently.
- All outer-blockwising may be too taxing for the device (which'd have to assemble the representation in RAM) or even the AEAD algorithm (AES-16-64-128 has a 64KiB limit).
- All inner-blockwising creates a per-message overhead of at least 8 byte in 1:1 and 64 in group mode.
The balancing of the inner block size is currently limited to 16..1024 byte, whereas BERT would open that space up to any multiple of 1024 bytes.
-
With CoAP being used outside of constrained devices (as in DOTS), it's not unreasonable any more that MTU discovery is available and finds support for jumboframes.
-
Internally (eg. inside a CoAP implementation) it can be convenient to let the library handle some block-wising (not bother the application with every 32 bytes of requested data) but not all of it (eg. because not all data is ready yet); BERT would allow serving larger chunks and letting the proxy that is the CoAP library do the small things.
I think that this can be done by just stating things in an update. It'd probably say that for CoAP-over-{TCP,WS} the CSM is the way to agree, and that other transports may define their mechanisms (of which there currently are none) to indicate a non-default maximum.
[edit: github's markdown is weird. probably, all markdown is weird.]