[Standards] Council Minutes 2020-04-15

Dave Cridland dave at cridland.net
Tue Apr 28 20:14:58 UTC 2020

On Tue, 28 Apr 2020 at 18:28, Georg Lukas <georg at op-co.de> wrote:

> * Tedd Sterr <teddsterr at outlook.com> [2020-04-22 16:46]:
> > https://logs.xmpp.org/council/2020-04-15?p=h#2020-04-15-515165c7293c9539
> >
> > 4a) Proposed XMPP Extension: Room Activity Indicators -
> https://xmpp.org/extensions/inbox/room-activity-indicators.html
> I'm actually very much torn on this. I can understand that you have a
> certain use case in mind, and that your use case probably defines all
> the parameters that are vague in the XEP text. As it stands, I as a
> client developer don't see why or how I should implement this. That
> said, I see multiple practical issues with it:
> It is not quite clear which aspects of this are user (account) specific
> and which are client (full-JID?) specific, and how the MUC service is
> supposed to track individual clients.
> The vague business rules don't provide a hint on whether to expect one
> RAI notification a day or one per second, and what the client is
> supposed to do with it - display an "unread" marker? Auto-join the room?
> Fetch MAM for the room? Something else?
> I hope we can figure out all these during Experimental, so +1
> > 4b) PR #924 - XEP-0191: Change service discovery flow to use account
> instead of server - https://github.com/xsf/xeps/pull/924
> While not strictly a vote, I think that the right approach here would be
> to introduce the new syntax while demanding from servers to support the
> old one, for the next ten years or so.
> > 4c) Advance XEP-0357 (Push Notifications) -
> https://xmpp.org/extensions/xep-0357.html
> -1
> This XEP really needs significant improvement. I agree with Daniel that
> starting from scratch might be the best idea. We might use regular
> message syntax or maybe IQs for the notifications, and we need a better
> introduction into the involved roles and what components this XEP
> addresses. And finally, we need to change the semantics to allow the
> push service to send different kinds of notifications. I think the
> stanza-skeleton approach is a good one to finally implement.

If you want people to start from scratch, is it worth accepting the XEP
onto Draft and then obsoleting it once a replacement is done? I didn't see
any concerns regarding security etc which might be blockers to that

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200428/fad229f0/attachment.html>

More information about the Standards mailing list