mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-24 16:48:52 -05:00
Merge branch 'feature/protoxep-fallback'
This commit is contained in:
commit
5ca03340b4
111
inbox/fallback.xml
Normal file
111
inbox/fallback.xml
Normal file
@ -0,0 +1,111 @@
|
||||
<?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>XXXX</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>fallback</shortname>
|
||||
&dcridland;
|
||||
<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>
|
Loading…
Reference in New Issue
Block a user