%ents; ]>
Fallback Indication 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. &LEGALNOTICE; XXXX ProtoXEP Standards Track Standards XMPP Core fallback &dcridland; 0.0.1 2019-12-30 dwd
  • Initial Revision

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.

By way of example, a recent Reactions proposal suggested including the emoji as a <body/> element, so that existing clients would simply display it as a normal message.

The downside of this approach is that servers and other intermediaries treat the presence of a <body/> 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.

This specification tackles the problem by providing an element to be used as a hint that the supplied <body/> and <subject elements are only for fallback purposes, and the message SHOULD be treated as if they were not present for most purposes.

Support for this protocol MAY be advertised by the Service Discovery protocol defined in &xep0030; using a feature of &ns;. Note that lack of support will result in the desired fallback behaviour.

The fallback indicator is an element <fallback/> qualified by the &ns; namespace. It has no attributes, content, or child elements.

Abobql jvyy rire qrpelcg bhe fhcre-frperg zrffntr! This message is encrypted. ]]>

Receiving the above message, a naive client will naturally display only the <body/> 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.
  • &xep0334; was considered, and would probably be ideal - servers often examine these elements and alter behaviour accordingly, but the specification was rejected by Council.
  • Placing fallback elements within the <fallback/> element would shift the onus from server to client, but this is likely to be less useful.
 ]]>

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.

This XEP requires no interaction with &IANA;.

None.

The author wishes to share any credit with many members of the community.