moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Add ProtoXEP: Compatibility fallback

Browse Source
This commit is contained in:
Marvin W 2022-01-01 17:47:08 +01:00
parent 7c43e4aaa8
commit 7f99862d20
No known key found for this signature in database
GPG Key ID: 072E9235DB996F2A
1 changed files with 134 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

134
inbox/compatibility-fallback.xml Normal file
View File

@ -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 &lt;fallback&gt; element in the urn:xmpp:compat:0
namespace is placed in the message stanza. The &lt;fallback&gt; element has a 'for' attribute with an identifier
of the specification the fallback is for. The &lt;fallback&gt; element contains one &lt;body&gt; 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 &lt;fallback&gt; 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 &lt;reply&gt; 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 &REGISTRAR;.</p>
</section1>
</xep>