Draft: draft-ietf-core-coap-tcp-tls

Commentary: Not quite clear to me that the best place is between TCP / TLS and Websockets , as this applies to both . 
 Agreed . It 's corrected in the next pull request . For some reason , my mind is stuck in a rut about websockets as more of a tunneling protocol that just another wire format on TCP after the Upgrade .
a UDP-to-TCP gateway may simply not have the context to convert a
message with a Block option into the equivalent exchange without
any use of a Block option.
This specification extends the block protocol to be able to make use
of the larger messages over a reliable transport.  This extension is
called 'Block-Wise Extension for Reliable Transport (BERT)'.
I-D.ietf-core-block uses a message size of maximum 1024 bytes and
this specification extends this maximum size to 1024 KiB (= 1 MiB) by
re-interpreting the length information.
In control usage, a BERT option is interpreted in the same way as the
equivalent option with SZX == 6, except that it also indicates the
capability to process BERT blocks.  As with the basic Block protocol,
the recipient of a CoAP request with a BERT option in control usage
is allowed to respond with a different SZX value, e.g. to send a non-
BERT block instead.
In descriptive usage, a BERT option is interpreted in the same way as
the equivalent option with SZX == 6, except that the payload is
allowed to contain a multiple of 1024 bytes (non-final BERT block) or
more than 1024 bytes (final BERT block).
The recipient of a non-final BERT block (M=1) conceptually partitions
the payload into a sequence of 1024-byte blocks and acts exactly as
if it had received this sequence in conjunction with block numbers
starting at, and sequentially increasing from, the block number given
in the Block option.  In other words, the entire BERT block is
positioned at the byte position that results from multiplying the
block number with 1024.  The position of further blocks to be
transferred is indicated by incrementing the block number by the
number of elements in this sequence (i.e., the size of the payload
divided by 1024 bytes).
As with SZX == 6, the recipient of a final BERT block (M=0) simply
appends the payload at the byte position that is indicated by the
block number multiplied with 1024.
The following sub-sections provide a few examples that involve BERT
options.  Extending the notation used in that section, a value of SZX
== 7 is shown as "BERT", or as "BERT(nnn)" to indicate a payload of
size nnn.
In all these examples, a Block option is shown in a decomposed way
indicating the kind of Block option (1 or 2) followed by a colon, and
then the block number (NUM), more bit (M), and block size exponent
(2**(SZX+4)) separated by slashes.  E.g., a Block2 Option value of 33
would be shown as 2:2/0/32), or a Block1 Option value of 59 would be
shown as 1:3/1/128.
The first example, see fig-bert1, shows a GET request with a response
that is split into three BERT blocks.  The first response contains
3072 bytes of payload; the second, 5120; and the third, 4711.  Note
how the block number increments to move the position inside the
response body forward.
The following example, see fig-bert2, demonstrates a PUT exchange
with BERT blocks.