[Standards] Council Minutes 2020-08-26

Tedd Sterr teddsterr at outlook.com
Mon Aug 31 22:09:31 UTC 2020


1) Roll Call
Present: Georg, Daniel, Jonas, Zash, Dave

2) Agenda Bashing

3) Editor's Update
* Ended LCs:
  - XEP-0352 (Client State Indication) ended on 2020-08-18
  - XEP-0411 (Bookmarks Conversion) ended on 2020-08-18

(Those LCs were missing from the Editor's update because of a mistake when using the LC tooling. The editors are now aware of the problem.)

4a) Advance XEP-0352 (Client State Indication) - https://xmpp.org/extensions/xep-0352.html
Jonas thinks the feedback was mostly positive; Georg and Zash think the feedback was a bit thin. Dave felt there was 'enough' feedback.
Georg would like to see the 'tribal knowledge' on this codified, but not at the cost of delaying the XEP; Jonas agrees with Zash, that the tribal knowledge should in an Informational document, rather than a Standards Track one. The author, MattJ, is in favour of the tribal knowledge going into a different document (and somebody should do that.) Georg likes that Informational XEPs aren't set in stone, so they can be a living-document of what's known to be good and bad.

Jonas: +1
Zash: +1
Dave: +1
Daniel: +1
Georg: +1

4b) Advance XEP-0411 (Bookmarks Conversion) - https://xmpp.org/extensions/xep-0411.html
The author, Daniel, would rather just deprecate this, or at least ignore it for a while - since XEP-0402 (Bookmarks 2) replaces the conversion mechanism.
Zash notes that it does exist in the wild - Jonas suggests pushing it to Draft and then Deprecating soon after, in favour of 0402. Daniel doesn't necessarily want to 'send a message' by deprecating it, but also doesn't want to send the opposite message by advancing it - it does its job in the wild right now, but has no future as a standard.
Jonas suggests requesting community feedback, noting the move to Draft and then Deprecation as Council's default position; Jonas feels that some in the community haven't been entirely happy with Council's apparent 'sending a message' without fully taking feedback into account.
Zash suggests extending the LC and poking implementations for more feedback. Daniel suggests extending the LC while noting that, even if Drafted, it will probably be Deprecated in the not too distant future - all are loosely in favour.

5) Pending Votes
Daniel is still on-list on PR #975, which expires next week.

6) Date of Next
2020-09-02 1500 UTC

Daniel probably won't make it.
Jonas will disappear at exactly 1530 UTC.

Jonas looks for an understudy, as he will be on vacation on the 9th and moving on the 16th of September, and won't have time to make a proper agenda either. Dave might not be around on the 9th. Daniel is also moving and will have limited availability for the next few weeks. Georg will be on a computer detox in the next few weeks, but isn't sure when. Dave asks whether everyone is moving - as he is also planning to at some point; Georg is renovating, not moving. Dave suggests Zash is now obligated to move - Zash is quite comfortable in his igloo.
Jonas postpones this discussion and hopes to find a solution next week.

7) AOB
On one of his rare voyages to the supermarket, Georg noticed there were Hallowe'en ornaments on sale [already?!], which reminded him of the horrors of preparing the Compliance Suites - so obviously it's time to start thinking about CS-2021.
Daniel wonders whether it's worth just bumping the year if there wouldn't be any other changes. Dave wonders whether any implementation has even claimed compliance with 2020 (if not, is it worth bothering?)
Georg notes the repeated discussions of whether their current format is appropriate for their objectives - wonders whether it makes sense to continue with the current form, or if anybody has a suggestion to reduce the author's workload. Daniel thinks that improving the format will be a lot of work and even more bike-shedding. Zash thinks it's worth having snapshots of "what implementations do today" and a separate "what we want to do in the future."
Daniel suggests updating, changing little, and introducing a new category for A/V calls (which he will be happy to create) - everyone likes that idea.
Zash wonders why the Compliance Suites aren't Informational anyway - Jonas notes that, oddly enough, XEP-0001 explicitly lists CS as being Standards Track [1].

8) Close
Thanks everyone. Stay safe. Beware of the compliance badgers.

[1] https://xmpp.org/extensions/xep-0001.html#types-Standards-Track

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

More information about the Standards mailing list