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

[Achim Kraus <[e-mail]>]

Hi Carsten,

thanks a lot!

 > So it is not forbidden to request a smaller block size later.

My point is,
- was this intented or
- just not considered and therefore not explicitly forbidden?

All examples and some text points more into the direction, that it is
intended to be negotiated only in the 1. exchange. I'm still not
convinced, I think to forbid this is the better approach.

Sure, if no-one else has doubts, go for it.

best regards
Achim Kraus

Am 22.07.20 um 13:08 schrieb Carsten Bormann:
> Hi Achim,
>
> Good questions.
>
>> On 2020-07-22, at 09:56, Achim Kraus <[e-mail]> wrote:
>>
>> Dear list,
>>
>> I would really appreciate, if the detail questions about the 4.13
>> failover could be answered!
>>
>> Without answers, I'm still afraid, that implementations will became
>> "overcomplicated" and "less interoperable".
>>
>> 1. is it intended to change the block size only in the first exchange?
>> Or on other exchanges? (Additionally, if changing later is considered as
>> failure, how should that failure be handled/processed?)
>
> RFC 7959 says (Section 2):
>
>     In most cases, all blocks being transferred for a body (except for
>     the last one) will be of the same size.  (If the first request uses a
>     bigger block size than the receiver prefers, subsequent requests will
>     use the preferred block size.)  The block size is not fixed by the
>     protocol. […]
>
> Simon cited some more text, but this is about too many blocks, not about too big blocks.  So it is not forbidden to request a smaller block size later.  I would expect that this is a rather unusual case, so I would not be surprised if a client gives up if this happens in mid-transfer.  On the other hand, it is also not hard to enable a client to adapt.
>
>> 2. is it intended, that a 4.13 response without block1 option to a
>> request also without block1 option, should also use/try a failover with
>> a request with block 1 option?
>
> That’s what RFC 7959 says:
>
>     The error code 4.13 (Request Entity Too Large) can be returned at any
>     time by a server that does not currently have the resources to store
>     blocks for a block-wise request payload transfer that it would intend
>     to implement in an atomic fashion.  (Note that a 4.13 response to a
>     request that does not employ Block1 is a hint for the client to try
>     sending Block1, and a 4.13 response with a smaller SZX in its Block1
>     Option than requested is a hint to try a smaller SZX.)
>
> This is phrased as a note, because the response contains a hint; there is no requirement that Block1 is supported.
>
> Simon also asked:
>
>>    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 ?
>
> I would expect that the server should send the desired block size if it wants the client to change from the block size it used, so 4.13 + Block1.  Size1 is not about block size, but about the size of the whole body - if the server has a limitation there, it might want to error out on a 4.13 (without a Block1 option).
>
> Grüße, Carsten
>