[Standards] Council Voting Summary 2019-10-15

Tedd Sterr teddsterr at outlook.com
Wed Oct 16 14:32:00 UTC 2019

2019-09-18 (expired 2019-10-02)
VETOED (-1:1:+3) PR #828 - XEP-0045: add muc#roominfo_webchat_url form field as used in the wild - https://github.com/xsf/xeps/pull/828

2019-09-25 (expired 2019-10-09)

FAILED (-1:4:+0)
PR #824 - XEP-0060: Add pubsub#public in Publish-Subscribe features - https://github.com/xsf/xeps/pull/824
Dave: [abstained]
Georg: -1 (this needs its own feature var; +1 if such a var is added to the PR)
Jonas: [abstained]
Kev: [abstained]
Link: [abstained]

PASSED (-0:0:+5)
PR #834 - XEP-0410: treat remote-server-{not-found,timeout} like timeout - https://github.com/xsf/xeps/pull/834
Dave: +1 (seems sensible)
Georg: +1 (don't consider this a breaking change as it's only a client behaviour)
Jonas: +1 (author)
Kev: +1
Link: +1

VETOED (-2:3:+0)
Proposed XMPP Extension: Authorization Tokens - https://xmpp.org/extensions/inbox/auth-tokens.html
Dave: -1 (against the XSF defining authentication pathways; should defer to the IETF XMPP and/or Kitten Working Groups)
Georg: +0 (reasons given on-list)
Jonas: [abstained]
Kev: -1 (default to -1; similar opinion to Dave, but want to re-read first)
Link: [abstained]

2019-10-02 (expiring 2019-10-16)

Proposed XMPP Extension: Message Moderation - https://xmpp.org/extensions/inbox/message-moderation.html
Dave: [pending]
Georg: [on-list]
Jonas: [on-list]
Kev: +1 (the part about iq ordering is often a nuisance server-side when there are unnecessary constraints on ordering, and this one doesn't seem needed)
Link: [on-list]

2019-10-09 (expiring 2019-10-23)

Proposed XMPP Extension: Message Retraction - https://xmpp.org/extensions/inbox/message-retraction.html
Dave: +1 (willing to be told I'm wrong later)
Georg: [on-list]
Jonas: [on-list]
Kev: [pending]
Link: [on-list]

VETOED (-5:0:+0)
PR #840 - XEP-0060: Clarify unlimited behaviour for node config - https://github.com/xsf/xeps/pull/840
Dave: -1 (having "-1" or empty seems sane for unlimited, but not novel unicode glyphs)
Georg: -1 (agree with Dave; also don't understand the implied semantics of that value)
Jonas: -1 (text needs to be clearer on the actual value for "use the server limit")
Kev: -1 (for untypable glyphs in particular)
Link: -1 (indicating an arbitrarily high value wouldn't be nice)

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

More information about the Standards mailing list