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

Commentary: WGLC review by     22 : " contain a multiple of 1024 bytes ( non - final BERT block ) or more than 1024 bytes ( final BERT block ) " -Why ca n't the final block be 1024 bytes ? I assume a final BERT block of 1024 bytes is allowed ; it would be strange to switch back to SZX=6 for that purpose . What about below text -"contain a multiple of 1024 bytes ( non - final BERT block ) or more than 1023 bytes ( final BERT block ) " 
 would you review and validate ? 
 The text explains what is allowed with  that is not allowed with SZX=6 . As correctly noted , 1024 final is already allowed for SZX=6 ( as is 1023 , 1022 , ... ) , so this is not explicitly listed in the list of additionally allowed cases . Maybe make clearer that this extends what has been allowed before instead of just saying that this is now allowed : s / is allowed / is also allowed/ or s//is additionally allowed/. 
 That seems like a simpler ( if more subtle ) edit .
A sender can also include an elective Custody Option in a Ping
message to explicitly request the inclusion of an elective Custody
Option in the corresponding Pong message.  The receiver SHOULD delay
its Pong message until it finishes processing all the request/
response messages received prior to the Ping message on the current
connection.
A sender can also include an elective Custody Option in a Ping
message to explicitly request the inclusion of an elective Custody
Option in the corresponding Pong message.  In that case, the receiver
SHOULD delay its Pong message until it finishes processing all the
request/response messages received prior to the Ping message on the
current connection.
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).
In descriptive usage, a BERT Option is interpreted in the same way as
the equivalent Option with SZX == 6, except that the payload is also
allowed to contain a multiple of 1024 bytes (non-final BERT block) or
more than 1024 bytes (final BERT block).
In all these examples, a Block Option is decomposed to indicate the
kind of Block Option (1 or 2) followed by a colon, 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.
In all these examples, a Block Option is decomposed to indicate the
kind of Block Option (1 or 2) followed by a colon, the block number
(NUM), more bit (M), and block size (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.
Resources made available via these schemes have no shared identity
even if their resource identifiers indicate the same authority (the
same host listening to the same TCP port).  They are distinct
namespaces and are considered to be distinct origin servers.
Resources made available via these schemes have no shared identity
even if their resource identifiers indicate the same authority (the
same host listening to the same TCP port).  They are hosted in
distinct namespaces because each URI scheme implies a distinct origin
server.
If |url| does not have a <scheme> component whose value, when
converted to ASCII lowercase, is "coap+tcp", "coaps+tcp", "coap+ws",
or "coaps+ws" then fail this algorithm.
If |port| does not equal the request's destination TCP port, include
a Uri-Port Option and let that option's value be |port|.
For CoAP over TCP, if the request is secured using TLS, let |url| be
the string "coaps+tcp://".  Otherwise, let |url| be the string
"coap+tcp://".  For CoAP over WebSockets, if the request is secured
using TLS, let |url| be the string "coaps+ws://".  Otherwise,
let |url| be the string "coap+ws://".
If the request includes a Uri-Port Option, let |port| be that
option's value.  Otherwise, let |port| be the request's destination
TCP port.
The steps are the same as specified in Section 6.4 of RFC7252 with
minor changes.
The steps are the same as specified in Section 6.5 of RFC7252 with
minor changes.