diff --git a/xep-0428.xml b/xep-0428.xml index 3802a5d4..81cabb31 100644 --- a/xep-0428.xml +++ b/xep-0428.xml @@ -8,13 +8,14 @@
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. + This specification proposes a mechanism by which message bodies or parts thereof can be marked as being for fallback + purposes, and therefore to be ignored by anything that understands the original intent of the message. &LEGALNOTICE; 0428 - Deferred + Experimental Standards Track Standards + Council XMPP Core @@ -23,6 +24,19 @@ fallback &dcridland; &larma; + + 0.2.0 + 2022-07-17 + lmw + +
    +
  • Add 'for' attribute such that entities can discover what the fallback is for.
    • +
  • Allow to specify that only one of &SUBJECT; or &BODY; is meant as a fallback.
    • +
  • Allow to specify the part of respective text that is meant as fallback where applicable.
    • +
  • Don't use encryption example, which should use XEP-0380 instead.
    • +
+ + 0.1.1 2020-03-03 @@ -48,17 +62,20 @@
-

A common and convenient practise for new extensions is to supply a fallback body. This provides immediate backwards +

A common and convenient practise for new extensions is to supply a fallback in the 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.

+ 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.

+ as being an indicator that a message is indeed an instant message. They may errornously treat a message this way + for archival purposes, etc, that only has a <body/> for fallback purposes, which might not be appropriate.

+

This specification tackles the problem by providing an element to be used as a hint that parts or all of the supplied + <body/> and <subject/> elements are for fallback purposes, and the message may be treated as + if they were not present if the processing entity understands what the message is a fallback for.

+

Additionally, the specification allows for transporting information about which parts of a <body/> are used + for fallback purposes and for which reason, such that supporting clients can hide or dim those parts when displaying them + to the user or otherwise treat those parts special as intended or encouraged by other specifications.

 @@ -67,25 +84,41 @@ 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.

+

The fallback indicator is an element <fallback/> qualified by the &ns; namespace. It has an attribute + for that indicates the specification that the fallback is meant to replace. This is typically the primary namespace + of the respective specification, but may be specified otherwise. The <fallback/> element may have one or multiple + <body/> or <subject/> child elements, that indicate the part of the message, that is a fallback. Both + of these child elements may have a start and end attribute which point to the start and end of a fallback + character sequence as defined in &xep0426; in the respective element in the message. If start and end + attribute are not supplied, the whole respective message element should be assumed to be there for fallback purposes. If + the <fallback/> element does not have any childs, it is assumed to apply to every message <body/> and + <subject/> present in the message.

+

A previous version of this specification had an example using an encrypted message. It is suggested to use &xep0380; + instead of this specification for that usecase.

- - Abobql jvyy rire qrpelcg bhe fhcre-frperg zrffntr! - This message is encrypted. + + + > Anna wrote: + > Hi, how are you? + Great + + + + + ]]> -

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.

+

Receiving the above message, a naive client will naturally display the full <body/> element text, but + a client which supports this specification and the specification for urn:xmpp:reply:0 will know that a part of the + message is merely a fallback placeholder, and to ignore (and not display) that part, if it has other ways to convey the + intended meaning.
    -
  • &xep0334; was considered, and would probably be ideal - servers often examine these elements and alter - behaviour accordingly, but the specification was rejected by Council.
    • +
  • &xep0334; was considered to inform intermediaries, 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.
    • + client, but this is likely to be less useful.
@@ -94,10 +127,20 @@ - + - + + + + + + + + + + + ]]>