[Standards] Proposed XMPP Extension: Compatibility Fallbacks

Dave Cridland dave at cridland.net
Sat Jan 8 22:34:35 UTC 2022

On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer <jonas at wielicki.name> wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Compatibility Fallbacks
> Abstract:
> This document defines a way to indicate that a specific part of the
> body only serves as fallback and which specification the fallback is
> for.
> URL: https://xmpp.org/extensions/inbox/compatibility-fallback.html
There seems to have been a flurry of XEPs recently which actively avoid
using any pre-existing designs and their XEPs, and I'm not sure why.

In this case, you've got a pre-existing fallback extension that you *could*
- and indeed *have* - proposed extending in exactly this way without any
problem, but for some reason you've decided to make an entirely new one
instead of continuing that discussion, which just feels a bit odd.

If you want to just edit that one please let me know, but otherwise, it
seems this is trying to do something in the same space but without using
the same XEP. This just feels like it's not really following the spirit of
our process at all, and it has to be considered an overlap since one of the
authors was actively proposing these changes to XEP-0428. What happens if I
update XEP-428 to support these use-cases?

Now, as it happens, my view is broadly unchanged after 18 months - I think
it gets very complicated when different extensions add bits of textual
markup they then need removing under some circumstances, and so I worry
that while this is a desirable UX, it's also a pretty nasty way of getting
there. The example given has parallel fallback "trims" for markup and
reply, and a client supporting both feature would have to know which to
apply and in what order. However, if a client knows that a quoted section
should be trimmed for replies, then the fallback trim information is
superfluous. It surely must know to remove the markup with markup. I can be
persuaded I'm wrong, mind, or simply that the consensus is we should have
this part of the protocol - but this is the conversation we were having 18
months ago, and I never got a reply.

Having a "for" attribute listing the feature that the fallback is for seems
fine to me, though I kind of think it might be superfluous. But as I said
18 months ago, it doesn't do any harm.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220108/2e964170/attachment.html>

More information about the Standards mailing list