XMPP Council - 2019-11-13


  1. Tobias has left

  2. debacle has left

  3. Tobias has joined

  4. Tobias has left

  5. Tobias has joined

  6. debacle has joined

  7. stpeter has left

  8. Tobias has left

  9. moparisthebest has left

  10. moparisthebest has joined

  11. stpeter has joined

  12. debacle has left

  13. stpeter has left

  14. jos1264 has joined

  15. jos1264 has left

  16. stpeter has joined

  17. stpeter has left

  18. Guus has left

  19. Guus has joined

  20. daniel has left

  21. Tobias has joined

  22. daniel has joined

  23. lnj has joined

  24. daniel has left

  25. undefined has left

  26. lnj has left

  27. undefined has joined

  28. daniel has joined

  29. sonny has left

  30. sonny has joined

  31. daniel has left

  32. daniel has joined

  33. Zash has left

  34. debacle has joined

  35. Zash has joined

  36. debacle has left

  37. lnj has joined

  38. debacle has joined

  39. Syndace has left

  40. Syndace has joined

  41. Wojtek has joined

  42. guy has joined

  43. stpeter has joined

  44. guy has left

  45. guy has joined

  46. guy has left

  47. stpeter has left

  48. Wojtek has left

  49. daniel has left

  50. daniel has joined

  51. stpeter has joined

  52. Zash has left

  53. Wojtek has joined

  54. raspbeguy has left

  55. raspbeguy has joined

  56. stpeter has left

  57. Zash has joined

  58. stpeter has joined

  59. Zash has left

  60. Zash has joined

  61. stpeter has left

  62. daniel has left

  63. daniel has joined

  64. Dave Cridland has joined

  65. Ge0rG

    It is the time and the day.

  66. Ge0rG

    And I even have a Controversial Agendum!

  67. dwd

    Afternoon all.

  68. dwd

    1) Roll Call

  69. Ge0rG ,o/

  70. Link Mauve

    Hi. o/

  71. Ge0rG

    hello one-armed Link Mauve

  72. jonas’

    here

  73. dwd

    I've a vague recollection Kev said he'd likely miss this one.

  74. Kev

    Maybe

  75. dwd

    2) Agenda Bashing

  76. Kev

    I'm here.

  77. dwd

    I don't think there's anything, but I see Ge0rG wants to fight with me on this. :-)

  78. Ge0rG

    15:23:18 Ge0rG> dwd: can we add https://github.com/xsf/xeps/pull/854 to tomorrow's agenda? The worst thing that can happen is that it will be re-voted by New Council

  79. dwd

    Oh, fair enough.

  80. Ge0rG

    It's a PR adding to MUC-PM: > Private messages are meant to hide a user's real JID from occupants they are talking to. In <link url='#enter-nonanon'>non-anonymous rooms</link>, a client SHOULD NOT resort to private messages, but instead make use of direct messages to the other occupant's real bare JID. However, if the user knows the other JID for other reasons, e.g. because they are a room admin, private messages SHOULD be used anyway.

  81. Ge0rG

    rendered version at https://op-co.de/tmp/xep-0045.html#privatemessage

  82. dwd

    Anyone have anything else?

  83. jonas’

    +1 from me

  84. jonas’

    oh, we’re not even voting yet

  85. dwd

    jonas’, Patience.

  86. jonas’

    sorry, no, nothing from e

  87. jonas’

    sorry, no, nothing from me

  88. dwd

    OK. In that case:

  89. Link Mauve

    Neither from me.

  90. dwd

    3) Items for a vote.

  91. dwd

    a) XEP-0045: Direct messages SHOULD be used over PMs in non-anonymous rooms #854

  92. dwd

    https://github.com/xsf/xeps/pull/854

  93. jonas’

    +1 on #854

  94. Link Mauve

    +1 for that, it’s making the UX easier for users with no downside.

  95. Ge0rG

    +1

  96. Ge0rG

    I'm sure some people will consider this a Breaking Change, though.

  97. Kev

    How does the client know that it's 'other reasons'?

  98. Link Mauve

    Kev, it should be aware that the room isn’t non-anonymous by doing disco#info on it.

  99. dwd

    I think I'm going to be difficult. I understand the rationale (I think), but it remains unclear why this is a good idea, and it's unclear there are any interoperability concerns (which makes me question RFC 2119 language).

  100. Ge0rG

    > If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service MUST warn the user by including a status code of "100" in the initial presence that the room sends to the new occupant

  101. jonas’

    !100_received && jid_known => other_reasons

  102. Kev

    dwd: I think there potentially /are/ interoperability concerns. Those messages might get swallowed because the users aren't in each other's roster and they're blocking messages from such.

  103. Link Mauve

    Or 100 yeah.

  104. Ge0rG

    dwd: direct messages are typically much more robust than MUC-PMs, delivery-wise

  105. Link Mauve

    Kev, or s2s is broken for $reasons.

  106. dwd

    Kev, Oh, that's true. Although if they're blocking the user deliberately - I see arguments pro and con.

  107. Kev

    dwd: But if they're simply not allowing non-roster messages...

  108. Link Mauve

    Kev, shouldn’t they also block MUC PMs in this case?

  109. Kev

    Or non-presence messages, I should say.

  110. dwd

    My problem isn't even if this is a good idea, it's that it's marked as a SHOULD without really explaining the considerations involved.

  111. Ge0rG

    not allowing non-roster messages is a very bad practice.

  112. jonas’

    Kev, but isn’t that already an interop problem in and of itself?

  113. Kev

    Link Mauve: I meant non-presence, really, rather than non-roster.

  114. Ge0rG

    dwd: I started typing it as "should", but then I realized that RFC2119 applies either way and made it explicit

  115. Kev

    We started doing this in Swift, and actually ended up with messages not getting through that previously did.

  116. Ge0rG

    dwd: what are the considerations that are missing?

  117. dwd

    Ge0rG, Well, blah. I disagree that it does apply in non-caps, but it's somewhat irrelevant.

  118. Ge0rG

    dwd: if lowercasing it will please you, I can surely do that ;)

  119. Kev

    So I think rushing this through at the last moment of this Council is ill-advised. Better to wait for a Council who have full voting periods to consider the implications.

  120. Link Mauve

    Kev, on the other hand, I’ve had users report that it was terribly confusing to have two different chats with me (due to clicking on me from the MUC vs. from their roster, but they didn’t know that).

  121. Kev

    But this breaks things, so if we really want to vote now, I'm -1.

  122. Ge0rG

    Kev: we still have a week left.

  123. Ge0rG

    What Link Mauve said.

  124. jonas’

    Ge0rG, put it into modernxmpp.org

  125. Link Mauve

    jonas’, it already is there.

  126. jonas’

    ah, good.

  127. Kev

    Link Mauve: Indeed. And it's worth discussing that. But normative language here in this way isn't right.

  128. Ge0rG

    I actually experienced that with a coworker, who was confused about how those two chats are different.

  129. dwd

    Link Mauve, I've had users say they like the seperation of 1:1 messages and private messages relating to a groupchat.

  130. Link Mauve

    Kev, I think this is what this change is about. :)

  131. Ge0rG

    dwd: did those users grasp the difference?

  132. Kev

    As I say - we implemented this in Swift because it seemed like the Obviously Right thing to do - and then found it wasn't, necessarily.

  133. dwd

    Link Mauve, And if a client wishes to combine those into a single UX, what prevents it?

  134. Ge0rG

    Kev: your description rather sounds like it still is the Obviously Right thing to do, but there are technical implementation problems associated

  135. Link Mauve

    dwd, nothing, they perfectly can avoid this recommendation.

  136. Ge0rG

    also something about trust domains and how a MUC can manipulate all and everything coming in through it

  137. dwd

    Link Mauve, No, I mean, if a client wishes to present PMs in a non-anonymous room in the same message stream as 1:1 messages, surely it can?

  138. dwd

    Finally, I think there's a security issue wherein a semi-anonymous room could easily confuse a MUC admin's client into revealing the MUC admin's jid.

  139. Kev

    So I think these are the right questions to be asking, but I don't think this text is the right way to answer them.

  140. Kev

    Or not in isolation, at least.

  141. dwd

    But yes, I get, entirely, there are reasons why clients might want to send messages directly, and present PMs as direct messages. I'm not not comfortable putting a blanket requirement into '45 without some explanation of the considerations involved.

  142. dwd

    So I'm going to be awkward and -1 this.

  143. Ge0rG

    dwd, Kev: do you have specific advice on how to move on?

  144. Link Mauve

    dwd, a client can, but for instance multiple clients may not and it will be even more confusing to see half of the discussion happening on one client, and the full conversation on the other, as if Carbons wasn’t enabled.

  145. Kev

    Ge0rG: Off the hoof, I'm not sure I have a complete answer. It at least involves relaxing the language from SHOULD and having a discussion of the implications of both options, I think.

  146. Kev

    (And Security Considerations, as Dave says)

  147. dwd

    I have a feeling a lot more text will be involved. But more or less what Kev says.

  148. Ge0rG

    Kev: I'm aiming for consistency here, which is why I wanted the SHOULD

  149. Kev

    It's possible that appropriate discussion text means that a SHOULD is possible, I'm not sure at this point.

  150. Ge0rG

    I agree that more text about the trade-offs would be helpful, but historically we aren't good at offering such text, and I'm missing an appropriate XML element to style it as such

  151. dwd

    Ge0rG, If the text said "generally prefer" instead of SHOULD I would be more comfortable.

  152. Ge0rG

    dwd: noted

  153. dwd

    Ge0rG, But I don't think it's anywhere close to "Always do this and if you don't expect things to break", which is the approximate translation of SHOULD.

  154. Kev

    Having a SHOULD means that a receiving client should be able to make assumptions, too.

  155. Ge0rG

    re Security Considerations, the MUC can fake everything and anything, and I hoped that the text is clear about when NOT to do it

  156. Ge0rG

    dwd: isn't that the approximate translation of MUST, with SHOULD being more like "you should be knowing very well what you do if you violate a SHOULD"

  157. dwd

    Ge0rG, The gap between MUST and SHOULD is very small indeed. :-)

  158. Ge0rG

    dwd: it SHOULD be larger, though.

  159. dwd

    Anyway. Moving on?

  160. Ge0rG

    Sorry.

  161. Ge0rG

    does it make sense to bring this up again, next week, with relaxed text and pros and cons added?

  162. Ge0rG

    also please provide clearer advice re your expectations of what kind of Security Considerations to add

  163. dwd

    Sure. And if it's well-discussed on the list it stands a good chance.

  164. jonas’

    maybe, but if you’ve got it prepared for next council it doesn’t harm

  165. Kev

    I think there might be people outside this room who have experience here that is relevant, so I think listing it is important.

  166. Kev

    e.g. it's coincidence that I happen to be on Council (this week) and could say "We tried this and some things break".

  167. Ge0rG

    dwd: I can't promise a list discussion happening within a week

  168. Link Mauve

    Even if it takes two, it should be fine.

  169. Ge0rG

    Kev: but if I send a mail to standards@, and you reply to it, maybe more people will notice.

  170. dwd

    Ge0rG, Sounds good.

  171. Kev

    I will promise to try to respond :)

  172. Ge0rG

    > also please provide clearer advice re your expectations of what kind of Security Considerations to add

  173. dwd

    Anyway, really moving on.

  174. dwd

    4) Next Meeting

  175. dwd

    Next week?

  176. Kev

    I *think* I can.

  177. jonas’

    +1w wfm

  178. dwd

    I think we'll try then. :-)

  179. Ge0rG

    +1W WFM

  180. dwd

    5) Any Other Business?

  181. Ge0rG

    none here

  182. Kev

    Newp.

  183. dwd

    Really?

  184. dwd

    :-)

  185. dwd

    In that case:

  186. dwd

    6) Ite, Meeting Est

  187. Link Mauve

    \o_

  188. Ge0rG

    > also please provide clearer advice re your expectations of what kind of Security Considerations to add

  189. dwd

    One more to go, and the hopefully someone else will wat to have a go.

  190. jonas’

    thanks, dwd

  191. pep.

    > dwd: if lowercasing it will please you, I can surely do that ;) We haven't settled on changing 2119 to the update have we. That was never resolved

  192. dwd

    Yes, I think it was resolved, in the sense of "Not without individually checking every document carefully".

  193. Ge0rG

    pep.: yes, that went down on some TODO list

  194. dwd

    It'd probably be useful to do the groundwork allowing us to change them one by one, and adopt the updated version (that I can't recall the number of) for new documents and revisions ona case-by-case.

  195. dwd

    That part is just XSLT stuff that's an Editor job. Sorry. But it'll allow us to move more easily on the issue.

  196. flow

    and we could at least update the boilerplate text regarding 2119 at least for new XEPs

  197. pep.

    flow, agreed

  198. dwd

    Exactly.

  199. daniel has left

  200. undefined has left

  201. debacle has left

  202. stpeter has joined

  203. undefined has joined

  204. undefined has left

  205. undefined has joined

  206. daniel has joined

  207. stpeter has left

  208. Wojtek has left

  209. Zash has left

  210. Zash has joined

  211. debacle has joined

  212. Zash has left

  213. hichamel has joined

  214. hichamel has left

  215. hichamel has joined

  216. hichamel has left

  217. moparisthebest has left

  218. moparisthebest has joined

  219. lnj has left