[Standards] Council Minutes 2020-04-15
dave at cridland.net
Thu Apr 23 09:16:41 UTC 2020
On Wed, 22 Apr 2020 at 15:46, Tedd Sterr <teddsterr at outlook.com> wrote:
> *1) Roll Call*
> Present: Daniel, Jonas, Zash, Georg
> Apologies: Dave
> *2) Agenda Bashing*
> No additions.
> *3) Editor's Report*
> * Expired calls: None
> * Calls in progress:
> - LC for XEP-0357 (Push notifications) ends at 2020-04-15
> * New ProtoXEP: Room Activity Indicators
> *4a) Proposed XMPP Extension: Room Activity Indicators* -
> Daniel: [on-list]
> Jonas: [on-list]
> Georg: [on-list]
> Zash: [on-list]
> Dave: [pending]
Oh, gosh, I never saw this one come in, so sorry.
Three main comments here:
* This is very much reinventing a publish subscribe pattern without
* The XML syntax feels inherently dead-endy, and mis-structured. I'd go for
one element per MUC, with the jid in an attribute. A container element
really only saves on the XMLNS declaration; I'm ambivalent there.
* The XML namespace is not under XSF control.
Of these, the last is blocking for me; we have run into problems when
non-XSF namespaces have been baked into XEPs before, and I'd rather not
repeat that. Should be trivial to fix though, and my other two points can
be argued through Experimental.
> *4b) PR #924 - XEP-0191: Change service discovery flow to use account
> instead of server* - https://github.com/xsf/xeps/pull/924
> Jonas expects some controversy on this, as do Zash and Georg.
> Kev notes that it's usual to send disco queries to the server's JID to
> find out what's supported for your current session - Jonas would like to
> gradually change that. Kev doesn't think the status quo prohibits the right
> results from being returned to the right entities, and so the motivation
> given doesn't necessarily lead to this patch (though other motivations
> may.) Zash likes the general pattern of disco#info going to the same JID as
> for the rest of the protocol. As a puritan, Jonas believes that disco#info
> for an entity should look the same, no matter who is asking (subject to
> Daniel is not entirely on board with changing draft XEPs, but agrees this
> PR is 'more correct.'
> Given that many other XEPs advertise on the server JID, Kev doesn't think
> changing one XEP in isolation is the right thing to do here, without wider
> Jonas thinks this should be taken to the list for feedback from the wider
> community, and thus cancels this vote.
> *4c) Advance XEP-0357 (Push Notifications)* -
> Daniel: -1 (unaddressed feedback)
> Jonas: -1 (arguments against this using PubSub syntax, making it
> unnecessarily hard to understand, are sound)
> Georg: [pending]
> Zash: [pending]
> Dave: [pending]
> Jonas asks whether anyone is taking ownership of this XEP, specifically
> Kev or Lance (as authors) - Lance wanted another author listed so he could
> retire from this, and Kev volunteered expecting to spend time working on
> it, but hasn't touched it since.
> Daniel thinks it wouldn't be a bad idea to just start from scratch, not
> that he's volunteering, but it would make the ownership question
> Jonas thinks it would be good to get someone already involved with
> implementations around this to do the work, primarily mobile client/server
> developers. Zash shirks any responsibility, having not touched this for
> years. Kev is very short of cycles at the moment. Jonas thinks input from
> Xabber would also be good.
> Daniel mentions that Tigase introduced something at the Summit, so they
> might be encouraged to write that down in XEP form - Jonas asks Daniel to
> contact them to see if they will, or call for volunteers on the list if
> they won't - Daniel accepts.
I'm a +1 on this, I think. Happy to wait for Daniel to block on feedback
though, of course.
I would note that in our case, we stopped using XEP-0357 for pushes some
time ago and increasingly deviate - for us it's now part of account
registration rather than per-session startup - but for open network use
this is the best we have currently, and it seems well-implemented. It is a
bit complex, true, and I'm sure that someone could come up with something
better, but the enemy of the good plan is the dream of the perfect, etc.
It feels inherently more sensible to say "This is the best we have now",
and later deprecate, than to say "We do not have any solution here" despite
plenty of deployment of '357.
> *5) Pending Votes*
> All votes are up to date.
> Dave made valid points about PR #913, and Jonas is going to fix that up
> and re-propose it.
> *6) Date of Next*
> 2020-04-22 1500 UTC
> *7) AOB*
> Daniel remembers what he wanted to do last week: ask Editor to Last Call
> XEP-0320 (Use of DTLS-SRTP in Jingle Sessions) and XEP-0339
> (Source-Specific Media Attributes in Jingle) - thinks they will be
> uncontroversial, as it's just metadata annotations.
> Jonas adds them to the agenda for next week.
> *8) Close*
> Thanks everyone.
> Thanks all.
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards