[Standards] Business rules of Last Message Correction
georg at op-co.de
Mon Jun 11 14:33:54 UTC 2018
* Sam Whited <sam at samwhited.com> [2018-06-11 16:20]:
> I'm also not sure that one would be necessary, if we can get away with
> no new protocol or namespaces I'd be very happy.
Which is exactly why I asked the (non-rhetorical, seriously intended)
question I asked further above in this thread, which nobody seems to
have answered yet.
As I see it, the *worst* thing that will happen if we allow
Last-Message-Correction to affect also the last-but-N messages, is:
Clients which implement the LMC spec strictly will display the update as
a new message, instead of as a correction of the old one.
Also, now might be the right moment in time to remind everybody that
relying on a single client's advertised features when sending messages
to the user of that client has a bunch of inherent problems, which is
why I've spoken out against resource-binding in the past. The specific
- Carbons and MAM-archived messages are delivered to other clients which
you potentially haven't checked the disco#info of
- Race conditions between you sending and the client going offline /
changing availability might get that message re-routed
- In a MUC, do you send according to the sub-set or the super-set of all
joined users' features? What happens if you can't even discover their
features because they are hidden by MSN weirdness?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards