[Standards] Council Minutes 2020-04-22

Tedd Sterr teddsterr at outlook.com
Wed Apr 29 14:34:13 UTC 2020


https://logs.xmpp.org/council/2020-04-22?p=h#2020-04-22-8bddd57b73bab8fc

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

2) Agenda Bashing
It's already long enough.

3) Editor's Update
* Expired calls: None
* Calls in progress: None
* New ProtoXEP: Quick Response
* New ProtoXEP: Best practices for password hashing and storage

4a) Proposed XMPP Extension: Best practices for password hashing and storage - https://xmpp.org/extensions/inbox/password-storage.html
Jonas's primary question is whether this is a matter the XSF should actually be handling. Zash seconds Dave's comment that it would fit with the IETF Kitten group. Jonas notes that it concerns interoperability rather than wire protocol. Daniel agrees with the author's suggestion of starting this with the XSF first, and if it ends up being replaced then that's fine - Jonas agrees. Georg doesn't think the XSF is the right place for recommendations on "the Public Jabber™ Network", but probably is a good place for public-server recommendations.

Daniel: +1
Jonas: +1
Zash: +1
Georg: +1
Dave: [pending]

4b) Proposed XMPP Extension: Quick Response - https://xmpp.org/extensions/inbox/quick-response.html
Jonas would like a quick response for this one.

Jonas +1
Daniel: +1
Zash: +1
Georg: +1
Dave: [pending]

Georg thinks it looks vaguely familiar.
Jonas would like to note his agreement with actions and responses being merged on the wire layer, with a flag to indicate the switch between "virtual keyboard" and "persistent actions" modes. Zash asks whether this could be fixed in Experimental - one author, Syndace, doesn't think so, but would prefer to discuss that if accepted. Jonas adds that he would be fine with the split as long as the document explains why it's sensible. Syndace expects things will become clearer after incorporating recent feedback.
MattJ is interested in Daniel's suggestion of using spinners for actions, which could be another optional flag for responses.
Kev ponders the possibility of "Forms 2" - if people don't want to use forms because they're terrible, maybe start work on something that's not terrible; Jonas thinks we need to stop over-engineering the simple things. MattJ doesn't object to people working on Forms 2, but does object to delaying otherwise fine protocols for the dream of something better which might be finished some years from now; the given use case doesn't call for forms. Syndace notes that the XEP could end up specifying how to use forms to achieve what's currently done with different elements.

4c) PR#935 - XEP-0004: clarify that the submitting entity may omit optional fields - https://github.com/xsf/xeps/pull/935
Georg: +1
Jonas: +1 (don't see how this could do harm)
Zash: +1
Daniel: +1
Dave: [pending]

MattJ observes that nobody really knows what omitting a field does in different contexts; MUC doesn't define it, for example.
Daniel wonders what the values of omitted fields should be - opinion appears to be a default value or the previous value, depending whether you're creating or modifying. Jonas notes that this doesn't change the previous logic, and only clarifies what was already implicit.
Zash believes there is at least one implementation that will reject forms with missing fields.
Kev doesn't think XEP-0004 (Data Forms) can be fixed easily, as it's underspecified and trying to deal with it is a mess, but this change seems fairly painless - Jonas agrees. MattJ is in favour of the change, but doesn't think it resolves anything in practice - Jonas also agrees, but isn't going to stand in the way of spelling things out more clearly, rather than expecting developers to work things out for themselves.

4d) PR#926 - XEP-0045: Clarify that the 307 status code should not be used alongside 333 for user disconnects - https://github.com/xsf/xeps/pull/926
Jonas: +1
Zash: +1
Daniel: +1
Georg: +1
Dave: [pending]

Kev wonders whether the use of 'recommended' might be confused with SHOULD - Jonas shall advise the Editors.

4e) Last Call: XEP-0320 (Use of DTLS-SRTP in Jingle Sessions) - https://xmpp.org/extensions/xep-0320.html
Daniel: +1
Jonas: +1 (expect some feedback, given the recent influx of Jingle things)
Georg: +1
Zash: +1
Dave: [pending]

4f) Last Call: XEP-0339 (Source-Specific Media Attributes in Jingle) - https://xmpp.org/extensions/xep-0339.html
Jonas: +1
Georg: +1
Zash: +1
Daniel: +1
Dave: [pending]

4g) PR#934 - XEP-0167: add rtcp-mux element - https://github.com/xsf/xeps/pull/934
Daniel: +1
Zash: +1
Jonas: +1
Georg: +1
Dave: [pending]

Georg asks whether this affects backward compatibility - the author, Daniel, says it's an optional element, so probably not; Jonas adds that it's in the same namespace and some parsers are picky about that. Daniel offers to add a feature if that makes people feel better, but isn't worried about it as most implementations appear to already send that field; Jonas thinks writing that a feature will be announced is good for clarity, even if nobody cares in practice.
Georg asks whether the responder needs to acknowledge their use of rtcp-mux - Daniel says that it's indicated by the presence or omission in the counter offer.

5) Pending Votes
Room Activity Indicators (everyone) and XEP-0357 (Dave, Georg, Zash); but neither expires today.

6) Date of Next
2020-04-29 1500 UTC

7) AOB
It's already long enough.

8) Close
Thanks everyone.

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


More information about the Standards mailing list