Sorry, I completely missed this for some reason. On Thu, 19 Nov 2020 at 15:30, Marvin W <x...@larma.de> wrote:
> 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. > > We don't, in XMPP, have critical extensions, like LDAP (Or X.400/X.500 in general). I think that's OK - if an entity sends a stanza that the recipient cannot understand at all, that is nevertheless critical, then something has gone wrong in service discovery. But for the rest, yes. Do we want the fallback element to have "the XMLNS of the extension", or does it make more sense to have the feature "var" that would be used in Disco? (I lean toward the latter). > > * 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). > > OK, I think you're persuading me here. I think we may need to revisit hints for the server-side though. > 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). > > Yes, '380 works if you understand encryption (or at least the concept), but not this instance of it. I like the notion of "this is a degraded version of the extended message" versus "this wasn't really a message at all, this message explains why". The latter feels like a case of failed feature negotiation, though. > > 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. > > Yup, that all makes sense. > > 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. Well, now, that's an entirely new can of worms. There's been some confusion over whether lower-cased "should" counts as RFC 2119. A handful of people in the IETF thought it did, or at least might, and so there was another BCP created to say that only upper-cased SHOULD counts. The XSF hasn't been able to adopt this because it is thought by some that existing XEPs might use a lower-cased "should" in the sense of RFC 2119's SHOULD. The RFC 2119 reference is part of our generalised boilerplate, so we have to switch wholesale, which means isolating each instance of a case-insensitive RFC 2119 keyword and "fixing" it first. Maybe just use phrases like "The intent is that a client will blah", and "A client ought not to foo"? Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
