XMPP Council - 2017-02-22

  1. Zash has left
  2. Kev has left
  3. Lance has left
  4. Kev has left
  5. Lance has joined
  6. Lance has left
  7. Tobias has joined
  8. Tobias has joined
  9. Kev has left
  10. SamWhited has joined
  11. jere has joined
  12. SamWhited has joined
  13. daniel has left
  14. daniel has joined
  15. Kev has left
  16. Kev has left
  17. jayaura has left
  18. Kev has left
  19. Kev has left
  20. Zash has joined
  21. peter has left
  22. Flow has joined
  23. Flow has left
  24. Kev has left
  25. SamWhited has left
  26. Kev has left
  27. Kev has left
  28. jayaura has joined
  29. jcbrand has joined
  30. Kev has left
  31. ralphm has left
  32. jayaura has joined
  33. Kev has left
  34. jayaura has joined
  35. Flow has joined
  36. Kev has left
  37. jere has joined
  38. jere has left
  39. jere has joined
  40. Dave Cridland has left
  41. Dave Cridland has joined
  42. Kev has left
  43. jayaura has joined
  44. jayaura has joined
  45. Dave Cridland has left
  46. jayaura has joined
  47. Dave Cridland has left
  48. Kev has left
  49. jayaura has joined
  50. jere has left
  51. jere has joined
  52. Kev has left
  53. Zash has left
  54. Kev has left
  55. Kev has left
  56. daniel has left
  57. daniel has joined
  58. moparisthebest has joined
  59. jere has joined
  60. Tobias has left
  61. jere has joined
  62. Flow has joined
  63. jayaura has joined
  64. jayaura has joined
  65. ralphm has joined
  66. jcbrand has left
  67. Kev has left
  68. SouL has left
  69. Tobias moparisthebest, didn't you plan an update on https://xmpp.org/extensions/xep-0368.html security considerations after last week's discussions with SamWhited?
  70. moparisthebest Tobias, I updated it
  71. Tobias so it's just the editor that hasn't processed it yet, ok
  72. moparisthebest he wanted the description updated, and I changed something else too, I think it's good to go
  73. moparisthebest I think he did? I'll check
  74. moparisthebest yea that's the latest version
  75. Tobias ah..ok
  76. SamWhited I thought I merged… refresh?
  77. Link Mauve Hi~
  78. Tobias yeah..seems it's the latest version
  79. Tobias ah..seems it's about time
  80. Tobias 1) Roll call
  81. daniel here
  82. SamWhited nods
  83. Dave Cridland Here.
  84. Link Mauve Here too.
  85. Tobias great
  86. Tobias 2) Minute taker
  87. Tobias seems jc isn't here, so we need a volunteer
  88. daniel i can do it
  89. Tobias great
  90. Tobias 3) Outstanding votes
  91. Tobias https://trello.com/b/ww7zWMlI/xmpp-council-agenda there are 2 ProtoXEPs and 2 other voting issues on the trello, please see recent minute notes and reply on list to vote
  92. Dave Cridland I've a few there.
  93. Tobias 4) Clarify CSI and Carbons state after SM resumption https://github.com/xsf/xeps/pull/402
  94. Tobias Sam added this earlier this month, Flow closed his PR and opened indepenent PRs instead. Please take a look and reply feedback in the PRs.
  95. Tobias 5) The Last Call for XEP-0333: Chat Markers ended, daniel is taking maintainership and will probably send in an update sometime so we can vote on advancing it
  96. SamWhited If daniel plans on making more changes, I will extend the LC by another week.
  97. Tobias more changes? haven't seen changes since the LC was issued
  98. SamWhited s/more changes/changes/
  99. Tobias ah..k
  100. Tobias 6) Vote on advancing XEP-0368: SRV records for XMPP over TLS, specifically Version 0.1.2, to Draft
  101. Tobias I'll vote on list
  102. daniel +1
  103. SamWhited I still don't like the direct TLS definition text, but that's an editorial change that can be made during draft
  104. SamWhited so +1
  105. daniel re extending the last call for xep333. please do. i will make changes in the next wee
  106. Tobias Dave Cridland, Link Mauve ?
  107. Link Mauve Wasn’t there a pending PR to fix the direct TLS definition?
  108. Link Mauve Apparently not.
  109. Link Mauve Anyway, will vote on list.
  110. Dave Cridland I think '368 is ready to go Draft now.
  111. Tobias that's probably supposed to be at least a +0
  112. Tobias ?
  113. Dave Cridland +1
  114. Tobias great
  115. Dave Cridland FTR, I'm sure there's further editorial fixes, but the technical side seems solid.
  116. Tobias 7) Date of next
  117. Tobias I'm probably traveling next Wednesday around this time
  118. daniel should we do tuesday?
  119. daniel same time?
  120. Link Mauve I’m ok with Tuesday.
  121. SamWhited WFM
  122. Tobias that could work better for me, yeah
  123. Tobias does that work for you, Dave Cridland?
  124. ralphm has left
  125. Dave Cridland I think so.
  126. Tobias great..that would be 2017-02-28 16:00:00 UTC then
  127. Tobias 8) AOB
  128. SamWhited Yes
  129. Tobias yeah?
  130. SamWhited XEP-0233, 0280, 0334, 0352 had their LCs end today. One of them has a pending PR (0280), otherwise do we want to do anything about them?
  131. Tobias probably see what the feedback was on them, if there was positive feedback indicating that they are fine and no changes are required, we can vote on them next week
  132. Tobias if the feedback indicates changes are required, they should stay proposed until we receive an update on the XEP
  133. daniel 334 and 352 are probably good to go
  134. daniel but we can vote on that next time
  135. daniel i think with these widely deployed xeps no feedback is good feedback
  136. SamWhited 334 I'm a bit torn about, but I agree with 352
  137. SamWhited anyways, next week. In the mean time should I extend the LC or move them back to experimental?
  138. Tobias i'd request to extend the LC of XEP-0233 and i'll bug someone who implemented it to respond with feedback on the list
  139. Kev FWIW, I don't think that's true, 'no feedback' is generally a sign of no interest in XEPs, which implies they've probably not seen sufficient review.
  140. Kev (Not saying that's the case with 334/352 necessarily, but as a general point)
  141. daniel Kev, i was specifically talking about those day. as they seem to be used and implemented
  142. daniel s/day/two
  143. Tobias yup...and we should try bugging people having implemented those...even if they have little time they could simply reply with a mail answering the questions with a short Yes/No.
  144. Link Mauve Tobias, that sounds sensible.
  145. daniel ok
  146. Tobias any other AOB?
  147. SamWhited Sounds reasonable; in that case I'll extend the LCs again.
  148. Tobias SamWhited, sounds sensible
  149. Tobias doesn't look like it
  150. Tobias bangs the gavel
  151. Tobias thanks everyone
  152. Link Mauve Thank you!
  153. Tobias thank you daniel for writing up meeting minutes
  154. moparisthebest note with 368 I made a somewhat major change with the last version
  155. jere has joined
  156. moparisthebest SamWhited, pointed out 3.1 had no proper SHOULD/MUST etc language
  157. moparisthebest in my mind that was always a MUST (mixing priorities of records), but he and ralphm convinced me it should be a SHOULD
  158. moparisthebest so maybe it was only a major change in my mind :)
  159. Tobias will give the XEP a total reread this evening then :) luckily it's not that big
  160. moparisthebest yea and it works the same both ways, the server op can't tell if you mixed priorities or some ports were blocked
  161. moparisthebest so in the grand scheme of things, no big deal
  162. ralphm has left
  163. jayaura has joined
  164. Dave Cridland So it might be that there exist circumstances to not mix priorities properly, and it'll still interop? Feels like a SHOULD is OK here.
  165. jcbrand has joined
  166. Dave Cridland moparisthebest, What were the cases ralphm and SamWhited were unable to mix priorities?
  167. moparisthebest Dave Cridland, ralphm pointed to the python twisted lib that connected to SRV records and how it'd be hard to mix them, but easy to try xmpps-client first then xmpp-client second
  168. moparisthebest which is fair, and like you said doesn't affect interop, and moreover is invisible to the server
  169. Zash moparisthebest: I also believe that'd be easier to implement.
  170. moparisthebest right
  171. Zash Keeping track of 'this srv entry is with tls/with starttls' seems like a recipe for messing up
  172. Dave Cridland Zash, I found it easy enough, and RFC 6168 is the same, so it's not uncommon.
  173. moparisthebest it was easy in conversations
  174. moparisthebest you already have to keep an object with 'target' and 'port', throwing 'directTls' in there is trivial?
  175. Dave Cridland That's basically what I did in Metre.
  176. Dave Cridland It treats a _xmpps-server._tcp record as if it were a _xmpp-server._tcp record with an extra field of "tls=true".
  177. Zash I may have done somesuch for DANE
  178. moparisthebest conversations code starts about here: https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/utils/DNSHelper.java#L184
  179. moparisthebest and yea I think you'd do DANE the same way, store the key hash on the same object
  180. moparisthebest I think, implementing dnssec+dane is fairly high on my priorities as a next patch for conversations
  181. Dave Cridland moparisthebest, See the minidns work that the XSF had s a GSoC project a couple of years back - should work fine. Smack uses it already.
  182. Dave Cridland moparisthebest, But just do DNSSEC+RFC 6125 names to beging with.
  183. moparisthebest yea Dave Cridland conversations already uses minidns, so I think it's basically just writing a bit of code
  184. moparisthebest so that brings up an interesting point, DANE can pin certs, public keys, and anywhere in the chain, but the RFC recommends implementations for a specific protocol pick one way and stick with it
  185. moparisthebest like for SMTP they just use public key pinning on the end device and that's all that is supported
  186. jayaura has joined
  187. Lance has joined
  188. moparisthebest sorry had to run off, but is there a standard like that for DANE with xmpp?
  189. moparisthebest or can/should we make one?
  190. Dave Cridland DANE-SRV is as close as we get. But I'm happy supporting all forms - I've seen use-cases for all of them.
  191. moparisthebest I despise certificate pinning personally hehe
  192. moparisthebest pinning the end devices public key is the only way to go in my opinion
  193. Zash has joined
  194. SamWhited Dave Cridland: I *can* mix priorities, I just don't want too. I'm going to try connecting and starting TLS and connecting and starting a plain stream at the same time probably; if TLS works, it wins, otherwise start using the plain stream that was already being negotiated.
  195. Kev has left
  196. moparisthebest attempting simultaneous connections sounds , not good for some reason
  197. moparisthebest do you do that now with existing SRV records? attempt them all at once and see which one wins?
  198. SamWhited moparisthebest: I'm not doing it for each record, just for each type of record (xmpp vs. xmpps); weights and priorities are still used within those records.
  199. SamWhited However, yes, if you have a few servers with identical weights and priorities, I would like to connect to all of them and use whichever one wins.
  200. SamWhited (and then if that fails, fall back to the next set of weights/priorities)
  201. moparisthebest what's the difference? the server op mixed priorities when they defined them
  202. moparisthebest I mean none of this really matters, you can do it however you like and interop and everything will work perfectly
  203. SamWhited If the server op made plain a higher priority than TLS, I'm ignoring it. That's basically the only difference.
  204. moparisthebest just seems strange, I assumed people that wouldn't mix them would just try xmpps- first, then xmpp-
  205. Kev has left
  206. SamWhited That's what I'm doing; doing it at the same time is just an optimization (if we can't do xmpps, we just fallback to the connection that's already started)
  207. moparisthebest yea but in doing both at the same time it's slower than just doing the first would be
  208. moparisthebest if bandwidth is constrained or anything
  209. SamWhited maybe, but I really doubt even the slowest connections are *that* slow (unless you're operating of HFR or something)
  210. Kev And no-one would do that, right? :)
  211. SamWhited Heh, I'm aware that it exists, I'm just not writing a library that aims to target every single use case (although, this will probably be an option when you configure the session, so it will probably support not doing it this way too, haven't figured the API out yet though)
  212. jayaura has joined
  213. Dave Cridland I was wondering about happy-eyeballs across multiple SRV records.
  214. Kev I think I've suggested before that happy-eyeballs across multiple same-priority records is sensible.
  215. moparisthebest how many domains have enough servers where it'd make a difference?
  216. moparisthebest that's a genuine question I really do not have any idea :)
  217. ralphm has left
  218. SamWhited I'm not sure; probably not many, but it's also not hard to do or anything, so I'm not sure that it matters. ¯\_(ツ)_/¯
  219. jayaura has joined
  220. moparisthebest it just kind of smells of premature optimization, multi-threaded code where connections are racing and one wins doesn't sound like the simplest thing to implement, especially if 99% of cases have 1 server anyway
  221. SamWhited Nah, I've already done it, it was trivial.
  222. moparisthebest probably depends a lot on the language too :)
  223. moparisthebest what are you using? go still?
  224. SamWhited Yah, Go (which indeed is the reason why it was trivial)
  225. moparisthebest is that code open source anywhere? I'd like to have a look
  226. SamWhited I just need to add it to my XMPP library and also add the XMPP/XMPPS version (although that's not a race, that's waiting on XMPPS and just pre-negotiating XMPP in case XMPPS fails)
  227. moparisthebest yea I was thinking about how to implement it in java, but I'm not sure I'd call it trivial
  228. SamWhited Nothing is trivial in Java… everything is harder than you expect it to be.
  229. SamWhited Or maybe that's just me.
  230. moparisthebest I wouldn't go that far :) but yea
  231. Zash has joined
  232. Kev has left
  233. Kev has left
  234. Kev has joined
  235. Kev has left
  236. Zash has left
  237. Lance has left
  238. jere has left
  239. Dave Cridland has left
  240. Dave Cridland has left
  241. Zash has left
  242. jcbrand has left
  243. Kev has joined
  244. Kev has left
  245. jere has joined
  246. Zash has joined
  247. Dave Cridland has left
  248. Dave Cridland has left
  249. Tobias has left
  250. Dave Cridland has left
  251. Dave Cridland has left
  252. Tobias has left
  253. Zash has joined
  254. jcbrand has joined
  255. Tobias has joined
  256. Zash has joined
  257. peter has joined
  258. Lance has joined
  259. Kev has joined
  260. Kev has left
  261. Kev has joined
  262. jcbrand has left
  263. Lance has left
  264. Lance has left
  265. Kev has left
  266. moparisthebest has joined
  267. Lance has left
  268. Lance has left
  269. peter has left
  270. Kev has joined
  271. Zash has joined
  272. Kev has left
  273. daniel has left
  274. jayaura has left
  275. jayaura has joined
  276. Kev has left
  277. daniel has left