Re: [core] WG Last Call on draft-ietf-core-new-block

[[e-mail]]

Hi Marco,

It is good that you are thinking this properly through.  FETCH was added later into this draft and the consequences were not properly thought through.

The new updates have been pushed to https://github.com/core-wg/new-block and the differences with the draft can be found at https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-block&url2=https://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-new-block.txt

The PR for the responses below can be found at https://github.com/core-wg/new-block/pull/13 

Otherwise, see inline.

Regards

Jon

> -----Original Message-----
> From: Marco Tiloca [mailto: [e-mail]]
> Sent: 11 January 2021 11:39
> To:[e-mail]; [e-mail]; draft-ietf-core-new-
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> Hi Jon,
> 
> Thanks, the updates look good.

[Jon] Thanks
> 
> As to the response codes in Section 3.3 "Using the Q-Block1 Option",
> wouldn't it make sense to mention also 2.05 (Content) ? Think of a FETCH
> request with a big body, which is actually mentioned at the beginning of
> Section 3.3 and in Section 3.1 (though missing the 2.05 response code
> beside it).

[Jon] Thanks - added.  Also added in 2.02 and 2.05 as being expected response codes in 3.3.

[Jon] For the 2.02,  I struggle with why anyone would want to use a POST with a large payload to cause the resource to get deleted (instead of using DELETE) , but RFC7252 allows this to happen.

OLD
   Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
   PATCH, and iPATCH requests and their responses (2.01 and 2.04).
NEW
Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PATCH, and iPATCH requests and their responses (2.01, 2.02, 2.04, and 2.05).

[Jon] And added into 3.3 (2.05 is done further into this discussion)

NEW
2.02 (Deleted)

This Response Code indicates successful receipt of the entire body and the resource was deleted when using POST (See Section 5.8.2 [RFC7252]). The token used SHOULD be from the last received payload. The client should then release all of the tokens used for this body.

> 
> Also, more in general, think of an observe registration, for which the
> server eventually sends back a first notification (possibly split into
> multiple payloads) with Q-Block2, with a certain Token value.

[Jon] OK
> 
> If the observation request used FETCH and was fragmented into several
> payloads with Q-Block1, each of which with a different Token, it's still
> true that the notifications can all have any of those Token values and
> should have the one of the last received request payload.

Jon[OK]
> 
> However, later on the client has to retain that Token value as the one
> associated to the observation, to match future notifications to come. In
> this case, there is a deviation from the claim used for other response
> codes, i.e. "The client should then release all of the tokens used for
> this body." This should concern only 2.01 notifications (hence including
> the Observe option) in response to observation requests with FETCH, so
> it can be limited to the context of this section about Q-Block1.

[Jon] I was not aware that FETCH could return 2.01 or 2.04.  GET does not return these codes and it is only GET and FETCH that can Observe.  However, it is true what you say for 2.05, so I have added that the tracked Observe token must be the (if Q-Block1) the one used for Q-Block1 that has the M bit unset.  I have added in some FETCH examples into the draft.

NEW
2.05 (Content)

This Response Code indicates successful receipt of the entire FETCH request body (See Section 2 [RFC8132]) and the appropriate representation of the resource has been returned. The token used in the response MUST be the one in the FETCH request that has the Q-Block1 with the M bit unset. If the FETCH request includes the Observe Option, then the server MUST use the same token for returning any Observe triggered responses. The client should then release all of the tokens used for this body unless a resource is being observed.

~jon
> 
> Best,
> /Marco
> 

<snip>