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

[Marco Tiloca <[e-mail]>]

Hi Jon,

Thanks for the fast reaction. Please, see inline.

Best,
/Marco

On 2021-01-11 17:39, [e-mail] wrote:
> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&data=04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554192170%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=P5eiQyl8meRhZX9t6gtNqwc29ryqLRGnOUwmFQxAydo%3D&reserved=0 and the differences with the draft can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core-new-block.txt&data=04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IYKVrC1a56Cva5mR4xoM0VM5y6dhjtQ7M6L5PwlCqzA%3D&reserved=0
>
> The PR for the responses below can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block%2Fpull%2F13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=b9hq1V5X136oGB65e9Ni12V0weXoNa%2FY1DT8QtzFRqQ%3D&reserved=0 
>
> 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.

==>MT
Looks good.
<==

>
> [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.

==>MT
If it's really about the client just asking to delete a resource, then a
DELETE is more efficient.

But, the client might just be asking the server to process its POST
payload, and it's the server that eventually takes the decision to
delete the resource, as a possible side-effect following the request
processing.

I think that's what the "if" wanted to suggest in RFC 7252, Section
5.8.2: "If the POST succeeds and results in the target resource being
deleted, the response SHOULD have a 2.02 (Deleted) Response Code."

Alternatively, the client may actually want to delete the resource as
somehow indicated in the payload, only following the processing of the
rest of the payload. This would not be possible with a DELETE (that has
no payload) and if supported by the application it is more efficient
than sending first a POST and then a DELETE.
<==

>
> 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).

==>MT
Looks good.
<==

> [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.

==>MT
Looks good.
<==

>
>> 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.  

==>MT
Oops, I actually meant 2.05 in the paragraph above. Sorry for the confusion.
<==

> 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.

==>MT
Looks good.

As to the two new examples in Figures 11 and 12, please add the Observe
option with value 0 to the requests from the client, i.e. O:0, just like
you do in Figures 7 and 8.

Best,
/Marco
<==

> ~jon
>> Best,
>> /Marco
>>
> <snip>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se