Subject: Re: [core] draft-ietf-core-block-08 - Block ordering

From: Maciej Wasilak <[email-masked]>
Date: Wed, 23 Jan 2013 21:30:01 +0100

Hello,

some time ago there was a discussion whether blocks in blockwise transfer
should be sent in sequential fashion. The suggested approach was:

1) the protocol does not fundamentally disallow out-of-order access (and,
many servers will be able to provide out-of-order access (e.g., because
they are stateless))
2) still, there is an expectation that more servers will be able to cope
with sequential access than with out-of-order access.  Servers that
implement one of the Block options SHOULD enable sequential access, and MAY
enable out-of-order access.

Question:
In what way server which accepts only sequential access should reject
out-of-order messages? Is it okay to send 4.08 Request Entity Incomplete error
message? (or is it reserved only for cases when M byte is not set).
Best Regards
Maciej Wasilak

2012/4/12 Carsten Bormann <[email-masked]>

> On Apr 12, 2012, at 11:36, Dijk, Esko wrote:
>
> > Carsten,
> >
> >> So a client that wants to maximize interoperability will probably
> operate in sequential fashion.
> > Ok. If this constitutes the minimum level of interoperability for
> core-block, should we mandate it as such?
> >
> > Option 1) e.g. specify a CoAP end-point MUST be prepared to receive
> block numbers in sequential fashion.
>
> Well, it is hard to say what such a MUST ("be prepared to receive...")
> really constrains.
> A server can still always go belly-up, stop serving a resource, ...
>
> I think the point is indeed that there is a larger expectation of
> successful completion when a client steps sequentially through the blocks
> of a resource.
>
> > Option 2) e.g. specify a CoAP end-point MAY use block numbers in
> sequential fashion.
> >              [this automatically implies an end-point MUST be prepared
> to receive sequential block numbers. At least an implementer MUST
> >               consider this possibility.]
>
> But it also MAY use out-of order accesses... just with a slightly lower
> level of expectation that the server will be able to successfully respond.
>
> > Though, the sequential case is so obvious from the I-D that it is
> already a de-facto minimum interoperability (though not formally stated).
>
> That was indeed my reasoning so far.
>
> To me it seems we could make all this more apparent by stating two things:
>
> 1) the protocol does not fundamentally disallow out-of-order access (and,
> many servers will be able to provide out-of-order access (e.g., because
> they are stateless))
> 2) still, there is an expectation that more servers will be able to cope
> with sequential access than with out-of-order access.  Servers that
> implement one of the Block options SHOULD enable sequential access, and MAY
> enable out-of-order access.
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>