[Standards] Proposed XMPP Extension: Fallback Indication
jonas at wielicki.name
Wed Jan 1 00:19:17 UTC 2020
On Dienstag, 31. Dezember 2019 13:54:29 CET Dave Cridland wrote:
> On Tue, 31 Dec 2019 at 07:08, Jonas Schäfer <jonas at 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
You can safely ignore what I wrote in that case.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards