Re: [core] Incoming AD review of draft-ietf-core-block-19

[Alexey Melnikov <[e-mail]>]

Hi Carsten,
Thank you for your responses. Further discussions below:

On 21/04/2016 07:14, Carsten Bormann wrote:
> Alexey Melnikov wrote:
>> Hi,
>> I am mostly happy with this document, but I have a few comments/questions:
>>
>> On page 11:
>>
>>    Clients that want to retrieve
>>    all blocks of a resource SHOULD strive to do so without undue delay.
>>
>> This is not an interoperability issue and it would be impossible to
>> verify compliance with it, unless you have a number that specifies what
>> is "undue delay". So I think you shouldn't use RFC 2119 SHOULD here.
>> Just use lowercased "should" instead.
> 
> Indeed, you cannot measure compliance with this SHOULD.  I still think
> that it is important for interoperability to point out that clients will
> have more successful exchanges if they heed this.  (From an
> interoperability point of view, this is a statement that relieves
> servers of a potential onus to somehow cater for clients that don't.)
> 
>> Similarly, in 2.5:
>>
>>    Clients SHOULD strive to send all blocks of a
>>    request without undue delay.
>>
>> (Similar text in 2.6)
> 
> (Ditto.)

I think I prefer to have some recommendations on what is "undue delay",
if you can add some text.

>> In 2.9.2:
>>
>> Should probably also mention that this response code is also used for
>>  mismatching content-format options
> 
> That is one way to see this; section 2.3 takes the view that mismatching
> content-formats aren't reassembled into one body in the first place so
> an incomplete body is the result of not having all parts.
> (I added back reference in the editor's draft.)

What is the state of the resource in such condition?

>> In 2.10:
>>
>>    A response with a Block1 Option in control usage
>>    with the M bit set invalidates cached responses for the target URI.
>>
>> Can you explain the reason for this?
> 
> 
> If the M bit had not been set the response would have been a final
> response and would be used to update the cache entries for this URI.
> Now, with the M bit set, we know that there will be a final response
> later, but we don't know what that will be.  Continuing to serve a
> previous response from the cache doesn't sound right.  But then, it
> could be argued that the server just promised to perform the request
> atomically later, so nothing has happened yet.  Good question.
> 
>>
>> In 3.2:
>>
>>    A stateless server that simply builds/updates the resource in place
>>    (statelessly) may indicate this by not setting the more bit in the
>>    response (Figure 8); in this case, the response codes are valid
>>    separately for each block being updated.
>>
>> What is the behaviour of both the client and the server if PUT on a
>> particular block fails? Is this clear enough in the document?
> 
> In the stateless case, the resource is now probably broken (unless the
> resource is somehow intrinsically robust to this case).  The client
> should not be using the resource (e.g., try to initiate a firmware
> update from an image it just has been building).  The server is
> stateless with respect to individual requests, so it is patiently
> sitting there for the broken resource to be mended.

How can a resource be "mended" if a PUT failed? I think it would be
reasonable for a server implementation to discard the whole accumulated
payload, so there would be no way to mend it other than by uploading the
whole thing from the beginning. If my interpretation is invalid, I
welcome some clarifications on this.

So I think this needs more clarifying text, either describing what
client might be able to do to fix the resource or explaining that the
client need to restart upload.

>> Other questions I have after reviewing the document. If I missed where
>> they are answered, please point me out to existing text in the document
>> or another RFC:
>>
>> Is there a special error for block size mismatch between multiple requests?
> 
> A block size mismatch is not an error (maybe I don't understand the
> question).

There are MUSTs in the document saying that if one end signalled a
certain block size, the other party needs to use the same or smaller
size. What happens if the other party doesn't obey this rule. Is there a
special error code that can be used to signal that a request is rejected
because the specified block size is too big?

>> As block2 is a critical option, how can a server know if a particular
>> client supports this option?
> 
> The assumption here is that CoAP clients generally do, unless they are
> very specialized and never have to deal with non-trivial amounts of
> information (such as a /.well-known/core).

Is this generally true for all COAP extensions or just some?

Extensibility for most protocols is done by capability
discovery/negotiation and graceful service degradation in absence of a
particular extension. This seems to violate this principle.