XMPP Council - 2020-05-06


  1. daniel has left

  2. daniel has joined

  3. Wojtek has joined

  4. sonny has left

  5. sonny has joined

  6. debacle has left

  7. stpeter has left

  8. Wojtek has left

  9. daniel has left

  10. daniel has joined

  11. stpeter has joined

  12. sonny has left

  13. sonny has joined

  14. stpeter has left

  15. kusoneko has left

  16. kusoneko has joined

  17. kusoneko has left

  18. kusoneko has joined

  19. kusoneko has left

  20. kusoneko has joined

  21. kusoneko has left

  22. kusoneko has joined

  23. kusoneko has left

  24. kusoneko has joined

  25. kusoneko has left

  26. kusoneko has joined

  27. kusoneko has left

  28. kusoneko has joined

  29. kusoneko has left

  30. kusoneko has joined

  31. daniel has left

  32. daniel has joined

  33. sonny has left

  34. sonny has joined

  35. kusoneko has left

  36. kusoneko has joined

  37. kusoneko has left

  38. kusoneko has joined

  39. kusoneko has left

  40. kusoneko has joined

  41. kusoneko has left

  42. kusoneko has joined

  43. stpeter has joined

  44. kusoneko has left

  45. kusoneko has joined

  46. kusoneko has left

  47. kusoneko has joined

  48. daniel has left

  49. daniel has joined

  50. Neustradamus has left

  51. sonny has left

  52. sonny has joined

  53. Neustradamus has joined

  54. daniel has left

  55. daniel has joined

  56. stpeter has left

  57. sonny has left

  58. sonny has joined

  59. stpeter has joined

  60. daniel has left

  61. daniel has joined

  62. stpeter has left

  63. daniel has left

  64. daniel has joined

  65. Tobias has joined

  66. sonny has left

  67. sonny has joined

  68. stpeter has joined

  69. stpeter has left

  70. SouL has left

  71. sonny has left

  72. sonny has joined

  73. SouL has joined

  74. daniel has left

  75. daniel has joined

  76. undefined has left

  77. sonny has left

  78. sonny has joined

  79. undefined has joined

  80. bear has left

  81. daniel has left

  82. daniel has joined

  83. daniel has left

  84. stpeter has joined

  85. daniel has joined

  86. stpeter has left

  87. bear has joined

  88. daniel has left

  89. daniel has joined

  90. debacle has joined

  91. Tobias has left

  92. Tobias has joined

  93. daniel has left

  94. daniel has joined

  95. kusoneko has left

  96. kusoneko has joined

  97. kusoneko has left

  98. kusoneko has joined

  99. kusoneko has left

  100. kusoneko has joined

  101. robertooo has joined

  102. sonny has left

  103. sonny has joined

  104. stpeter has joined

  105. sonny has left

  106. sonny has joined

  107. stpeter has left

  108. Zash has left

  109. Zash has joined

  110. debacle has left

  111. debacle has joined

  112. stpeter has joined

  113. kusoneko has left

  114. kusoneko has joined

  115. kusoneko has left

  116. kusoneko has joined

  117. kusoneko has left

  118. kusoneko has joined

  119. kusoneko has left

  120. kusoneko has joined

  121. stpeter has left

  122. kusoneko has left

  123. kusoneko has joined

  124. kusoneko has left

  125. kusoneko has joined

  126. kusoneko has left

  127. kusoneko has joined

  128. kusoneko has left

  129. kusoneko has joined

  130. kusoneko has left

  131. kusoneko has joined

  132. Neustradamus has left

  133. Neustradamus has joined

  134. kusoneko has left

  135. kusoneko has joined

  136. kusoneko has left

  137. kusoneko has joined

  138. stpeter has joined

  139. kusoneko has left

  140. kusoneko has joined

  141. kusoneko has left

  142. kusoneko has joined

  143. Neustradamus has left

  144. kusoneko has left

  145. kusoneko has joined

  146. Neustradamus has joined

  147. kusoneko has left

  148. kusoneko has joined

  149. stpeter has left

  150. Ge0rG has left

  151. undefined has left

  152. undefined has joined

  153. Ge0rG has joined

  154. stpeter has joined

  155. Ge0rG

    good morning everyone.

  156. Zash presses snooze

  157. Zash

    Time?

  158. jonas’

    yikes sorry

  159. jonas’

    1) Roll Call

  160. jonas’

    I’m here but was deeply sunk in lua code

  161. Zash

    I'm tired but here.

  162. jonas’

    I join the "tired" club

  163. daniel

    Hi

  164. jonas’

    I suppose Ge0rG is here too

  165. jonas’

    2) Agenda Bashing

  166. jonas’

    anything to add/modify?

  167. jonas’

    I suppose not

  168. jonas’

    3) Editor’s Update

  169. jonas’

    - Expired calls: - LC for XEP-0280 expired without feedback. - Calls in progress: - LC for XEP-0320 (ends at 2020-05-19) - LC for XEP-0339 (ends at 2020-05-19)

  170. jonas’

    + a protoxep

  171. jonas’

    4) Items for Voting

  172. Ge0rG

    I wonder why nobody commented on Carbons.

  173. jonas’

    4a) Decide on Advancement of XEP-0280: Message Carbons URL: https://xmpp.org/extensions/xep-0280.html

  174. jonas’

    everyone is worn out about that probably

  175. Ge0rG

    I'm torn about it.

  176. Zash

    I just started looking at carbons (the code) again recently

  177. daniel

    yes. i don’t even have an opinion on that anymore

  178. Ge0rG

    I like most of the XEP, except for this one line: > it contains payload elements typically used in IM (...)

  179. Ge0rG

    Personally, I'd rather roll back Carbons and fix message routing, than entrench the mess. But that's not going to happen, so... 🤷

  180. Zash

    It's already entrenched tho

  181. Zash

    IM-NG can obsolete it when it's ready :)

  182. daniel

    Ge0rG, well some time before the summit I thought so too. (see my emails from january) but after more discussions during summit I came to the conclusion that im-ng isn’t going to be easy either

  183. daniel

    and share a lot of the problems with carbons

  184. jonas’

    it won’t indeed

  185. Zash

    Is anything ever easy?

  186. jonas’

    though having clear semantics is a good start

  187. Ge0rG

    daniel: right. My hope was that we can invest some work into Carbons to make IM-NG profit from the rules later on

  188. Ge0rG

    jonas’: yes, the fallback rules would be only for legacy-interop

  189. daniel

    yes we won’t get around of defining some ruleset probably

  190. daniel

    or start over with the whole pubsub mess

  191. daniel

    sorry; rambling; all that is to say that i don’t know what to do with carbons status wise at the moment

  192. Zash

    With my Implementer Hat on, I have something slightly different from the rules in the XEP now, which might be better, or not. Going to need some time and deployment experinece with it I think.

  193. Ge0rG

    daniel: you could check whether §6.1 is sufficient and adequate for all your use cases.

  194. daniel

    does it cover jingle messages?

  195. Ge0rG

    Zash: that sounds like we should postpone advancing Carbons

  196. Ge0rG

    daniel: are jingle messages of type=chat?

  197. daniel

    well you can make everything type chat

  198. Zash

    And/or extend the LC, tho I'm not sure I'll have energy to post about it in the next to weeks either.

  199. daniel

    but usually (following the examples from the xep) they are not

  200. Ge0rG

    or is jingle one of the gazillion XEPs that don't define an appropriate message type?

  201. Ge0rG

    I want Carbons and MAM sync to become type=headline

  202. Zash

    One thing: The new mod_carbons acts on anything that's been archived.

  203. daniel

    Conversations makes them type chat to get around 6.1 rules

  204. daniel

    but arguably they probably maybe shouldn’t be?

  205. Ge0rG

    daniel: what about fixing §6.1 rules instead?

  206. Ge0rG

    Zash ~volunteered~ proposed to fix https://xmpp.org/extensions/xep-0226.html

  207. jonas’

    I wonder whether we need a routing-WG like we had (have) an E2EE WG

  208. daniel

    but yeah that's the point? so do we have to touch 280 every time there is a new xep around?

  209. Zash

    jonas’, good idea

  210. daniel

    and subsequently all implementations

  211. Ge0rG

    I suppose Carbons has no meaning outside of IM anyway, and Jingle is kinda-sorta-IM now

  212. jonas’

    daniel, supposedly, since you send to bare-JID (under IM-NG rules) this would be broadcast

  213. Ge0rG

    jonas’: that would be good

  214. jonas’

    daniel, supposedly, since you send to bare-JID (under IM-NG rules) this would be multicast to all resources

  215. Zash

    also, is there a Jingle WG that could comment on this batch of Jingle XEPs?

  216. jonas’

    which is one of the key reasons for IM-NG, so that we don’t have to touch things every time a new protocol comes aroundy

  217. daniel

    but because of backward compat you still have to have rules

  218. Ge0rG

    is there any single implementation of `urn:xmpp:carbons:rules:0` ?

  219. jonas’

    I see a few people who have a certain share in implementations (daniel, Holger, Zash, Ge0rG, someone from the Dino folks, lovetox) which could sit down for a sprint and work out rules for different use cases.

  220. Ge0rG

    daniel: yes, and we need to define those rules

  221. jonas’

    and who could drive IM-NG forward

  222. jonas’

    I think this is most direly needed

  223. Ge0rG

    jonas’: I agree.

  224. jonas’

    daniel, you have the compliance checker to pressure people to deploy an update

  225. Zash

    Ge0rG, I /think/ Prosody actually does something very close to the rules in the XEP

  226. Ge0rG

    most of the rules we sort out will apply equally to IM-NG, Carbons and MAM

  227. Zash

    As in, the stable release. Trunk now does something else.

  228. jonas’

    can someone of you folks take the hat for this sprint?

  229. Ge0rG

    Zash: the delta would be a good addition to the 0280 LC

  230. jonas’

    because we won’t solve this in this session.

  231. jonas’

    I’ll be happy to move 280 back to Experimental in that case

  232. Ge0rG

    I'm not good at organizing.

  233. Zash

    jonas’, sure

  234. jonas’

    Zash, thank you very much

  235. daniel

    +1 moving it back

  236. Ge0rG

    But I'm motivated to bring 0280 + IM-NG rules into a sane state

  237. jonas’

    I can offer a jitsi meet instance for a virtual meeting, though I suppose you’ll find other instances, too

  238. jonas’

    so Zash will organize a virtual(?) sprint on that one; please announce it on standards@ and also ping ejabberd, dino and gajim devs at least

  239. Zash

    jonas’, +1 for back to experimental.

  240. Zash

    also +1 to whoever invents <in-reply to=id/>

  241. jonas’

    Zash, was that in implicit "I didn’t want to volunteer for organizing this!!!"

  242. Zash

    yes

  243. jonas’

    darn

  244. jonas’

    ok, then I’ll step up to try to get everyone on a table, but I won’t actively participate most likely

  245. jonas’

    4b) Request LC for XEP-0393: Message Styling URL: https://xmpp.org/extensions/xep-0393.html Abstract: This specification defines a formatted text syntax for use in instant messages with simple text styling.

  246. jonas’

    +1

  247. daniel

    +1

  248. daniel grabs popcorn

  249. Zash

    +1

  250. Zash

    LC all the XEPs?!

  251. Ge0rG

    +1

  252. jonas’

    4c) Proposed XMPP Extension: Channel Binding Pseudomechanisms URL: https://xmpp.org/extensions/inbox/cb-pseudomechanisms.html Abstract: A method for advertising and negotiating types of channel binding supported by SCRAM based SASL mechanisms.

  253. jonas’

    even more so than with the previous spec about password storage, I’m fairly certain that this needs to be addressed on the IETF-level

  254. jonas’

    -1, even more so than with the previous spec about password storage, I’m fairly certain that this needs to be addressed on the IETF-level

  255. Zash

    I approve of the general goal tho.

  256. jonas’

    me too

  257. daniel

    > I approve of the general goal tho. +1

  258. Ge0rG

    on-list

  259. jonas’

    hm, I’m changing my vote to on-list.

  260. jonas’

    I have to read it more closely

  261. SamWhited

    This will *never* be addressed at the IETF level, FWIW. The XMPP WG is shut down and this is protocol specific.

  262. jonas’

    SamWhited, yeah, I just realised that

  263. jonas’

    so going on-list, because I’m not sure that mangling the mechanism names is a great way to do that

  264. daniel

    But the approach feels wrong

  265. jonas’

    yeah, a lot wrong

  266. jonas’

    if only we had namespaced attributes

  267. Zash

    on-list

  268. daniel

    If only we had namespace attributes

  269. daniel

    Lol

  270. Zash

    I'd like to have Dave around to discuss this one

  271. jonas’

    let’s not discuss protocol specifics in this meeting; I’m assuming you’re on list too, daniel?

  272. daniel

    Yes on list

  273. jonas’

    5) Outstanding Votes I lied in the email, there are no outstanding votes.

  274. jonas’

    6) Date of Next

  275. jonas’

    +1w wfm

  276. Zash

    SamWhited, starting the XMPP WG up is a thing we can do if needed AFAIK

  277. jonas’

    +1w could be tricky for me

  278. daniel

    (pretty sure I'm -1 but I want to elaborate more on list)

  279. jonas’

    there is the RIPE General Meeting and I was appointed responsible for doing on behalf of my company which is a LIR there

  280. jonas’

    I’m not sure what the schedule is and when I’m expected to participate there, so I can’t say for sure I can chair the meeting here

  281. jonas’

    I’ll prepare an agenda on tuesday, who volunteers to chair?

  282. SamWhited

    Please let's have a discussion on list before you all finish voting if possible. I'm open to being convinced of alternative methods, but the ones I could think of were much more obnoxious to implement or required major modifications to our SASL profile (which is not likely to happen)

  283. jonas’

    SamWhited, I’m going to reply on-list soon

  284. SamWhited

    But I also knew this method would be an uphill fight :)

  285. Zash

    Something something XEP-0388

  286. SamWhited shuts up and lets you finish the meeting.

  287. jonas’

    yes, thanks

  288. jonas’

    we’re at Date of Next, and we need a chair for next week

  289. daniel

    i can chair

  290. jonas’

    Thanks

  291. Zash

    so +1w then

  292. jonas’

    excellent

  293. jonas’

    7) AOB

  294. jonas’

    none from me

  295. Zash

    none here

  296. jonas’

    alright

  297. jonas’

    8) EOM

  298. jonas’

    thanks all

  299. Zash

    ACK, FIN, RST

  300. dwd has joined

  301. dwd

    Well, taken me all afternoon, but I can apparently get in this room again.

  302. jonas’

    \o/

  303. Zash

    Äntligen!

  304. Ge0rG

    dwd: how many yaks did you shave today?

  305. dwd

    Not enough. I don't *think* I can connect outbound and establish TLS to this server, and I do not understand why.

  306. Zash

    _this_?

  307. Zash

    `locate iteam-hat`

  308. dwd

    Zash, As in xmpp.xmpp.org. But not just this one, cerdale.zash.se is the same.

  309. Zash

    If mine doesn't want to talk to you it should send you a <stream:error> with the reason

  310. dwd

    TLS negotiation fails, though, so no opportunity.

  311. Zash

    I see you → here connections, but unencrypted in the other direction

  312. dwd

    Right, because Openfire can actually fallback to retry without TLS.

  313. dwd

    Which is what's happened here I think.

  314. Zash

    for reverse connections?

  315. Zash

    crazy

  316. jonas’

    May 06 15:12:15 s2sin5578e86691d0 debug Incoming s2s received <stream:stream xmlns='http://etherx.jabber.org/streams' version='1.0' to='xmpp.org' from='dave.cridland.net'> May 06 15:12:15 s2sin5578e86691d0 debug Sending[s2sin_unauthed]: <stream:stream id='3bdeff5f-b26a-4635-a2d6-1d37c1ab1db9' xml:lang='en' xmlns='jabber:server' to='dave.cridland.net' xmlns:db='jabber:server:dialback' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' from='xmpp.org'> May 06 15:12:16 s2sin5578e86691d0 debug Incoming s2s received <stream:stream xmlns='http://etherx.jabber.org/streams' version='1.0' to='xmpp.org' from='dave.cridland.net'> May 06 15:12:16 x509 debug Cert dNSName dave.cridland.net matched hostname May 06 15:12:16 s2sin5578e86691d0 debug Sending[s2sin_unauthed]: <stream:stream id='57b0f2aa-5f41-4a53-ba20-3e5c8686952a' xml:lang='en' xmlns='jabber:server' to='dave.cridland.net' xmlns:db='jabber:server:dialback' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' from='xmpp.org'> May 06 15:12:16 s2sin5578e86691d0 info Incoming s2s stream dave.cridland.net->xmpp.org closed: stream closed May 06 15:12:16 s2sin5578e86691d0 debug Destroying incoming session dave.cridland.net->xmpp.org

  317. jonas’

    that doesn’t seem useful

  318. dwd

    Sorry, distracted by Atlassian apparently having a dodgy cert on their cloud hosting.

  319. Zash

    I see some failed attepmts at dialback and some timeouts

  320. dwd

    That would have been earlier, I suspect.

  321. Zash

    after what jonas’ posted

  322. SamWhited

    I get a *lot* of errors from your server as well, dwd. Mostly useless things about being unable to connect.

  323. SamWhited

    FWIW

  324. dwd

    How bizarre.

  325. Zash

    May 06 15:13:46 s2sout5578e7a3df20 debug Destroying incomplete session xmpp.org->dave.cridland.net due to inactivity

  326. Zash

    May 06 15:12:17 s2sout5578e7a3df20 debug sent dialback key on outgoing s2s stream

  327. Ge0rG

    TLS version mismatch?

  328. Ge0rG

    something like TLS 1.0 vs TLS 1.2? dh keys?

  329. jonas’

    2020/05/06 17:54:43 failed to probe c2s to xmpp:cridland.net: dial tcp 74.125.28.125:5269: connect: connection refused

  330. dwd

    Yeah, not cridland.net

  331. dwd

    dave.cridland.net

  332. jonas’

    also, why does it write c2s

  333. dwd

    Anyway. More usefully:

  334. Zash

    Huh, but this one is TLS'd

  335. dwd

    XEP-0280 - I thought we'd discussed this in the Summit and come to some kind of conclusion abotu moving the routing rules themselves into a new XEP, that would be pointed to by IM-NG on the basis that IM-NG was Carbons with better PR^Wsyntax?

  336. Zash

    May 06 15:12:17 s2sout5578e7a3df20 debug Sending[s2sout_unauthed]: <stream:stream xml:lang='en' xmlns='jabber:server' to='dave.cridland.net' ... May 06 15:12:17 s2sout5578e7a3df20 info Stream encrypted (TLSv1.3 with TLS_AES_256_GCM_SHA384)

  337. dwd

    Yeah, from * -> dave.cridland.net it negotiates TLSv1.3 and AES etc.

  338. Zash

    Then it does dialback, which times out. Then some time later it tries again

  339. dwd

    So:

  340. dwd

    4a) On-list, I need to look at what was discussed at the Summit.

  341. dwd

    4b) +1

  342. jonas’

    I admit I speculated you’d take time to vote on 4b so that we don’t have three LCs starting within just 24 hours ;-)

  343. jonas’

    still, welcome back

  344. undefined has left

  345. dwd

    4c) I'm somewhat torn about this. It's a revolting syntax, but I wonder if just listing channel bindings, and mandating that sorry, but if you offer it for one it's offered for all mechanisms, might be preferable. As to whether this lives here or IETF, I'm inclined to say it lives here - as Sam notes, XMPP-WG is dead, and KITTEN is probably not ideal, though definitely worth talking to Simon Josefsson there as he's discussed this kind fo thing before quite recently. So Sorta +1 but dear dog can we change this?

  346. Wojtek has joined

  347. jonas’

    dwd, I think quite similar as you do, and I think we should discuss those specifics on-list

  348. dwd

    By which I mean, on-list to give me some time to think, but if it weren't using pseudo-mechanisms I'd be a firm +1.

  349. undefined has joined

  350. Neustradamus has left

  351. pep.

    If only we had namespace attributes

  352. dwd

    I'm not sure those help here.

  353. sonny has left

  354. sonny has joined

  355. sonny has left

  356. sonny has joined

  357. sonny has left

  358. sonny has joined

  359. sonny has left

  360. sonny has joined

  361. sonny has left

  362. sonny has joined

  363. sonny has left

  364. sonny has joined

  365. debacle has left

  366. sonny has left

  367. sonny has joined

  368. Wojtek has left

  369. sonny has left

  370. sonny has joined

  371. daniel has left

  372. daniel has joined

  373. Wojtek has joined

  374. debacle has joined

  375. robertooo has left

  376. raspbeguy has joined

  377. daniel has left

  378. daniel has joined

  379. Neustradamus has joined

  380. Tobias has left

  381. moparisthebest has left

  382. moparisthebest has joined

  383. debacle has left

  384. sonny has left

  385. SouL has left

  386. dwd

    Scribbled that listwards, and I'll vote +1 on 4c).

  387. undefined has left

  388. Zash

    I'm not sure how I feel about "(oh btw channel bindings in TLS 1.3 are undefined)" hidden away in an appendix in an RFC that doesn't update the channel binding document.

  389. dwd

    Zash, Channel bindings are in general a bit stalled. I think the XMPP community is the only group that really cares, sometimes, and we're not very vocal within the IETF, so they probably don't realise there's interest.

  390. SamWhited

    The two channel bindings it's talking about are broken anyways, and I assume even more broken on TLS 1.3 because they won't work in-0RTT mode (I think)

  391. SamWhited

    I'm only guessing, but I assume that's why they decided to just say that they're undefined. Libraries won't be able to give you the data half the time, or even worse, they will try to give you non-unique data

  392. Zash

    Found a single thread from 2015 discussing it

  393. SamWhited

    Link? I didn't find anything when I looked

  394. dwd

    SamWhited, And by the way, you're doing a great job in KITTEN, pushing this stuff. It probably feels like you're getting nowhere, but I think it's making an impact slowly - but the recent last-minute-virtual IETF meeting has probably drained people of energy.

  395. SamWhited

    dwd: thanks; I was worried I was beign a pest, I never know how the IETF works or how much I should stay on top of things

  396. SamWhited

    being, even

  397. Zash

    SamWhited, not sure which thread it was but a couple of threads from 2015-2016 pop up in https://mailarchive.ietf.org/arch/search/?qdr=a&start_date=&end_date=&email_list=tls&email_list=kitten&q=text%3A%28channel+binding%29&as=1

  398. SamWhited

    Thanks

  399. SamWhited

    Oh hey, if I filter by date and list there's a whole topic called "Deprecating tls-unique for TLS 1.3". Dunno why I never realized there was a convenient list-only search that doesn't involve Google or DDG or whatever.

  400. Zash

    This is a pretty great mailing list interface indeed. I wish we used it for our lists.

  401. SamWhited

    +1

  402. daniel has left

  403. SamWhited

    Aha, and it mentions an old draft name I never found by searching either!

  404. SamWhited

    Hopefully I can find discussion on that and finally know what had been done towards this in the past. It's just about impossible to dig information out of the IETF.

  405. Zash

    I think I searched for the channel binding RFC number as well last time

  406. daniel has joined

  407. SamWhited

    This works almost exactly the same as how mine did originally, that's encouraging (or maybe not, since it just dissapeared in 2015 and I'm not sure why yet)

  408. Zash

    This?

  409. SamWhited

    sorry, the other draft I found in that email thread that expired in 2015: https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03

  410. SamWhited

    The author amusingly responded to the other I-D I have out right now, but not the emails to KITTEN and TLS about the channel binding draft, so I pinged him to ask him about the history of it and what not.

  411. Zash

    Endless yaks probably.

  412. undefined has joined

  413. Wojtek has left

  414. Wojtek has joined

  415. Wojtek has left

  416. Tobias has joined

  417. Wojtek has joined

  418. Tobias has left