<?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>