On Dienstag, 31. Dezember 2019 13:54:29 CET Dave Cridland wrote: > On Tue, 31 Dec 2019 at 07:08, Jonas Schäfer <jo...@wielicki.name> wrote: > > Comments inline. I'm trying a new MUA, I hope it won't butcher this > > message. > > > > 30 Dec 2019 6:58:51 pm Dave Cridland : > > > Please note Section 2.3 in this document. > > > Having some clear and consistent mechanism for indicating that, when > > > > heuristically deciding if a message is an "Instant Message", systems > > should > > ignore the and would eliminate my arguments against using enthusiastically > > for fallback purposes. So *something* like this is needed unless you're > > all > > happy for me to veto everything that says to insert a fallback. Muahahaha, > > etc, but no, really. > > > > > I would genuinely like to resurrect XEP-0334 for this - if there is > > > > interest there I have some suggestions for reworking it to be a little > > more > > comfortably extensible which, I think, was Sam's main objection alongside > > wanting to keep capabilities like no-copy inside the specifications which > > needed it. The latter argument is weaker for everything other than > > no-copy, > > and indeed I think in cases such as fallback it's literally counter to the > > point. > > > > I think Hints should stay in their grave. > > You know that every server I've looked at recently implements them? If > that's a grave, we have a serious problem with zombies. > > Will XEP-0334 eat my brains? Should I get a shotgun? > > > We addressed the no-copy case with IM-NG hopefully, > > There are no implementations on IM-NG I'm aware of. > > > and I think that a one-purpose spec like your Fallback Indicator has a > > much better chance at reaching Draft or Final than a redo or fix of > > something broader like Hints -- and there is no gain in mixing the > > concerns. > > > > 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 don't think Fallback is any different to no-store, for example.
That’s true. I got confused. I thought that <fallback/> had an attribute in form of a namespace URI which indicated the reason why the message is marked with <fallback/>. You can safely ignore what I wrote in that case. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
