[core] block1 size negotiation with 4.13 Request Entity Too Large

[Simon Bernard <[e-mail]>]

Hi all,

   I have several questions about block1 size negotiation.
   The specification <https://tools.ietf.org/html/rfc7959#section-2.9.3> 
says :

    The present specification allows the server to return this response
    code (4.13) at any time during a Block1 transfer to indicate that it does
    not currently have the resources to store blocks for a transfer that
    it would intend to implement in an atomic fashion.  It also allows
    the server to return a 4.13 response to a request that does not
    employ Block1 as a hint for the client to try sending Block1.

    Finally, a 4.13 response to a request with a Block1 Option (control
    usage, seeSection 2.3  <https://tools.ietf.org/html/rfc7959#section-2.3>) where the response carries a smaller SZX in
    its Block1 Option is a hint to try that smaller SZX.

   So if a client send a block1 request and server can not handle a so 
big block it can answer with 4.13 + block1 with szx option. This means 
sends me smaller block (size is given in szx option).

   1) Could this kind of negotiation happen in a middle of a block1 
transfer ? or any block size negotiation (even negotiation which does 
not use 4.13) should always be done on first exchange ?

    Now Imagine a client which sends a normal (not block1) request with 
a too large payload and server want this payload be sent by block1.

   2) What exactly should send the server ? 4.13 or 4.13 + block1 with 
szx option ? is size1 should be used to guess the correct block size ?

    The more straightforward way seems to be "4.13 +block1 with szx 
option" this way this is clear that server support block1 and it gives 
the exact size of block it want. But the rfc sounds to consider this way 
only if original request is block1 too.

Thank you,

Simon