[Standards] Business rules of Last Message Correction

Georg Lukas 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
problems are:

- 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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180611/7f3a6a29/attachment-0001.sig>

More information about the Standards mailing list