Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blockwise (block1) FETCH in combination with observe #18

Open
boaks opened this issue Oct 19, 2021 · 1 comment
Open

Blockwise (block1) FETCH in combination with observe #18

boaks opened this issue Oct 19, 2021 · 1 comment

Comments

@boaks
Copy link

boaks commented Oct 19, 2021

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?

  • the token of the first blockwise request?
  • the token of the last blockwise request (with the first response with payload)?
  • any token else?
@mrdeep1
Copy link

mrdeep1 commented Oct 20, 2021

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants