On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer <jo...@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. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
