XMPP Council - 2020-04-22


  1. stpeter has joined
  2. stpeter has left
  3. Neustradamus has joined
  4. Neustradamus has left
  5. debacle has left
  6. susmit88 has left
  7. debacle has joined
  8. susmit88 has joined
  9. stpeter has joined
  10. stpeter has left
  11. debacle has left
  12. stpeter has joined
  13. stpeter has left
  14. debacle has joined
  15. debacle has left
  16. debacle has joined
  17. susmit88 has left
  18. susmit88 has joined
  19. stpeter has joined
  20. stpeter has left
  21. susmit88 has left
  22. susmit88 has joined
  23. debacle has left
  24. stpeter has joined
  25. stpeter has left
  26. kusoneko has left
  27. kusoneko has joined
  28. kusoneko has left
  29. kusoneko has joined
  30. stpeter has joined
  31. stpeter has left
  32. stpeter has joined
  33. stpeter has left
  34. bear has left
  35. susmit88 has left
  36. susmit88 has joined
  37. Tobias has joined
  38. stpeter has joined
  39. stpeter has left
  40. raspbeguy has left
  41. bear has joined
  42. bear has left
  43. stpeter has joined
  44. stpeter has left
  45. raspbeguy has joined
  46. raspbeguy has left
  47. paul has joined
  48. stpeter has joined
  49. stpeter has left
  50. bear has joined
  51. bear has left
  52. susmit88 has left
  53. susmit88 has joined
  54. undefined has joined
  55. Guus has left
  56. stpeter has joined
  57. stpeter has left
  58. bear has joined
  59. stpeter has joined
  60. stpeter has left
  61. Guus has joined
  62. bear has left
  63. stpeter has joined
  64. stpeter has left
  65. bear has joined
  66. Neustradamus has joined
  67. Neustradamus has left
  68. bear has left
  69. stpeter has joined
  70. stpeter has left
  71. robertooo has joined
  72. Link Mauve has left
  73. bear has joined
  74. debacle has joined
  75. Link Mauve has joined
  76. stpeter has joined
  77. stpeter has left
  78. bear has left
  79. susmit88 has left
  80. susmit88 has joined
  81. susmit88 has left
  82. susmit88 has joined
  83. stpeter has joined
  84. stpeter has left
  85. kusoneko has left
  86. kusoneko has joined
  87. kusoneko has left
  88. kusoneko has joined
  89. bear has joined
  90. stpeter has joined
  91. stpeter has left
  92. bear has left
  93. Neustradamus has joined
  94. Neustradamus has left
  95. stpeter has joined
  96. stpeter has left
  97. bear has joined
  98. bear has left
  99. susmit88 has left
  100. stpeter has joined
  101. stpeter has left
  102. susmit88 has joined
  103. sonny has left
  104. stpeter has joined
  105. stpeter has left
  106. susmit88 has left
  107. susmit88 has joined
  108. bear has joined
  109. susmit88 has left
  110. susmit88 has joined
  111. bear has left
  112. Neustradamus has joined
  113. Neustradamus has left
  114. stpeter has joined
  115. stpeter has left
  116. susmit88 has left
  117. susmit88 has joined
  118. stpeter has joined
  119. stpeter has left
  120. bear has joined
  121. bear has left
  122. stpeter has joined
  123. stpeter has left
  124. Neustradamus has joined
  125. Neustradamus has left
  126. stpeter has joined
  127. stpeter has left
  128. bear has joined
  129. bear has left
  130. kusoneko has left
  131. stpeter has joined
  132. stpeter has left
  133. susmit88 has left
  134. susmit88 has joined
  135. bear has joined
  136. susmit88 has left
  137. susmit88 has joined
  138. jonas’ 1) Roll Call
  139. daniel Hi
  140. Zash SYN
  141. jonas’ ACK
  142. Ge0rG FIN
  143. jonas’ also, no TCP in multicast
  144. jonas’ 2) Agenda Bashing
  145. Ge0rG RST RST RST
  146. jonas’ this one’s a long one, anything to modify?
  147. Ge0rG TL;DR, sorry :(
  148. jonas’ 3) Editor’s Update - Expired calls: None - Calls in progress: None - New ProtoXEP: Quick Response - New ProtoXEP: Best practices for password hashing and storage
  149. jonas’ 4) Items for voting
  150. Ge0rG looks good, but I haven't even catched up with previous on-lists
  151. jonas’ s/catched/caught/ scnr
  152. jonas’ 4a) Proposed XMPP Extension: Best practices for password hashing and storage URL: https://xmpp.org/extensions/inbox/password-storage.html Abstract: This document outlines best practices for handling user passwords on the public Jabber network for both clients and servers.
  153. jonas’ do you folks think this is a matter the XSF should handle?
  154. jonas’ that’s my primary question with this one
  155. Zash As Dave says, it would fit with IETF / Kitten
  156. daniel someone said on list (was it the author?) that we can start this of with the xsf and if it gets replaced by something else that's fine
  157. daniel and i agree
  158. jonas’ it doesn’t concern wire protocol, it concerns interop to some extent (but not beyond things applying to all things SASL)
  159. daniel so +1
  160. jonas’ daniel, very good point, I like it
  161. Ge0rG I think that the XSF is not the right place for recommendations for "the public Jabber network", but other than that it's probably a good place for public-server recommendations
  162. jonas’ I follow daniel with the +1
  163. Zash +1
  164. Ge0rG +1
  165. jonas’ Thanks
  166. jonas’ 4b) Proposed XMPP Extension: Quick Response URL: https://xmpp.org/extensions/inbox/quick-response.html Abstract: Quickly respond to automated messages.
  167. jonas’ let’s make this a quick response: +1
  168. jonas’ let’s make this a quick response: I’m +1 on that
  169. Ge0rG That looks vaguely familiar.
  170. jonas’ it does
  171. daniel +1
  172. Zash +1
  173. jonas’ though I’d like to note (cc @ MattJ ) that I agree that actions and responses should maybe be merged on the wire layer, and a flag should indicate a switch between the "virtual keyboard" or "persistent actions" mode
  174. Zash Can it be fixed in Experimental?
  175. susmit88 has left
  176. Syndace (spoiler: I don't think so, but I'd like to discuss details if/when it is accepted)
  177. jonas’ anything is possible in Experimental
  178. jonas’ Syndace, I’m not hard-sold on either way, if there’s a good rationale in the document which explains why a split is sensible, I’m fine with that
  179. MattJ FWIW I got hooked by Daniel's mention of spinners for actions, so... we'll see
  180. Syndace Yeah, I think the reasons will be a little clearer after I've incorporated the feedback I got in the past days.
  181. MattJ (this could be another optional flag for response type)
  182. jonas’ Ge0rG, are you staying with your intent to vote on-list on this one?
  183. Kev Is there any merit in considering 'forms2' here?
  184. Ge0rG a quick +1 in the hope to catch up with the thread before it expires or bad things happen
  185. Ge0rG hi Kev
  186. jonas’ Kev, I don’t think so
  187. Kev If people don't want to use forms because they're terrible, rather than solving a subproblem, using to to start work on a thing that isn't terrible?
  188. pep. Kev: after the protoxep has been accepted then :)
  189. pep. not blocking this one to reproduce what happened with reactions
  190. jonas’ I think we need to stop over-engineering the simple things
  191. MattJ Kev, I've no objection to people working on forms2, but I have objection to delaying otherwise fine protocols because there is a dream of something better that might be finished in a couple of years
  192. Syndace The XEP might just end up specifying how to conveniently use forms to achieve what is done with different elements now.
  193. MattJ The use case doesn't call for forms at all
  194. jonas’ the discussion about a potential '4 replacement should be taken to xsf@ please, we have a tight agenda today
  195. pep. (note that I'm not particularly in favour of quick response, I don't mind, I'm just bitter re reactions)
  196. jonas’ 4c) PR#935: XEP-0004: clarify that the submitting entity may omit optional fields URL: https://github.com/xsf/xeps/pull/935 Description: It is not really spelled out that the submitting entity may omit fields not mark as required by the processing entity. Even though the existence of the flag on form fields is a strong hint towards this, it is worth to explicitly state that.
  197. bear has left
  198. Ge0rG +1
  199. jonas’ I don’t see how this could do harm. +1
  200. Zash +1
  201. MattJ Observation: nobody really knows what omitting a field does in different contexts
  202. daniel wait. what will be the value of those fields if you leave them out?
  203. Zash daniel, up to the processing thing?
  204. daniel and thats good?
  205. jonas’ daniel, the "default"?
  206. MattJ MUC doesn't define this, for example
  207. Ge0rG the same as if you don't have the clarification in the XEP, I suppose
  208. daniel the default or the previous value?
  209. Zash defaults or previosu values depneding on if you're creating somethin new, or editing
  210. jonas’ daniel, it doesn’t change the logic of the document.
  211. jonas’ it was implicitly there already that fields which aren’t marked as <required/> can be omitted
  212. daniel mhh ok. +1
  213. Zash Tho I believe at least one implementation will reject forms if they're missing <fields>
  214. jonas’ <required/> This element, which MUST be empty, flags the field as required in order for the form to be considered valid.
  215. jonas’ taking the reverse of that, a field without <required/> does not need to be present
  216. Kev I don't think you can fix 4 without a certain amount of discomfort. It's underspecified in both the core and its uses, and trying to deal with it is a mess. This seems like low hanging fruit with relatively little pain, to me.
  217. jonas’ Kev, is this about 4c, or still about Quick Responses / forms2?
  218. Kev jonas’: The PR.
  219. jonas’ if the latter, please save it for after the meeting in xsf@. if the former, I don’t quite see how it’s connected.
  220. Kev MattJ observed that no-one knows what optional fields mean.
  221. jonas’ the PR is just a clarification of something which is defined elsewhere, but not spelt out clearly; I don’t see how your comment is relevant, but I’m tired, so maybe that’s that.
  222. Kev I said that any improvement to '4 is going to have uncomfortable questions, but this one seems to be fairly painless, and helps.
  223. jonas’ ah, yeah, that
  224. jonas’ I agree
  225. jonas’ thanks for clarifying
  226. MattJ I'm not council, but I'm in favour of the change under discussion. I just don't think it resolves anything in practice.
  227. jonas’ MattJ, I agree with that, too.
  228. jonas’ but I’m not going to stand in the way of making our documents more accessible by spelling things out in clear statements instead of having to reverse-logic something
  229. jonas’ and with that, moving on
  230. jonas’ 4d) PR#926: XEP-0045: Clarify that the 307 status code should not be used alongside 333 for user disconnects URL: https://github.com/xsf/xeps/pull/926 Description: Per discussion in xsf@ about the UX implications of showing user disconnects as kicks.
  231. jonas’ +1
  232. Zash +1
  233. daniel +1
  234. Ge0rG +1
  235. jonas’ 4e) Start Last Call on XEP-0320: Use of DTLS-SRTP in Jingle Sessions URL: https://xmpp.org/extensions/xep-0320.html Abstract: This specification defines how to use DTLS-SRTP (RFC 5763) in the Jingle application type for the Real-time Transport Protocol (RTP) as a way to negotiate media path key agreement for secure RTP in one-to-one media sessions.
  236. Kev 4d) is 'recommended' the right word here, given confusion with SHOULD?
  237. daniel +1
  238. jonas’ re 4e: +1, due to the recent influx of jingle things, I expect some feedback there actually
  239. jonas’ Kev, thanks, I’ll let the editors know
  240. Ge0rG +1
  241. Zash +1
  242. jonas’ 4f) Start Last Call on XEP-0339: Source-Specific Media Attributes in Jingle URL: https://xmpp.org/extensions/xep-0339.html Abstract: This specification provides an XML mapping for translating the RFC 5766 Source-Specific Media Attributes from SDP to Jingle
  243. jonas’ again, +1
  244. Ge0rG +1
  245. Zash +1
  246. daniel +1
  247. jonas’ Secret hidden agendum: 4g) PR#934: XEP-0167: add rtcp-mux element URL: https://github.com/xsf/xeps/pull/934 Description: RTCP-muxing is used in WebRTC. This element is actually used in the wild by clients like Siskin and Movim (and soon Conversations)
  248. jonas’ on-list
  249. daniel +1
  250. Zash +1
  251. jonas’ nevermind, +1
  252. Ge0rG doesn't that affect backward compat?
  253. daniel it's an optional element
  254. daniel so probably not?
  255. jonas’ in the same namespace though
  256. jonas’ some ~people~ parsers are picky about that
  257. Zash MAY and addition should be mostly fine?
  258. Zash Unless you're doing ultra strict schema validation
  259. daniel well we can introduce the feature for it
  260. daniel see the comment
  261. daniel if that makes people feel better
  262. daniel but in practice i wouldn’t be worried about it
  263. daniel most implementations i saw send this
  264. daniel that's how i even learned about that field
  265. jonas’ hm, writing down that a feature is to be announced -- even if in practice noone cares -- would be good for clarifty
  266. Ge0rG by sending it you tell the other party that you support it?
  267. jonas’ hm, writing down that a feature is to be announced -- even if in practice noone cares -- would be good for clarity
  268. daniel apparently down to the original google jingle
  269. Zash Seems fine then
  270. jonas’ but yeah, not going to insist on this
  271. Ge0rG +1 with the PR as-is
  272. Zash I wonder if we have a Jingle SIG we could solicit reviews from
  273. jonas’ we have a few people involved with jingle, but I think at least one of them already commented on the PR
  274. Zash Yeah
  275. Ge0rG daniel: does the responder need to somehow acknowledge use of <rtcp-mux/> or is it implied by how the connection is established?
  276. daniel Ge0rG, they can or can’t put that into their counter offer
  277. jonas’ that’ll negotiate nicely without any additional feature flags then
  278. jonas’ if they don’t know it, they can simply ignore it
  279. Ge0rG yeah
  280. jonas’ 5) Pending Votes
  281. jonas’ everyone is pending on Room Activity Indicators according to my notes (but I haven’t checked the ML yet)
  282. jonas’ anyone want to cast votes now?
  283. daniel not me
  284. jonas’ we’re over time anyways
  285. jonas’ and nothing expires
  286. jonas’ so moving on
  287. jonas’ 6) Date of Next
  288. jonas’ +1w wfm
  289. daniel +1w wfm
  290. Zash +1w wfm
  291. jonas’ 7) AOB Unless someone speaks up with an urgent AOB in the next 30s, I’m going to cut this.
  292. Ge0rG +1W WFM
  293. jonas’ 8) Ite Meeting Est
  294. daniel Thanks all
  295. jonas’ Thanks everyone for managing this long agenda without any on-list vote.
  296. jonas’ Thanks Tedd :)
  297. Ge0rG has left
  298. Ge0rG has joined
  299. susmit88 has joined
  300. susmit88 has left
  301. Wojtek has joined
  302. susmit88 has joined
  303. bear has joined
  304. bear has left
  305. susmit88 has left
  306. susmit88 has joined
  307. bear has joined
  308. daniel has left
  309. daniel has joined
  310. daniel has left
  311. daniel has joined
  312. daniel has left
  313. daniel has joined
  314. daniel has left
  315. daniel has joined
  316. kusoneko has joined
  317. daniel has left
  318. daniel has joined
  319. susmit88 has left
  320. susmit88 has joined
  321. susmit88 has left
  322. susmit88 has joined
  323. susmit88 has left
  324. susmit88 has joined
  325. susmit88 has left
  326. susmit88 has joined
  327. kusoneko has left
  328. kusoneko has joined
  329. kusoneko has left
  330. kusoneko has joined
  331. kusoneko has left
  332. kusoneko has joined
  333. kusoneko has left
  334. kusoneko has joined
  335. SamWhited has joined
  336. SamWhited has left
  337. daniel has left
  338. daniel has joined
  339. susmit88 has left
  340. susmit88 has joined
  341. vanitasvitae has left
  342. vanitasvitae has joined
  343. kusoneko has left
  344. kusoneko has joined
  345. kusoneko has left
  346. kusoneko has joined
  347. susmit88 has left
  348. susmit88 has joined
  349. undefined has left
  350. susmit88 has left
  351. susmit88 has joined
  352. debacle has left
  353. debacle has joined
  354. susmit88 has left
  355. susmit88 has joined
  356. susmit88 has left
  357. susmit88 has joined
  358. kusoneko has left
  359. kusoneko has joined
  360. kusoneko has left
  361. kusoneko has joined
  362. susmit88 has left
  363. susmit88 has joined
  364. robertooo has left
  365. susmit88 has left
  366. susmit88 has joined
  367. kusoneko has left
  368. kusoneko has joined
  369. kusoneko has left
  370. kusoneko has joined
  371. Zash has left
  372. Zash has joined
  373. Zash has left
  374. Zash has joined
  375. susmit88 has left
  376. susmit88 has joined
  377. susmit88 has left
  378. SamWhited has joined
  379. Tobias has left
  380. bear has left
  381. undefined has joined
  382. daniel has left
  383. daniel has joined
  384. bear has joined
  385. daniel has left
  386. daniel has joined
  387. bear has left
  388. bear has joined
  389. daniel has left
  390. daniel has joined
  391. undefined has left
  392. kusoneko has left
  393. kusoneko has joined
  394. kusoneko has left
  395. kusoneko has joined
  396. Wojtek has left
  397. kusoneko has left
  398. kusoneko has joined
  399. kusoneko has left
  400. kusoneko has joined
  401. daniel has left
  402. daniel has joined
  403. kusoneko has left
  404. kusoneko has joined
  405. paul has left
  406. debacle has left
  407. debacle has joined
  408. kusoneko has left
  409. kusoneko has joined
  410. kusoneko has left
  411. kusoneko has joined
  412. kusoneko has left
  413. kusoneko has joined
  414. debacle has left
  415. kusoneko has left
  416. kusoneko has joined
  417. debacle has joined
  418. debacle has left
  419. debacle has joined
  420. bear has left
  421. daniel has left
  422. debacle has left
  423. daniel has joined
  424. debacle has joined