[Standards] Proposed XMPP Extension: Compatibility Fallbacks

Marvin W xmpp at larma.de
Sun Jan 9 10:57:06 UTC 2022


Hi,

On 08.01.22 23:34, Dave Cridland wrote:
> 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?
Beside "fallback" in the name, there is really no overlap in
functionality of this ProtoXEP and XEP-0428. This is also explained in
the ProtoXEP itself.

<fallback/> as described in XEP-0428 is basically similar to a
<no-store/> hint of XEP-0334 (which is hinted to in the XEP itself and
also was explained by you on list) as such that it instructs
intermediaries (servers) to handle the message as if there was no body.
Clients have little use of this specification as they should only ignore
the body if they understand what the message in question is actually
supposed to transmit and thus will always know if they should ignore the
body or not.

<fallback/> as described in the ProtoXEP in contrast is purely client
side and only applies to a part of the body, never the full body.
Intermediaries should not interpret it and if Stanza Content Encryption
(XEP-0420) is used, this <fallback/> element should be part of the
encrypted payload and not outside, so that intermediaries are not even
capable of interpreting it.

Of course you can update XEP-0428 to divert from its current intended
meaning. Or you just add new features to XEP-0428. If you feel that is
more sensible, I'm open for that as well. It's not like it really
matters in which XEP number this new client-side feature ends up, as
long as it does end up in a XEP.

> 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.

Removing parts of the body under circumstances is exactly the only
purpose of this ProtoXEP. If we were to remove that feature, the
ProtoXEP would be entirely useless. I wouldn't know what a client should
do with the information "Parts of the body are only for fallback
purposes, but we don't tell you which part".

We intentionally have a complex example in there, so that developers
will directly think of them when implementing this. However you are
wrong in that clients need to know the order in which to process certain
markup or trimming XEPs, for as long as all of them are a reference to
characters in the original body, i.e. before any markup or trimming took
place.

Regarding your message from Jan 10, 2020 (which I think is the one you
are referring to): You were asking if anyone is keen on doing this and
if anyone knew an alternative. I'm not keen on this, but I don't know
any sensible alternative (and given there was no reply, apparently
nobody else is keen or knows an alternative) - so this is why I'm
pursuing this now, even if this is not a solution which immediately
rings "that's awesome" in my head, because we need something like this
and don't have any alternatives. I'd be happy if any sensible
alternative was provided.

> 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.

Without the "for" attribute, clients will not know if they should remove
a part or not as they don't know if this is a fallback for a
specification they implement or a fallback for some part of the message
they did not understand (if any). As such it's not superfluous in this
case but strictly needed (opposed to XEP-0428 where it is not a
requirement as intermediaries do not really mind why they won't store a
message in persistent storage).

Marvin


More information about the Standards mailing list