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


  140. Zash


  141. jonas’


  142. Ge0rG


  143. jonas’

    also, no TCP in multicast

  144. jonas’

    2) Agenda Bashing

  145. Ge0rG


  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


  164. Ge0rG


  165. jonas’


  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


  172. Zash


  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


  199. jonas’

    I don’t see how this could do harm. +1

  200. Zash


  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’


  232. Zash


  233. daniel


  234. Ge0rG


  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


  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


  241. Zash


  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


  245. Zash


  246. daniel


  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’


  249. daniel


  250. Zash


  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


  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


  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