[Standards] Council Minutes 2020-11-18

Tedd Sterr teddsterr at outlook.com
Sat Nov 21 19:09:51 UTC 2020


https://logs.xmpp.org/council/2020-11-18?p=h#2020-11-18-b43c59f0d77acd68

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

2) Agenda Bashing
None.

3) Editor's Update
* Editors have been very busy.

4a) Proposed XMPP Extension: File metadata element - https://xmpp.org/extensions/inbox/file-metadata.html
Dave thinks this already had some on-list discussion, others seem to have missed that; at least, Dave thought it looked familiar and so assumed he'd seen it before - Zash demands a reference to this clandestine discussion.
It appears to Georg that this is copying the 'file' element from XEP-0234 (Jingle File Transfer) for the sake of copying the 'file' element from XEP-0234 - wonders whether he's missing something - Jonas believes the idea is to separate it out for use in other XEPs, without necessarily being bound to the 0234 namespace.

Dave: +1 (seems fine)
Daniel: +1
Jonas: +1 (have remarks, but will suggest those to authors on-list [1])
Zash: +1
Georg: +1 (given that 0234 is deferred, it's worth a try)

Zash isn't entirely convinced that another XEP really fixes anything - Georg doesn't disagree, but thinks that smaller, reusable elements in their own XEPs are a good idea - Zash doesn't disagree.
Georg questions what will happen if this is ever given the forbidden namespace bump - will clients have to send two 'file' elements with different namespaces? - Daniel doesn't think the idea is to make it resilient against bumps, but to better use it outside of Jingle; Georg assumes making it reusable will make it prone to bumping.

4b) Proposed XMPP Extension: Stateless file sharing - https://xmpp.org/extensions/inbox/sfs.html
Zash wonders whether this was made in preference to re-authoring SIMS (XEP-0385). Dave thinks this is basically SIMs but based around the file metadata instead. Georg suggests allowing Marvin, the author, to co-author SIMS and make the fixes in there - Dave also considered this. Daniel questions whether there has been a clear consensus on the need for such a re-factor of SIMS, as SIMS might still be useful for other things - Dave is unsure; Jonas questions whether such a consensus is needed before accepting this as Experimental. Zash suggests throwing SIMS and SFS into the arena and letting them fight to earn their place upon the throne of OOB.
Georg imagines a post-apocalyptic future where clients send multiple different 'file-attached' elements for compatibility reasons, even though each client supports the same set of mechanisms; Dave is impressed by the optimism of expecting that any two clients will ever have any file-transfer mechanisms in common.
Daniel expects that, with the body fallback, it should be relatively safe to drop OOB at some point; Dave hates body fallback [nobody mention XEP-0428.] Zash suggests everything will be okay with Fallback Indication (XEP-0428), though it is lacking a fallback for itself.

Daniel: +1
Zash: +1
Jonas: +1
Dave: +1 (don't object)
Georg: [on-list]

4c) Proposed XMPP Extension: Encryption for stateless file sharing - https://xmpp.org/extensions/inbox/esfs.html
Dave thinks this has issues, but nothing insurmountable, so publish then fix (hopefully).
Georg likes the extensive Security Considerations.

Jonas: +1 (feedback on-list [2])
Daniel: +1
Zash: +1
Dave: +1 (unclear if every cipher suite will have/need separate key and IV)
Georg: [on-list]

4d) Proposed XMPP Extension: Stickers - https://xmpp.org/extensions/inbox/stickers.html
Jonas thinks the hash calculation looks very reminiscent of XEP-0390 (Entity Capabilities 2.0); suggests the author, Marvin, might consider replacing ASCII separators (invalid in XML 1.0, but valid in 1.1) with NUL (invalid in both) - Marvin would rather enforce that name, desc, and summary should be displayable to end-users and not include ASCII separators - Jonas thinks doing both would be provide low-cost additional resilience.
Dave admits to possibly being too old to understand what a 'sticker' is - Georg suggests "something like a large custom emoji" - Dave asks why they hunt in packs.
Daniel wonders whether stickers might be better suited to SIMS rather than file-sharing (unsure how stickers work/are used).

Georg: [on-list] (need to think about the technical implications and copyright violation issues)
Jonas: [on-list]
Dave: [on-list]
Daniel: +1
Zash: +1

5) Pending Votes
Dave votes +0 on "Advance XEP-0443 (XMPP Compliance Suites 2021)".
Georg votes +1 on "PR #1001 (XEP-0393: clarify rules for span directives)"; everyone else is slacking.

Jonas pushes everyone to cast remaining votes on the list.

6) Date of Next
To be decided by the incoming Council.

7) AOB
Georg suggests advancing XEP-0423 (XMPP Compliance Suites 2020) to Final, as it's now officially over a year old; hopes it might yield useful input for CS-2021 - Jonas is unsure how a CFE would work across council terms.
Zash considers asking Board to add a special Compliance Suite Thing into XEP-0001.

8) Close
Jonas takes the opportunity to thank everyone for their efforts this council term, "it was a pleasure working with you all." And special thanks (with cookies) to Tedd for consistent, enjoyable, comprehensive meeting minutes.
Dave thanks Jonas for his excellent and conscientious chairing. Georg thanks Jonas very much as well. Zash thanks everyone, "it's been a pleasure serving with you."

While Dave hates to lose elections, if beaten, he is confident that it will be by good people.


[1] https://mail.jabber.org/pipermail/standards/2020-November/037912.html
[2] https://mail.jabber.org/pipermail/standards/2020-November/037913.html

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


More information about the Standards mailing list