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.
<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. <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. > 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". 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. 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). Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
