XMPP Council - 2021-02-03


  1. stpeter has left
  2. debacle has left
  3. vaulor has left
  4. SouL has left
  5. kusoneko has left
  6. B has left
  7. B has joined
  8. stpeter has joined
  9. stpeter has left
  10. paul has left
  11. pprrks has left
  12. pprrks has joined
  13. vaulor has joined
  14. SouL has joined
  15. Tobias has joined
  16. mdosch has left
  17. mdosch has joined
  18. paul has joined
  19. B has left
  20. B has joined
  21. Wojtek has joined
  22. debacle has joined
  23. mani2 has joined
  24. mani2 has left
  25. debacle has left
  26. Wojtek has left
  27. neox has joined
  28. moparisthebest has left
  29. Wojtek has joined
  30. Wojtek has left
  31. sonny has left
  32. sonny has joined
  33. debacle has joined
  34. B has left
  35. pprrks has left
  36. pprrks has joined
  37. B has joined
  38. moparisthebest has joined
  39. stpeter has joined
  40. SouL has left
  41. vaulor has left
  42. jonas’ 1) Roll Call
  43. daniel Hi
  44. Zash Ohai
  45. dwd Afternoon!
  46. Ge0rG Good morning
  47. jonas’ \o/
  48. jonas’ 2) Agenda Bashing
  49. jonas’ anything?
  50. Zash Bash it!
  51. jonas’ \o/
  52. jonas’ 3) Editor’s Update
  53. jonas’ - Proposed XMPP Extensions: - Implicit WebSocket Endpoints
  54. jonas’ there’s already a good amount of discussion ongoing about that one on-list
  55. jonas’ speaking of which
  56. jonas’ 4) Items for Voting
  57. jonas’ 4a) Proposed XMPP Extension: Implicit WebSocket Endpoints URL: https://xmpp.org/extensions/inbox/xep-iwe.html Abstract: This document specifies implicit connection endpoints for XMPP over WebSocket (RFC 7395).
  58. jonas’ as you might’ve guessed, I hadn’t come around yet to read it, so I’m on-list
  59. daniel I'm not the biggest fan
  60. Ge0rG Yeah, daniel you brought up a good point on list
  61. Ge0rG and haproxy on yax.im:5222 tends to agree
  62. daniel I think I might be less oppossed to a XEP called "Recommendation for default port and path for websocket connections" informational XEP
  63. daniel which would address the point Sunny raised
  64. daniel and I do agree with his first paragraph I guess
  65. dwd Would that mean somebody running around and insisting every XMPP server changed their defaults?
  66. daniel sorry misspelled your name
  67. daniel dwd, yes
  68. daniel but the proposed XEP even more so I'm afraid
  69. daniel that's why I've put the "*recommendation* for default" in the title
  70. daniel to make it clear that it's just that
  71. daniel we can let it pan on on the list for a while I guess?
  72. jonas’ yes
  73. Zash on-list
  74. dwd I'm not sure we want to encourage anyone to listen on non-TLS websockets these days.
  75. Ge0rG on-list
  76. sonny daniel, no problem - sounds good to me so far
  77. daniel dwd, that too
  78. dwd Which is ironic considering they only exist because I argued for them. :-)
  79. Ge0rG dwd: I think the only reason would be for local development and CI/CD, but maybe there is a less inelegant solution for those
  80. Zash I'm skeptical, the no-SRV fallback thing seems like a mistake in hindsight, should we be repeating it?
  81. jonas’ Zash, I tend to agree
  82. jonas’ it causes annoying issues
  83. Zash But does it qualify for Experimental?
  84. jonas’ no idea, I’m still on-list
  85. daniel Zash. yes that's what I said on list.
  86. Zash daniel, I saw, and I agree.
  87. daniel but i think what i wrote above might be some sort of compromise because sonny does have a bit of a point
  88. SouL has joined
  89. dwd Right, so broadly, I think I'll veto, after skimming this. I'll post to the list on why, but as a summary:
  90. sonny I understand that ultimately the use case both for me and the editor is actually localhost/development so ws://service:5280/.well-known/xmpp-websocket would be fine there
  91. Ge0rG 159 of the 2726 client connections to yax.im use the non-SRV fallback.
  92. daniel Ge0rG, yes we can confirm ~10%
  93. daniel last time i checked
  94. Zash Pragmatism?
  95. dwd * Non-TLS websockets seem bad. * A "suck it and see" approach seems not something we want to encourage. * It's highly restrictive having the Websocket default to the same domain and a different port.
  96. daniel yes I was going to be +0 at best
  97. Ge0rG what about: * it's an unprivileged port that a random local user could bind on * it's not IANA approved
  98. daniel only because i really try to avoid -1
  99. jonas’ ok, I think I need to bring it up again: I had my pidgin fall back to A/AAAA regularly because SRV lookup was failing while the local recursor was still booting. I don’t think that accounts for all of the connections you’re seeing to A/AAAA:5222, but such issues are still a factor and it shouldn’t be attributed to "laziness". They could be addressed by abolishing that endpoint and mandating SRV still (i.e. instead of fallback, retry SRV).
  100. Ge0rG jonas’: old soho router resolvers lack SRV support. BTDT
  101. daniel jonas’, yes resolving SRV on crap wifis is an issue. but that isn’t the case for 156 over http
  102. jonas’ I think we can move on here.
  103. dwd I'd be up for a default path and default port for wss, as Daniel proposes, which - I think - satisfies much of the use-case for local dev.
  104. jonas’ dwd, I’ll note down your -1?
  105. dwd I hate to veto. I'll ost to the list and see if there are solutions, first.
  106. jonas’ ok
  107. dwd But I'm likely to, as far as I can see.
  108. jonas’ moving on:
  109. jonas’ 4b) PR#1032: Data Forms Clarifications URL: https://github.com/xsf/xeps/pull/1032 Abstract: No description provided.
  110. jonas’ -1, it does not show sufficiently how this is a clarification and not a massive normative change.
  111. jonas’ -1, it does not show sufficiently how this is a clarification and not a massive normative change; it introduces a precedent of requiring relative ordering of unrelated (i.e. different qname) elements which I *really* don’t want to see.
  112. daniel on list. over the bike shedding of websocket i forgot to read this
  113. flow form-field type aware parsingof data forms does become more complex if the order is not specified
  114. dwd jonas’, I don't think it's a new precedent, actually.
  115. flow form-field type aware parsing of data forms does become more complex if the order is not specified
  116. jonas’ dwd, source please
  117. flow and it appears to be actually the norm to have <requirement/> first, simply because most people copy the examples
  118. dwd jonas’, The existing text says <reported/> described "the data to follow".
  119. flow and it appears to be actually the norm to have <reported/> first, simply because most people copy the examples
  120. dwd jonas’, Also, I think Sl{eek|i}XMPP already assumes an order, I noticed it in the code the other day.
  121. daniel wait wasn’t the lack of element ordering the reason we can’t use schemas?
  122. jonas’ dwd, it’s not clear from me that imposes a strict ordering requirement
  123. flow daniel, that's why it isn't specified in the schema but in normative text
  124. jonas’ and for the record, I know of at least one implementation which does not guarantee the order and which would with that change become non-compliant.
  125. flow jonas’, hence the clarification ;)
  126. jonas’ flow, I don’t believe, yet, that this is a clarification instead of a normative change
  127. jonas’ (and, obviously, as the XML document is the entire XML stream, the wording as written is invalid anyway)
  128. jonas’ (but that is easy to fix)
  129. flow sure, everything which does clarify normative requirement that wasn't previously explicitly spelled out could be considered a normative change
  130. dwd jonas’, https://github.com/fritzy/SleekXMPP/blob/develop/sleekxmpp/plugins/xep_0004/stanza/form.py#L27 for example.
  131. flow it's a trade-off
  132. Ge0rG can we agree that the updated first commit of the PR is a clarification indeed?
  133. jonas’ flow, I don’t think that imposes a strict ordering during ingestion (as opposed to emission) of such stanzas
  134. jonas’ Ge0rG, I have to parse that in context first, one moment please
  135. dwd Anyway, happy to suggest this should be discussed on list, and not here.
  136. vaulor has joined
  137. jonas’ Ge0rG, yes, I agree
  138. Ge0rG on-list regarding the ordering requirement.
  139. jonas’ *sigh* I’ll see that I start a thread on that then
  140. Zash Ge0rG, yes
  141. flow jonas’, I don't think we should be able to make a difference between ingestion and emission
  142. jonas’ moving on, let’s take that to the list
  143. dwd flow, Except at mealtimes.
  144. jonas’ yikes
  145. Zash mm. on-list
  146. jonas’ 5) Pending Votes
  147. flow I would tolerate implementations changing the order of first level stanza extensions, but not the order of arbitrary elements while en-route
  148. jonas’ there are still missing votes by daniel and dwd on the Service outage status protoxep, unless I missed any on-list
  149. jonas’ the vote expires today
  150. daniel jonas’, i voted on list
  151. daniel +1
  152. daniel in the minutes thread
  153. jonas’ thanks, didn’t see that yet
  154. dwd Oh, sorry. My bad, very much. +1, I'm pretty sure the general concept is fine.
  155. jonas’ dwd, thanks!
  156. jonas’ 6) Date of Next
  157. jonas’ +1w wfm
  158. Zash +1w wfm
  159. daniel +1w wfm
  160. Ge0rG +1W WFM
  161. jonas’ that’s a quorum, thanks
  162. jonas’ 7) AOB
  163. daniel none here
  164. Zash -
  165. dwd ·
  166. jonas’ that was a lot of effort for saying "no" :)
  167. jonas’ alright then
  168. jonas’ 8) Ite Meeting Est
  169. jonas’ thanks everyone!
  170. Ge0rG thanks jonas’
  171. daniel thanks jonas’
  172. moparisthebest FYI a future SRV2 XEP will support advertising websocket in conjunction with other advertisement methods, and routers and such will all support it very quickly because what HTTP/The Browsers (tm) want, they get
  173. Zash Hrrrrrrrrrrrrr
  174. moparisthebest FYI a future SRV2 XEP will support advertising websocket in conjunction with other connection methods, and routers and such will all support it very quickly because what HTTP/The Browsers (tm) want, they get
  175. Zash And crappy firewalls will all magically implement this on day 1.
  176. flow i guess the sad part is that this is likely to be true
  177. Zash false, they will implement the `HTTPS` record only.
  178. kusoneko has joined
  179. kusoneko has left
  180. kusoneko has joined
  181. kusoneko has left
  182. kusoneko has joined
  183. moparisthebest the record name is still up in the air, it might end up being srv2 or https or http-svc or something else but that's just a minor detail
  184. moparisthebest what matters is browsers will require it so everyone will fall all over themselves to implement it asap, many already have
  185. Zash It has been deployed already. It's too late now.
  186. moparisthebest yep, something like 5% of sites already using it, support in all chrome channels etc
  187. moparisthebest but that's fine, we'll use whatever The Browsers (tm) support, and we'll be set because of it :)
  188. B has left
  189. pprrks has left
  190. pprrks has joined
  191. daniel has left
  192. B has joined
  193. daniel has joined
  194. stpeter has left
  195. pep. moparisthebest, link?
  196. Zash s/The Browsers/The Browser/
  197. moparisthebest Zash, don't depress me :'(
  198. moparisthebest pep., to, which? SRV2 ?
  199. pep. yeah
  200. Zash pep., https://mailarchive.ietf.org/arch/msg/dnsop/ldaCto09yaOuSXM92HgJhGqmPJw/
  201. moparisthebest pep., always takes me a minute to find the latest version, I think https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02
  202. pep. thanks
  203. moparisthebest (this also gets us encrypted client hello too, ie, hiding SNI and ALPN)
  204. pep. ietf.org is hosted at clownflare..
  205. moparisthebest isn't everything? :(
  206. pep. :(
  207. stpeter has joined
  208. Zash pep., no, www.ietf.org is hosted at cloudflare, but not ietf.org
  209. Zash I know this because there's a thread on a mailing list complaining about this.
  210. pep. re SVCB/HTTPS RRs, I guess we'll be able to do reverse roles now. HTTP on www.foo.tld served under foo.tld, and foo.tld serving XMPP and getting certificates properly. Useful in BYOD setups
  211. adiaholic has left
  212. daniel has left
  213. adiaholic has joined
  214. stpeter has left
  215. stpeter has joined
  216. B has left
  217. B has joined
  218. adiaholic has left
  219. daniel has joined
  220. adiaholic has joined
  221. B has left
  222. B has joined
  223. Kev has left
  224. Kev has joined
  225. Kev has left
  226. B has left
  227. B has joined
  228. Tobias has left
  229. stpeter has left
  230. paul has left
  231. debacle has left