mirror of https://github.com/moparisthebest/xeps
Marvin W
1 year ago
1 changed files with 134 additions and 0 deletions
@ -0,0 +1,134 @@
@@ -0,0 +1,134 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?> |
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [ |
||||
<!ENTITY % ents SYSTEM 'xep.ent'> |
||||
%ents; |
||||
]> |
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> |
||||
<xep> |
||||
<header> |
||||
<title>Compatibility Fallbacks</title> |
||||
<abstract> |
||||
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. |
||||
</abstract> |
||||
&LEGALNOTICE; |
||||
<number>xxxx</number> |
||||
<status>ProtoXEP</status> |
||||
<type>Standards Track</type> |
||||
<sig>Standards</sig> |
||||
<dependencies/> |
||||
<supersedes/> |
||||
<supersededby/> |
||||
<shortname>compat</shortname> |
||||
<author> |
||||
<firstname>Natalie</firstname> |
||||
<surname>Wirth</surname> |
||||
<email>nataliew@laposte.net</email> |
||||
</author> |
||||
<author> |
||||
<firstname>Marvin</firstname> |
||||
<surname>Wissfeld</surname> |
||||
<email>xsf@larma.de</email> |
||||
<jid>jabber@larma.de</jid> |
||||
</author> |
||||
<revision> |
||||
<version>0.0.1</version> |
||||
<date>2022-01-01</date> |
||||
<initials>nw/mw</initials> |
||||
<remark> |
||||
<p>First draft.</p> |
||||
</remark> |
||||
</revision> |
||||
</header> |
||||
|
||||
<section1 topic='Introduction' anchor='intro'> |
||||
<p> |
||||
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. |
||||
</p> |
||||
<p> |
||||
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. |
||||
</p> |
||||
</section1> |
||||
|
||||
<section1 topic='Use Cases' anchor='usecases'> |
||||
<p> |
||||
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. |
||||
</p> |
||||
|
||||
<p> |
||||
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. |
||||
</p> |
||||
|
||||
<example><![CDATA[ |
||||
<message to='news@muc.example.com/juliet' id='message-id2' type='chat'> |
||||
<body>BREAKING NEWS: Romeo is dead.</body> |
||||
<breaking xmlns='urn:example:breaking-news:0' /> |
||||
<fallback xmlns='urn:xmpp:compat:0' for='urn:example:breaking-news:0'> |
||||
<body start='0' end='15' /> |
||||
</fallback> |
||||
</message>]]></example> |
||||
|
||||
<p> |
||||
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. |
||||
</p> |
||||
|
||||
<example><![CDATA[ |
||||
<message to='anna@example.com' id='message-id2' type='groupchat'> |
||||
<body> |
||||
> Anna wrote: |
||||
> Hi, how are you? |
||||
Great |
||||
</body> |
||||
<reply to='anna@example.com' id='message-id1' xmlns='urn:xmpp:reply:0' /> |
||||
<markup xmlns="urn:example:markup:0"> |
||||
<quote start='0' end='33' /> |
||||
</markup> |
||||
<fallback xmlns='urn:xmpp:compat:0' for='urn:example:markup:0'> |
||||
<body start='0' end='1' /> |
||||
<body start='14' end='15' /> |
||||
</fallback> |
||||
<fallback xmlns='urn:xmpp:compat:0' for='urn:xmpp:reply:0'> |
||||
<body start='0' end='33' /> |
||||
</fallback> |
||||
</message>]]></example> |
||||
</section1> |
||||
<section1 topic='Business Rules' anchor='rules'> |
||||
<p>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. |
||||
</p> |
||||
</section1> |
||||
|
||||
<section1 topic="Security Considerations" anchor="security"> |
||||
<p> |
||||
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. |
||||
</p> |
||||
</section1> |
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'> |
||||
<p>This document requires no interaction with &IANA;.</p> |
||||
</section1> |
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> |
||||
<p>This document requires no interaction with ®ISTRAR;.</p> |
||||
</section1> |
||||
|
||||
</xep> |
||||
Loading…
Reference in new issue