diff --git a/inbox/compatibility-fallback.xml b/inbox/compatibility-fallback.xml new file mode 100644 index 00000000..586c8a75 --- /dev/null +++ b/inbox/compatibility-fallback.xml @@ -0,0 +1,134 @@ + + + %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;.

+ + +