[Standards] Proposed XMPP Extension: Fallback Indication

Dave Cridland dave at cridland.net
Fri Jan 10 17:06:41 UTC 2020

On Wed, 8 Jan 2020 at 15:04, Marvin W <xmpp at larma.de> wrote:

> On 1/8/20 3:37 PM, Georg Lukas wrote:
> > Having a per-namespace trigger isn't possible
> > because <fallback> doesn't tell us for which specific payload this is
> > a fallback.
> I also feel that for fallback indication to be useful, namespace of what
> this is a fallback for should be added.
> This would also allows servers to discover (via service discovery) if
> the receiving client does support a protocol and strip out the fallback
> body (and the fallback hint) for clients that do, saving a few bytes on
> the wire. It might be a tiny optimization, but why not?
I'm not convinced, but it does no harm that I can see so OK.

> Another thing is that IMO it should be possible to indicate a begin/end
> of the fallback in the body, if the body only partially contains
> fallback. The example I have in mind is a reply feature, where the
> replied-to message is provided using a <reply-to id="message-id" /> and
> the body contains a quote of the message for fallback compatibility, but
> clients that do understand the <reply-to> probably don't want to display
> that part (and instead just nicely reference the message "message-id"
> somehow). Just an idea, but if we have any indication of a fallback in
> the body, it should cover that use-case.

(See: https://gist.github.com/mar-v-in/8f66872bb533f7e805fb174e341be992)

I think this rapidly becomes very complex, and overall I'd rather that this
idea was done in some other way.

I'd be interested to know whether people would be keen on this, and if
there's an alternative way we could reach the same UX.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200110/7e995104/attachment.html>

More information about the Standards mailing list