[Standards] Proposed XMPP Extension: Fallback Indication

Dave Cridland dave at cridland.net
Tue Dec 31 12:54:29 UTC 2019


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.


> > So... If Council wants to reject this in favour of
> improving/tidying/accepting hints, I'm absolutely fine with that - but I
> could use a little more input there on what that would look like.
> > Dave.
> > On Mon, 30 Dec 2019 at 13:29, Jonas Schäfer < jonas at wielicki.name
> [mailto:jonas at wielicki.name] > wrote:
> >
> > > The XMPP Extensions Editor has received a proposal for a new XEP.
> > >
> > > Title: Fallback Indication
> > > Abstract:
> > > This specification proposes a mechanism by which message bodies can be
> > > marked as being purely for fallback purposes, and therefore to be
> > > ignored by intermediaries and anything that understands the remainder
> > > of the message.
> > >
> > > URL: https://xmpp.org/extensions/inbox/fallback.html [
> https://xmpp.org/extensions/inbox/fallback.html]
> > >
> > > The Council will decide in the next two weeks whether to accept this
> > > proposal as an official XEP.
> > > _______________________________________________
> > > Standards mailing list
> > > Info: https://mail.jabber.org/mailman/listinfo/standards [
> https://mail.jabber.org/mailman/listinfo/standards]
> > > Unsubscribe: Standards-unsubscribe at xmpp.org [mailto:
> Standards-unsubscribe at xmpp.org]
> > > _______________________________________________
> > >
> >
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191231/8064c5f3/attachment.html>


More information about the Standards mailing list