%ents; ]>
Compatibility Fallbacks This document defines a way to indicate that a specific part of the body only serves as fallback and which specification the fallback is for. &LEGALNOTICE; xxxx ProtoXEP Standards Track Standards compat Natalie Wirth nataliew@laposte.net Marvin Wissfeld xsf@larma.de jabber@larma.de 0.0.1 2022-01-01 nw/mw

First draft.

New specifications can use the message body to convey intended meaning to users of non-supporting clients. This XEP provides a way to indicate which part of the body serves as fallback and which specification it provides a fallback for.

This specification serves a different purpose than the similarly named &xep0428;. Fallback indication tells servers that the body is only a fallback and that clients implementing all the specifications used by the message will not make use of the message body. This specification tells clients that parts of the body are only included to aid clients not supporting a certain specification.

To mark a specific text section in the body as a fallback, a <fallback> element in the urn:xmpp:compat:0 namespace is placed in the message stanza. The <fallback> element has a 'for' attribute with an identifier of the specification the fallback is for. The <fallback> element contains one <body> element for each continuous character sequence in the body that is part of the fallback text. Each body element contains a 'start' and 'end' attribute which point to the start and end of a fallback character sequence as defined in &xep0426;, respectively.

For example, Juliet might be part of a group that shares news. Breaking news are indicated by a specific element and supporting clients can highlight them accordingly. To also inform users of non-supporting clients about the importance of a piece of news, the information is prefixed by "BREAKING NEWS: " in the body. A supporting client sees the <fallback> element and removes the respective character sequence before highlighting the message to the user.

BREAKING NEWS: Romeo is dead. ]]>

Another example are message replies, where a <reply> element specifies the referenced message. A simple fallback is to include a &xep0393; quote of the referenced message in the body text. To provide a better fallback, the sender can also include markup information for the quote.

> Anna wrote: > Hi, how are you? Great ]]>

The exact behavior for a compatibility fallback should be defined in the respective specification. Not displaying the fallback in supporting clients would be an example for a behavior.

An attacker might include a compatibility fallback with a meaning that is different from what would be displayed by a supporting client. While this could also be achieved using other parts of the XMPP specifications (e.g. xml:lang), some environments might want to prevent it. Specifications could standardize some parts of the compatibility text such that the equivalence can be verified by supporting clients.

This document requires no interaction with &IANA;.

This document requires no interaction with ®ISTRAR;.