[Council] [Standards] Council Voting Summary 2019-03-31

Dave Cridland dave at cridland.net
Tue Apr 2 16:44:32 UTC 2019


On Sun, 31 Mar 2019 at 21:47, Tedd Sterr <teddsterr at outlook.com> wrote:

> *2019-03-13 (expired 2019-03-27)*
>
> PASSED (-0:2:+3)
> *Proposed XMPP Extension: E2E Authentication in XMPP: Certificate Issuance
> and Revocation* - https://xmpp.org/extensions/inbox/eax-cir.html
> Dave: +1 (tentatively; seems in-scope)
> Georg: +1 (have some minor detail issues with this, but nothing critical)
> Jonas: +1
> Kev: [abstained]
> Link: [abstained]
>
> PASSED (-0:2:+3)
> *Proposed XMPP Extension: DNS Queries over XMPP (DoX)* -
> https://xmpp.org/extensions/inbox/dox.html
> Dave: +1 (will be pushing hard for Security Considerations in place about
> privacy)
> Georg: +1 (another potential use-case: XMPP clients behind an HTTP/socks
> proxy (resolving SRV would leak DNS data); a section about service
> discovery before connecting to XMPP would be great)
> Jonas: -0 (my personal distaste for weird things like DoH shouldn't stand
> in the way, and this is just as sensible)
> Kev: [abstained]
> Link: +1 (because it's a valid usecase and seems properly written)
>
>
> *2019-03-20 (expiring 2019-04-03)*
>
> *Last Call: XEP-0353 (Jingle Message Initiation)* -
> https://xmpp.org/extensions/xep-0353.html
> Dave: +1
> Georg: +1
> Jonas: +1
> Kev: [pending]
> Link: +1
>
>
> *2019-03-27 (expiring 2019-04-10)*
>
> *Advance to Draft: XEP-0412 (XMPP Compliance Suites 2019)* -
> https://xmpp.org/extensions/xep-0412.html
> Dave: [on-list] (wonder if we should consider a last call once more given
> the change of author)
> Georg: +1
> Jonas: +1
> Kev: [pending]
> Link: +1
>
>
+0 - I'm in two minds as to whether we should have a Compliance Suite if
there's no interest in the contents from the community, but equally it does
little harm. (I hope).


> *Proposed XMPP Extension: Automatic Trust Transfer (ATT)* -
> https://xmpp.org/extensions/inbox/automatic-trust-transfer.html
> Dave: [on-list]
> Georg: [on-list]
> Jonas: [on-list]
> Kev: [pending]
> Link: [on-list]
>
>
-1 - I don't think there's evidence of this being anything beyond a very
high-level sketch. Designing a cryptographic trust system is complex, and
I'm not convinced we have the expertise to adequately do such a thing.


> *PR #764 - XEP-0308: Clarify correcting a message multiple times* -
> https://github.com/xsf/xeps/pull/764
> Dave: [on-list]
> Georg: -1 (the XEP is in dire need of clarification, but it's more logical
> to correct the last message, not the first, e.g. when fetching partial MUC
> history)
> Jonas: +1
> Kev: [pending]
> Link: 0 (will break clients, but so will the other way, even if that seems
> more logical to me)
>
>
+0 - I'm pretty sure there are further clarifications on the nature and
scope of corrections, and it's nice to have a single way of doing things,
and this even looks like the right way, but it's not clear it makes any
difference either way - so I'd rather see some suggestion that if a
correction is corrected clients SHOULD treat this as a correction of the
original message.


> _______________________________________________
> 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/council/attachments/20190402/39aa0b8a/attachment.html>


More information about the Council mailing list