[Standards] Council Minutes 2019-11-13

Tedd Sterr teddsterr at outlook.com
Mon Nov 18 17:39:37 UTC 2019


1) Roll Call
Present: Georg, Link, Jonas, Dave, Kev

2) Agenda Bashing
Dave doesn't think there is anything; Georg wants to start a fight.

3) PR #854 - XEP-0045: Direct messages SHOULD be used over PMs in non-anonymous rooms - https://github.com/xsf/xeps/pull/854
Jonas: +1
Link: +1 (making the UX easier for users with no downside)
Georg: +1 (author)
Kev: -1 (this breaks things)
Dave: -1 (not comfortable adding a blanket statement into 0045 without some explanation of the considerations involved)

The author expects some will consider this a breaking change.

Kev wants to know how a client would know when there are "other reasons" (for a user already being aware of the target JID) - the author mentions the 100 status code, which warns of a non-anonymous room.
Dave understands the rationale, but is unclear on why this is a good idea, or if there are interoperability concerns (questioning use of RFC 2119 language) - Kev thinks there are interoperability concerns, as those message could be lost due to users not being in each others' roster while blocking non-presence messages - the author suggests direct messages are typically more robustly delivered than MUC-PMs.
Dave has a problem with this being marked as 'SHOULD' without really explaining the considerations involved - the author had originally intended a lowercase 'should', but assumed RFC 2119 applies either way and decided to make it explicit; is happy to lowercase it if that would help.

Kev says they had done this in Swift, as it seemed like the Right Thing, but it resulted in messages not getting through; thinks rushing this through at the last moment is ill-advised, and it's better to wait for a Council to have a full voting period to consider the implications. Link has had users report confusion over having two separate chats with the same person (due to clicking in the MUC versus roster). The author reports of a coworker being confused about how the two chats (direct and private messages) differed; Dave has had users say they like the separation. The author thinks this is still the Right Thing, but there are associated technical implementation problems; also something about trust domains, and that a MUC can manipulate anything flowing through it. Dave thinks there is a security issue whereby a semi-anonymous room could confuse a MUC admin's client into revealing the admin's JID.

Dave understands there are reasons a client might want to present private messages as direct messages, but isn't comfortable adding a blanket statement into 0045 without some explanation of the considerations - Link says when using multiple clients it would be confusing to see half of the discussion on one client and the full conversation in another, as if Carbons weren't enabled. Kev thinks these are the right questions to be asking, but doesn't think this text is the right way to answer them - the author requests advice on how to proceed - Kev doesn't have a complete answer, but it should at least relax the SHOULD and discuss the implications of both options, as well as security considerations. Dave would be more comfortable if the text said "generally prefer" instead of "SHOULD".

The author wonders whether to bring this up again next week, with relaxed text and pros and cons added - Dave thinks it stands a good chance if it's well-discussed on-list; Jonas thinks it would also be fine if made ready for next Council. Kev thinks others might have relevant experience here, so mentioning it on-list is important - the author can't promise that discussion will happen within a week, but hopes Kev's reply to it will spark one - Kev promises to try to respond.

4) Next Meeting
2019-11-20 1600 UTC

5) Any Other Business

6) Close
Dave notes that there is one meeting of this Council remaining, and hopes somebody else will want to take on the most esteemed role of Council Chair.

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

More information about the Standards mailing list