mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-13 21:05:09 -05:00
135 lines
5.4 KiB
XML
135 lines
5.4 KiB
XML
<?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>
|