Hi, 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 inappropriate). 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. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
