You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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)
cabo
transferred this issue from core-wg/corrclar-old
Jul 22, 2023
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 text was updated successfully, but these errors were encountered: