MSC4300: Processing status requests & responses #4300
Conversation
Johennes
force-pushed
the
johannes/request-response
branch
from
07e91a2 to
256d5d8
Compare
Johennes
changed the title
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
Johennes
force-pushed
the
johannes/request-response
branch
from
256d5d8 to
aa5b57b
Compare
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Sending client
- Receiving client (with support)
- Receiving client (without support)
|
|
||
| ## Proposal | ||
|
|
||
| A new content block `m.request.status` is introduced to request a processing status from other |
There was a problem hiding this comment.
Shouldn't it be m.status.request and m.status.response like the m.key.verification.* events?
There was a problem hiding this comment.
Hm, good question. My assumption was that there might be further specialized request types in future – as in requests that ask for something else than the processing status. Therefore, I made request the namespace. I have no concrete examples in mind, however, and don't feel strongly about the naming either.
|
|
||
| ## Proposal | ||
|
|
||
| A new content block `m.request.status` is introduced to request a processing status from other |
There was a problem hiding this comment.
Do we really need a request for the described use cases? Couldn't the receiver proactively just decide to send a status, when it does not support event types instead of letting the sender always request the status?
There was a problem hiding this comment.
I think that could be helpful but it seems to solve a slightly different problem.
My assumption was that the sender would only add status requests on events that, for one reason or another, are important. Things such as prescriptions or sick notices where the content is not just plain text and where as the sender I need to make sure that you have actually understood and processed the event correctly. That means the majority of events would not include status requests which made adding it on the sender side appear acceptable.
Only sending the status response when an event was not understood would mean that the only signal of successful processing is the absence of a response. But then you won't know if the recipient didn't respond because it understood the event or if it simply hasn't received and processed the event yet.
Rendered