[Standards] Proposed XMPP Extension: Fallback Indication

Georg Lukas georg at op-co.de
Wed Jan 8 14:37:55 UTC 2020

* Jonas Schäfer <jonas at wielicki.name> [2019-12-30 14:29]:
> This specification proposes a mechanism by which message bodies can be
> marked as being purely for fallback purposes, and therefore to be
> ignored by intermediaries and anything that understands the remainder
> of the message.

I'm very much split on this one.

On the first look, it seems like a sensible addition to let clients and
servers know that they can safely ignore the body.

However, I'm very unconvinced that this will allow to draw useful
conclusions in the anticipated use cases.

In my eyes, the Right Way is to define in each XEP (which makes use of
legacy bodies) how those bodies are meant and that they are actually to
be ignored by implementations that can process the respective "real"

For Reactions (the most controversial case of fallback bodies in recent
history), Fallback Indication in my eyes means:

- a server that understands Reactions will persist them in MAM (or do a
  Reactions collation of some sorts), regardless of <fallback>

- a client that understands Reactions will ignore the body anyway,
  regardless of <fallback>

- a server that doesn't understand Reactions still needs some other
  thing to decide whether to persist them or not. The <fallback> "hint"
  is not sufficient on its own. Just ignoring the body would probably
  mean loss of information, so we also need a <store> hint.

- a client that doesn't understand Reactions still has no actionable way
  to react to the "hint". Obviously it is supposed to display the
  fallback body, but some people contest that for Reactions
  specifically. Having a client-global trigger for showing fallback
  bodies isn't good either because it will also affect other things,
  like MUC invitations. Having a per-namespace trigger isn't possible
  because <fallback> doesn't tell us for which specific payload this is
  a fallback.

The only actual use case for Fallback Indication that I can see is
retrofitting this for things that do make use of a fallback <body>, but
where the XEP doesn't contain a clear statement that the body is always
a fallback and must be ignored. For example in XEP-0045 §7.8.2 Mediated
Invitation, no fallback body is included, but most implementations will
add one anyway, and the clients I've seen will ignore the message body
if an invitation is contained in the same message.

That said, I don't consider this as harmful, at least if we can agree on
having an implementation note telling servers not to use this as an
equivalent to the message not having a body at all (especially because
some earlier XEPs introduced fallback bodies for the specific reason of
circumventing server heuristics and getting messages persisted).

|| 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 ||_________________________________________________||
-------------- 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/20200108/5e38b2d6/attachment-0001.sig>

More information about the Standards mailing list