[Standards] Proposed XMPP Extension: Compatibility Fallbacks

Marvin W xmpp at larma.de
Sun Jan 9 13:37:36 UTC 2022


Hi,

On 09.01.22 13:24, Dave Cridland wrote:
> I'm astonished you can simultaneously argue that XEP-428 should have
> added this functionality *and* the functionality has no overlap. Surely
> it must be one or the other, and not both?

After I proposed this and you argued against, I understood your position
and agreed. I expected you didn't just argue for the sake of arguing,
but actually also argued in your own favor, so this should be in your favor.

> Well, part of the intent was that clients could know that it *was* a
> fallback message, and render it as such, so the user knew that the
> message wasn't being rendered at the sender intended. I know this isn't
> in the XEP, but it was discussed at the time I think.

If this was intended, then again the "for" attribute is not optional
because the client would not know if they should render that they
received a message that isn't rendered as intended or not, if they don't
know if they actually implemented the specification that this body was a
fallback for.

Example 1:

<message from="sender at example.com">
 <propose xmlns='urn:xmpp:jingle-message:0' id="a9d9fa">
  <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
 </propose>
 <unknown xmlns='urn:example:nobody-knows-what-this-is' />
 <body>Unfortunately your client does not support Jingle Message
Initiation. Please click this link to accept my call:
https://call.example.com/accept?id=a9d9fa&jid=sender@example.com</body>
  <fallback xmlns="urn:xmpp:fallback:0"/>
</message>

Example 2:

<message from="sender at example.com">
 <propose xmlns='urn:xmpp:jingle-message:0' id="a9d9fa">
  <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
 </propose>
 <unknown xmlns='urn:example:nobody-knows-what-this-is' />
 <body>Your client does not support the unknown element. Nobody does.</body>
 <fallback xmlns="urn:xmpp:fallback:0"/>
</message>

> As I said, my concern is that updating '428 isn't the first choice here.

Given that (as you know) I originally proposed this for XEP-0428 and you
argued against, I'd say that updating XEP-0428 *was* my first choice,
but it is your right as author to refuse this. Again, if your opinion
changed since, that's fine by me. But your reply also basically says
that you don't want this in XEP-0428.
> 1) Markup, where removing the quotation marks radically alters the
> message (and the markup is intended not to be intrusive anyway), and

Removing the quotation marks does not alter the meaning if the client
understood through other means (markup) that the part of the message is
meant as a quote. We need a way to transition from markdown-style
formatting to something else (as markdown-style formatting is overly
restrictive and at the same time has false positives) and this is a
proposal to do this.

> 2) Replies, where including a quoted message has security problems all
> of their own, as I note elsewhere, and

The current situation is that people do quote messages for replies with
all the "security" problems it has. Again we need a way to transition
from this to something else. As we are in a federated environment, we
can't force upgrade everyone at the same time and users won't use the
new feature if it does not work properly with their friends' clients, so
for this transition we need a fallback. The fallback does not worse
anything for existing users, as they are already using quoted messages
for replies today.
> Still, as written, the ability send a message which is rendered in
> *radically* different ways in different clients just fills me with
> unease. Fallback bodies are nasty like this - it's why I've never been
> happy with the "multipart/alternative" style of XHTML-IM, for example

"multipart/alternative" style as you call it is being used in e-Mail for
centuries. I might also be worth looking at other modern messengers like
Matrix, which transports html and plain text as alternatives
[https://spec.matrix.org/unstable/client-server-api/#mroommessage-msgtypes].

> <message>
>   <body>Dave is not a genius</body>
>   <fallback for='urn:xmpp:call-invites:0'>
>     <body start='8' end='12'/>
>   </fallback>
> </message>

The ProtoXEP clearly states "The exact behavior for a compatibility
fallback should be defined in the respective specification. Not
displaying the fallback in supporting clients would be an example for a
behavior.". As such, in this example, the fallback element would not
result in part of body being stripped, as the specification for
"urn:xmpp:call-invites:0" has no behavior defined for this case.

> <message to='anna at example.com <mailto:anna at example.com>'
> id='message-id3' type='chat'>
>   <body>
>     > Anna wrote:
>     > We should bake a cake
>     This is not a great idea!
>   </body>
>   <reply to='anna at example.com/laptop <http://anna@example.com/laptop>'
> id='message-id1' xmlns='urn:xmpp:reply:0' />
>   <fallback xmlns='urn:xmpp:feature-fallback:0' for='urn:xmpp:reply:0'>
>     <body start="0" end="36" />
>     <body start="43" end="47"/><!-- I probably can't count, but you get
> the idea -->
>   </fallback>
> </message>

Nothing prevents receiving clients or specifications from adding checks
or requirements to the fallback and warn users/moderators if the
fallback seems to be significantly off from what it should. For example,
a valid fallback for replies will typically be a single block in the
body, etc.
But, I also doubt that this is strictly needed, given the experience
with other systems using alternative formats. I agree it makes sense to
think about this, but should really a large amount of users suffer from
us not proceeding the specification process because there are some
things that arguably are not and never will be perfect?

Of course spam prevention and moderation must be prepared to operate on
everything that may be eventually rendered to the user (which is a good
argument to prefer using body instead of new elements for new features)

> And if you think removal of arbitrary words isn't a problem, be assured
> that people will use this to slip spam and abusive messages past
> moderators and scanners.

Of course spam prevention and moderation must be prepared to operate on
everything that may be eventually rendered to the user (which is a good
argument to prefer using body instead of new elements for new features)

> I just don't think you want the arbitrary pre-render body text editing.

And this is probably why it makes sense to have two specifications: one
that does nothing like "arbitrary pre-render body text editing"
(XEP-0428) and one that specifically does it. Nobody forces you to
implement or use this specification you don't like. If it turns out to
be a bad idea, we can get rid of it as easily as we introduced it.

Marvin


More information about the Standards mailing list