[Standards] Council Minutes 2020-04-22

Dave Cridland dave at cridland.net
Thu Apr 30 10:36:15 UTC 2020


On Wed, 29 Apr 2020 at 15:34, Tedd Sterr <teddsterr at outlook.com> wrote:

> 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]
>
>
+1


> *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.
>
>
I would like many things, but in the meantime +1.


> *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.
>
>
+0 - I'm not entirely sure this is fixing (or breaking) anything, but I'm
not inclined to block it.


> *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.
>
>
-1 for "not recommended"/"recommended". If we mean SHOULD [NOT] let's say
it.


> *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]
>
>
+1


> *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]
>
>
+1


> *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.
>
>
+1


> *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.
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200430/e8541ccb/attachment-0001.html>


More information about the Standards mailing list