From f31ed35c8e74a1b8856b0b5b9bc7246206a44632 Mon Sep 17 00:00:00 2001 From: Dave Cridland Date: Mon, 30 Dec 2019 13:11:47 +0000 Subject: [PATCH] ProtoXEP: Fallback Indicator --- inbox/fallback.xml | 111 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 inbox/fallback.xml diff --git a/inbox/fallback.xml b/inbox/fallback.xml new file mode 100644 index 00000000..c2cb6e61 --- /dev/null +++ b/inbox/fallback.xml @@ -0,0 +1,111 @@ + + +%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.

+ + +