mirror of https://github.com/moparisthebest/xeps
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
123 lines
5.1 KiB
123 lines
5.1 KiB
<?xml version='1.0' encoding='UTF-8'?> |
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [ |
|
<!ENTITY % ents SYSTEM 'xep.ent'> |
|
%ents; |
|
<!ENTITY ns "urn:xmpp:fallback:0"> |
|
]> |
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> |
|
<xep> |
|
<header> |
|
<title>Fallback Indication</title> |
|
<abstract>This specification proposes a mechanism by which message bodies can be marked as being purely for fallback |
|
purposes, and therefore to be ignored by intermediaries and anything that understands the remainder of the message.</abstract> |
|
&LEGALNOTICE; |
|
<number>0428</number> |
|
<status>Deferred</status> |
|
<type>Standards Track</type> |
|
<sig>Standards</sig> |
|
<dependencies> |
|
<spec>XMPP Core</spec> |
|
</dependencies> |
|
<supersedes/> |
|
<supersededby/> |
|
<shortname>fallback</shortname> |
|
&dcridland; |
|
<revision> |
|
<version>0.1.1</version> |
|
<date>2020-03-03</date> |
|
<initials>ps</initials> |
|
<remark>Minor editorial fixes</remark> |
|
</revision> |
|
<revision> |
|
<version>0.1.0</version> |
|
<date>2020-01-28</date> |
|
<initials>XEP Editor (jsc)</initials> |
|
<remark>Accepted by vote of Council on 2020-01-02.</remark> |
|
</revision> |
|
<revision> |
|
<version>0.0.1</version> |
|
<date>2019-12-30</date> |
|
<initials>dwd</initials> |
|
<remark> |
|
<ul> |
|
<li>Initial Revision</li> |
|
</ul> |
|
</remark> |
|
</revision> |
|
</header> |
|
|
|
<section1 topic='Introduction' anchor='intro'> |
|
<p>A common and convenient practise for new extensions is to supply a fallback body. This provides immediate backwards |
|
compatibility for naive clients, since - not understanding the new protocol - they will gracefully degrade to displaying |
|
the body as an instant message.</p> |
|
<p>By way of example, a recent Reactions proposal suggested including the emoji as a <tt><body/></tt> element, so |
|
that existing clients would simply display it as a normal message.</p> |
|
<p>The downside of this approach is that servers and other intermediaries treat the presence of a <tt><body/></tt> |
|
as being an indicator that a message is indeed an instant message. They will then treat it this way for archival |
|
purposes, etc, which might not be appropriate.</p> |
|
<p>This specification tackles the problem by providing an element to be used as a hint that the supplied |
|
<tt><body/></tt> and <tt><subject/></tt> elements are only for fallback purposes, and the message SHOULD be |
|
treated as if they were not present for most purposes.</p> |
|
</section1> |
|
|
|
<section1 topic='Overview' anchor="overview"> |
|
<section2 topic="Discovering Support" anchor="feature"> |
|
<p>Support for this protocol MAY be advertised by the Service Discovery protocol defined in &xep0030; using a feature |
|
of <tt>&ns;</tt>. Note that lack of support will result in the desired fallback behaviour.</p> |
|
</section2> |
|
<section2 topic="Fallback Indicator"> |
|
<p>The fallback indicator is an element <tt><fallback/></tt> qualified by the <tt>&ns;</tt> namespace. It has no |
|
attributes, content, or child elements.</p> |
|
<example><![CDATA[ |
|
<message from="alice@example.org" to="bob@example.net" type="chat"> |
|
<fallback xmlns="]]>&ns;<![CDATA["/> |
|
<encrypted xmlns="urn:example:crypto">Abobql jvyy rire qrpelcg bhe fhcre-frperg zrffntr!</encrypted> |
|
<body>This message is encrypted.</body> |
|
</message> |
|
]]></example> |
|
<p>Receiving the above message, a naive client will naturally display only the <tt><body/></tt> element text, but |
|
a client or server which supports this specification will know this is merely a fallback placeholder, and to ignore |
|
(and not display) the content therein.</p> |
|
</section2> |
|
<section2 topic="Alternatives"> |
|
<ul> |
|
<li>&xep0334; was considered, and would probably be ideal - servers often examine these elements and alter |
|
behaviour accordingly, but the specification was rejected by Council.</li> |
|
<li>Placing fallback elements within the <tt><fallback/></tt> element would shift the onus from server to |
|
client, but this is likely to be less useful.</li> |
|
</ul> |
|
</section2> |
|
</section1> |
|
|
|
<section1 topic="Schema"> |
|
<code> |
|
<![CDATA[ |
|
<?xml version="1.0" encoding="UTF-8"?> |
|
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="]]>&ns;<![CDATA[" xmlns:xs="http://www.w3.org/2001/XMLSchema"> |
|
<xs:element name="fallback"> |
|
<xs:complexType/> |
|
</xs:element> |
|
</xs:schema> |
|
]]> |
|
</code> |
|
</section1> |
|
|
|
<section1 topic='Security Considerations' anchor='security'> |
|
<p>This specification allows messages with a body (and real message content therein) to be treated by a server as |
|
if that body text does not exist. Servers MAY, particularly in a secure setting, wish to archive copies of the message |
|
even if they ordinarily would not archive a message with no body.</p> |
|
</section1> |
|
|
|
<section1 topic='IANA Considerations' anchor='iana'> |
|
<p>This XEP requires no interaction with &IANA;. </p> |
|
</section1> |
|
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> |
|
<p>None.</p> |
|
</section1> |
|
|
|
<section1 topic='Acknowledgements' anchor='ack'> |
|
<p>The author wishes to share any credit with many members of the community.</p> |
|
</section1> |
|
|
|
</xep>
|
|
|