core-wg / corrclar

Corrections and Clarifications to CoRE standards
Other
0 stars 0 forks source link

Blockwise (block1) FETCH in combination with observe #18

Open boaks opened 2 years ago

boaks commented 2 years ago

I'm currently struggling with a detail using FETCH.

Assuming, the FETCH requires more blocks of payload and so uses a BLOCK1 transfer to the server. With that, the server will receive multiple requests, with several tokens, which are not related. The observe then requires a token in order to establish the observe-notify relation, notifies will (re-)use that token (at least for their first response block, if the response is blockwise as well).

Question: Which token is intended to be used here for the observe-relation?

mrdeep1 commented 2 years ago

In draft-ietf-core-new-block-14 Section 4.3 there is some clarity here, namely

      If the FETCH request includes the Observe Option, then the server
      MUST use the same token as used for the 2.05 (Content) response
      for returning any Observe triggered responses so that the client
      can match them up.

The response that potentially includes some data is the 2.05 response, and when the unsolicited observe response is triggerred, it is not triggering to send back a new 2.31 response, but is triggereing to send a new 2.05 response. So, to me is has to be the token that was used that got the initial 2.05 response back (Yes, there is more token tracking / token mapping to do)

The follow on question to this is:-

What does the FETCH request to get the next BLOCK2 comprise of - does it require the entire original FETCH body? RFC7959 2.7 hints at

      To continue this Block2 transfer, the client
   continues to send requests similar to the requests in the Block1
   phase, but leaves out the Block1 Options and includes a Block2
   request option with non-zero NUM.

and draft-ietf-core-new-block-14 Section 10.3.3 has

                     Note that, following Section 2.7 of [RFC7959], the
   FETCH request does not include the Q-Block1 or any payload.

Then the next questions are:-

What is the FETCH request used to cancel an Observe request - does it have to contain all the BLOCK1 payloads? (I believe the answer includes the entire body potentially spanning multiple payloads as the body can indicate selection parameters)

Which Token should it be using to initiate the cancelling of the Observe request? (I think it is the 2.05 response token)