On Sun, 9 Jan 2022 at 10:58, Marvin W <x...@larma.de> wrote:
> Hi,
>
> On 08.01.22 23:34, Dave Cridland wrote:
> > In this case, you've got a pre-existing fallback extension that you
> > *could* - and indeed *have* - proposed extending in exactly this way
> > without any problem, but for some reason you've decided to make an
> > entirely new one instead of continuing that discussion, which just feels
> > a bit odd.
> >
> > If you want to just edit that one please let me know, but otherwise, it
> > seems this is trying to do something in the same space but without using
> > the same XEP. This just feels like it's not really following the spirit
> > of our process at all, and it has to be considered an overlap since one
> > of the authors was actively proposing these changes to XEP-0428. What
> > happens if I update XEP-428 to support these use-cases?
> Beside "fallback" in the name, there is really no overlap in
> functionality of this ProtoXEP and XEP-0428. This is also explained in
> the ProtoXEP itself.
>
>
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?
> <fallback/> as described in XEP-0428 is basically similar to a
> <no-store/> hint of XEP-0334 (which is hinted to in the XEP itself and
> also was explained by you on list) as such that it instructs
> intermediaries (servers) to handle the message as if there was no body.
> Clients have little use of this specification as they should only ignore
> the body if they understand what the message in question is actually
> supposed to transmit and thus will always know if they should ignore the
> body or not.
>
>
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.
But yes, also the rejection of XEP-0334 does cause servers some problems,
so '428 fills that gap too. Arguably it shouldn't (or at least, not
always), but the loss of XEP-0334 was rather fresh in my mind, so as
written it is indeed equivalent to <no-store/>.
> <fallback/> as described in the ProtoXEP in contrast is purely client
> side and only applies to a part of the body, never the full body.
> Intermediaries should not interpret it and if Stanza Content Encryption
> (XEP-0420) is used, this <fallback/> element should be part of the
> encrypted payload and not outside, so that intermediaries are not even
> capable of interpreting it.
>
> Of course you can update XEP-0428 to divert from its current intended
> meaning. Or you just add new features to XEP-0428. If you feel that is
> more sensible, I'm open for that as well. It's not like it really
> matters in which XEP number this new client-side feature ends up, as
> long as it does end up in a XEP.
>
>
As I said, my concern is that updating '428 isn't the first choice here.
(See also, updating XEP-0353 and reusing any of the prior art at all in
replies). This feels like Not Invented Here.
> > Now, as it happens, my view is broadly unchanged after 18 months - I
> > think it gets very complicated when different extensions add bits of
> > textual markup they then need removing under some circumstances, and so
> > I worry that while this is a desirable UX, it's also a pretty nasty way
> > of getting there. The example given has parallel fallback "trims" for
> > markup and reply, and a client supporting both feature would have to
> > know which to apply and in what order. However, if a client knows that a
> > quoted section should be trimmed for replies, then the fallback trim
> > information is superfluous. It surely must know to remove the markup
> > with markup. I can be persuaded I'm wrong, mind, or simply that the
> > consensus is we should have this part of the protocol - but this is the
> > conversation we were having 18 months ago, and I never got a reply.
>
> Removing parts of the body under circumstances is exactly the only
> purpose of this ProtoXEP. If we were to remove that feature, the
> ProtoXEP would be entirely useless. I wouldn't know what a client should
> do with the information "Parts of the body are only for fallback
> purposes, but we don't tell you which part".
>
>
The examples you've given are:
1) Markup, where removing the quotation marks radically alters the message
(and the markup is intended not to be intrusive anyway), and
2) Replies, where including a quoted message has security problems all of
their own, as I note elsewhere, and
3) Breaking News, where arguably you'd want to send a different renderable
payload element entirely and if a body element is provided *at all*, it'd
be a pure fallback.
On the other hand, we've prior art like XEP-0308 where the biggest UX
problem is that the users don't understand why they're seeing a message
twice. '428 might help with allowing the users to understand that their
client is missing some important semantics of the message. A "for"
attribute might aid developers to understand what's going on in
more detail. Maybe they'll upgrade (most have once they've understood
what's happened). Body-editing won't help here at all, of course.
Now, I accept that my general view is that fallback bodies are bad; when
writing '428 I did wonder if we'd be better off having the fallback body
text inside the '428 extension entirely, but I think overall that's the
greater of two evils.
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 - but here we
can have endless fun:
<message>
<body>Dave is not a genius</body>
<fallback for='urn:xmpp:call-invites:0'>
<body start='8' end='12'/>
</fallback>
</message>
This example suggests that removing the extraneous data should only happen
both when the client supports the named feature *and* when it knows that
feature should use fallbacks.
<message to='a...@example.com' id='message-id3' type='chat'>
<body>
> Anna wrote:
> We should bake a cake
This is not a great idea!
</body>
<reply to='a...@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>
But it turns out that is not enough either - I can use replies to craft
things differently anyway, so that doesn't work as a general rule. Instead,
I would argue that either you want very specific handling for removing the
fallback text from bodies in replies etc, on a per-extension basis, or else
you don't want to include the fallback text in the first place, and just
indicate to the client that they may not be able to render the message
properly due to semantics they don't understand (see '428).
I know there's a trade-off here, and it's complex. But I cannot think of a
way to ensure that an attacker cannot subvert this to present two different
messages to different parts of the entire system.
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.
This is why, 18 months ago, I said I felt this was going to be too complex
to get right.
We intentionally have a complex example in there, so that developers
> will directly think of them when implementing this. However you are
> wrong in that clients need to know the order in which to process certain
> markup or trimming XEPs, for as long as all of them are a reference to
> characters in the original body, i.e. before any markup or trimming took
> place.
>
>
So your algorithm is to mark all characters in the message that are
discardable by any fallback block and then remove them all at once? OK,
that makes sense.
> Regarding your message from Jan 10, 2020 (which I think is the one you
> are referring to): You were asking if anyone is keen on doing this and
> if anyone knew an alternative. I'm not keen on this, but I don't know
> any sensible alternative (and given there was no reply, apparently
> nobody else is keen or knows an alternative) - so this is why I'm
> pursuing this now, even if this is not a solution which immediately
> rings "that's awesome" in my head, because we need something like this
> and don't have any alternatives. I'd be happy if any sensible
> alternative was provided.
>
> > Having a "for" attribute listing the feature that the fallback is for
> > seems fine to me, though I kind of think it might be superfluous. But as
> > I said 18 months ago, it doesn't do any harm.
>
> Without the "for" attribute, clients will not know if they should remove
> a part or not as they don't know if this is a fallback for a
> specification they implement or a fallback for some part of the message
> they did not understand (if any). As such it's not superfluous in this
> case but strictly needed (opposed to XEP-0428 where it is not a
> requirement as intermediaries do not really mind why they won't store a
> message in persistent storage).
For the record I agree that if you include arbitrary pre-render body text
editing then you do indeed need a "for".
I just don't think you want the arbitrary pre-render body text editing.
Dave.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
