|
Unknown opened 5 years ago
|
|
|
If the message is not delivered then it is marked by SiskinIM in the chat (if was stamped with ID, the response had a body and it was possible to be identified). In any other case message, the message is skipped. If the message does not have a body element then in most cases it will not be stored in the offline storage anyway, so with iOS client (being mostly offline), the error would not be delivered anyway. |
|
|
I've tested the behavior by sending a message from Siskin to reject@yax.im, which will automatically send an error response to the message, referencing the original message id. However, Siskin didn't show any annotation to the message. Feel free to test yourself with the bot. |
|
|
As I've mentioned, Siskin adds an error if the response has a body, while reject@yax.im does not include body element in the response as I've checked. |
|
|
I haven't yet seen message errors with a body element in the wild, and I'm pretty sure that would be considered as non-standard by most. Have a look at RFC6120 ยง8.3 for the rules around message errors, they only suggest an |
|
|
I know RFC and I also know that in most cases there is no specific I've already mentioned, the message of type error without body element most likely will be dropped if the client is disconnected as message will not be saved to the offline storage by the server unless we add a hint to store a message. But this as well is not within RFC and would be considered non-standard. So we can improve the client handling of the error (and we will), however, it will not improve the storage of error message while the client is not connected. |
|
|
Yes, I am aware of the sad situation with message errors that do not contain a body. I've actually just started a thread about this problem, in the hope to fix the respective standards. Feel free to chime in there :) |
When delivery of a message fails, this is not visible to the user. However, it would be much better to have an indication that the message was not delivered.
This indication should NOT be displayed if a Receipt has been received for that message already, and it should be reset if a Receipt arrives after the fact.
This is how it looks in yaxim:
P.S: you can test the behavior by sending messages to xmpp:reject@yax.im