xmpp at larma.de
Thu Nov 19 15:30:13 UTC 2020
On 19.11.20 12:04, Dave Cridland wrote:
> * Indicate to clients that if they're just going to display the body
> tag, then they are missing something. There was some suggestion - from
> Georg I think - that it might be useful to include the XMLNS of the
> element that obviates the body.
This would indeed by a useful feature, allowing the client to tell the
users they are displaying the fallback message because they are missing
a feature. I'd argue that this is also possible without the <fallback/>
element, just by noting that there are elements inside the <message/>
not understood by the client, but having it in a dedicated way and
thereby signaling that the receiving client misses "something important"
(and not just lack for support of origin-id, for example) also makes sense.
However, I'd even go further and argue that such feature is independent
of body fallback being used or not. E.g. if there was a new type of
message carrying important information but without a fallback body, I'd
also want the receiving client to display a note, and not only when
there is a body.
> * Indicate to servers that a message isn't a message at all.
And here we totally disagree. A sticker message is a message for all
purposes the server should care. Consider a sticker a "glorified emoji".
Most users would fallback to send the emoji as text instead of a sticker
if the sending client had no sticker support.
Also the fallback is not only a "legacy compatibility fallback", but
also a "technically not possible fallback". For example, when Telegram
receives a sticker it creates a notification with only the "base" emoji,
because notifications on many platforms can't carry images (and/or using
the image feature in notifications for stickers would maybe be
Maybe we should note that there are two types of fallback bodies:
- "Approximating fallbacks": The body contains a text that closely
approximates the intended message, but lacks some features that would
normally be there, e.g. interactivity, inline media, etc. Both stickers
and SFS fall in this category. The general assumption for those is that
it is better to behave as if the message was just a "simple" message
with that body instead of e.g. displaying an error to the user.
- "Incompatibility warning fallback": The body just notifies that
important information is not available because the receiving entity does
not support a certain XEP. An example for this would be encryption XEPs,
(which have XEP-0380 to indicate this).
> I don't really follow the logic around not offering to download the
> sticker. It's a file. I accept that stickers are not normally
> individually downloaded, and there may be copyright issues in taking a
> (further) copy, but in terms of interoperability it doesn't seem to make
> a difference.
What I wanted to express is that in the case of stickers, the sender
would prefer the recipient to see the fallback body (e.g. the emoji
showing the same emotion as the sticker) instead of a download button,
if for some reason the recipient does not support displaying the file
inline. Remember that stickers are typically used as an alternative to
emojis. Even if it's technically a file and no text anymore, it makes no
sense to download the file, just as you don't have a "Save message to
file" option in a typical instant messenger.
> Anyway, I understand what you're trying to do here at a high level, I
> just think it's broadly not going to be useful, and certainly isn't an
> interoperability concern.
I'm happy to change respective wording from uppercase to lowercase to
ensure it's not perceived as an RFC2119 keyword.
More information about the Standards