[Standards] Proposed XMPP Extension: Fallback Indication

Marvin W xmpp at larma.de
Tue Dec 31 15:42:49 UTC 2019


On 12/31/19 1:54 PM, Dave Cridland wrote:
> I don't think Fallback is any different to no-store, for example.

IMO the XEP-0334 <no-store/> hint is better than the proposed
<fallback/> indication. This is mostly because for the <no-store/> hint
I have a way better understanding of what it should cause the server to
do (mostly because of it's name) and with <fallback/> that's not
immediately obvious.

Also in your example 1, you put a <fallback/> on an encrypted message.
While that message indeed has a fallback body, it should for some
purposes behave as if it had a real body, because after decrypting it
effectively will have a real body for the client. So typically such
message should not have a <no(-permanent)-store/> hint.

On 12/31/19 8:07 AM, Jonas Schäfer wrote:
> In addition, the Fallback Indicator is much more semantic than
> anything Hints had, and thus allows a Processing Entity to do policy
> decisions on how to handle such content much easier.

I think relying on a server policy for decisions how to handle a message
is worse than hint provided from the client (as provided through
XEP-0334). This is mostly because it implies that servers may be
required to update more frequently to support new message contents,
which could otherwise just mandate the usage of processing hints.

Of course adding semantic information doesn't hurt, but it most probably
won't be able to act as an replacement for processing hints from the client.

Can someone link me to where council decided to reject/not continue the
process of XEP-0334, so I can read the reasoning? Seems like I
completely missed that.

Marvin


More information about the Standards mailing list