Hi, recently I started noticing bounces for CSNs (XEP-0085) sent to an offiline (ejabberd) user. This behavior corresponds to XEP-0160, ยง2.3:
> Recipient's server determines that if the server can store offline > messages on behalf of the intended recipient; if not (e.g., because > the recipient's offline message queue is full), the server returns a > <service-unavailable/> error to the sender. The user experience in at least the client I'm using (poezio) is very disturbing, as the message log is flooded with error bounces that are unrelated to the actual messages I send: 10:34:05 [email protected]: 503 - cancel: User session not found 10:34:08 [email protected]: 503 - cancel: User session not found 10:34:09 [email protected]: 503 - cancel: User session not found 10:34:09 Ge0rG> test 10:34:14 [email protected]: 503 - cancel: User session not found The obvious long-term solution will be to change CSNs from being <message> to directed <presence>. However, that will take some years, and I'm interested in a principal solution of what to do with ephemeral messages. The problem at hand, CSN bounces, has a number of possible solutions: 1. Tracking of CSNs in the sending clients and suppressing display of the bounces. That requires additional logic and (potentially persistent) tracking of ephemeral message IDs, or some other ugly hacks like encoding the ephemerality into the ID, and it doesn't work over multiple clients. 2. Mandating that the bounce MUST contain the original bounced message (this is optional as per the RFC), so that the client can suppress the error in a state-less way. That will also work better if the original CSN is not carbon-copied to the sender's other devices, but the error is(*). 3. Receiving server silently drops unimporant/ephemeral messages instead of bouncing them. This would make the client less complex (at the cost of the server, which fits the original design of XMPP), and reduce the overall network load. Jonas has pointed out that certain kinds of ephemeral messages definitively need to be bounced, e.g. OTR payloads. We already have the "ephemerality" debate in the context of MAM / offline storage, where we don't have a clear set of rules yet. So we should also move forward with defining what's ephemeral (bounce silently) and what's semi-ephemeral (don't store but bounce). Georg (*) I'd really like to mandate carbon-copying of message errors, but this is up to a separate standards@ thread; the relevant part here is that a bounce obviously inherits the ephemerality property of the bounced message. -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
