Re: [core] Status of Blockwise Transfers

["Kovatsch Matthias" <[e-mail]>]

Thanks for the responses!

> > The current spec seems to already take this "most likely to happen" meaning
> > for the status code in the examples, e.g. blockwise PUT returns 2.04 each
> > time but if a block is missing the final result could still be 2.04 or 4.00 or 4.08.
> > POST could do the same?

But what is most likely to happen?
The author of the server implementations will just arbitrarily pick a status code, which still has no meaning.
A badly written client then might misinterpret that intermediate status. I think, it only creates a source of errors.

> > On your first point, concurrent Block1/Block2 usage, that seems only applicable to POST or doesn't it?
> From the spec, only concurrent POST is mentioned.

Yes, that is how I understand it as well. A successful PUT would always results in resource state, i.e., no payload in the response.

> In the Size extension draft, I proposed to get the resource size by the Size option, and use concurrent GET for blocks.
> http://www.ietf.org/id/draft-li-core-coap-size-option-02.txt

I would say an upper bound (sz attribute) is enough. Embedded devices usually avoid dynamic memory allocation and those which use it probably have plenty of memory from a CoRE point of view.
For the concurrent GETs, one should be careful not to re-invent/implement TCP (sliding window for messages in flight), I guess. If it is required, the devices should rather switch to another protocol, shouldn't they?
I also saw that even for the server it can be hard to know the exact size in advance. With content-negotiation, the representation is created on-the-fly from some variables. When including on-demand sensor readings, the server cannot even do a "dry run" to pre-cache the sizes for each content-type.

Best regards
Matthias