XMPP Council - 2021-02-03

  1. jonas’

    1) Roll Call

  2. daniel


  3. Zash


  4. dwd


  5. Ge0rG

    Good morning

  6. jonas’


  7. jonas’

    2) Agenda Bashing

  8. jonas’


  9. Zash

    Bash it!

  10. jonas’


  11. jonas’

    3) Editor’s Update

  12. jonas’

    - Proposed XMPP Extensions: - Implicit WebSocket Endpoints

  13. jonas’

    there’s already a good amount of discussion ongoing about that one on-list

  14. jonas’

    speaking of which

  15. jonas’

    4) Items for Voting

  16. 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).

  17. jonas’

    as you might’ve guessed, I hadn’t come around yet to read it, so I’m on-list

  18. daniel

    I'm not the biggest fan

  19. Ge0rG

    Yeah, daniel you brought up a good point on list

  20. Ge0rG

    and haproxy on yax.im:5222 tends to agree

  21. daniel

    I think I might be less oppossed to a XEP called "Recommendation for default port and path for websocket connections" informational XEP

  22. daniel

    which would address the point Sunny raised

  23. daniel

    and I do agree with his first paragraph I guess

  24. dwd

    Would that mean somebody running around and insisting every XMPP server changed their defaults?

  25. daniel

    sorry misspelled your name

  26. daniel

    dwd, yes

  27. daniel

    but the proposed XEP even more so I'm afraid

  28. daniel

    that's why I've put the "*recommendation* for default" in the title

  29. daniel

    to make it clear that it's just that

  30. daniel

    we can let it pan on on the list for a while I guess?

  31. jonas’


  32. Zash


  33. dwd

    I'm not sure we want to encourage anyone to listen on non-TLS websockets these days.

  34. Ge0rG


  35. sonny

    daniel, no problem - sounds good to me so far

  36. daniel

    dwd, that too

  37. dwd

    Which is ironic considering they only exist because I argued for them. :-)

  38. 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

  39. Zash

    I'm skeptical, the no-SRV fallback thing seems like a mistake in hindsight, should we be repeating it?

  40. jonas’

    Zash, I tend to agree

  41. jonas’

    it causes annoying issues

  42. Zash

    But does it qualify for Experimental?

  43. jonas’

    no idea, I’m still on-list

  44. daniel

    Zash. yes that's what I said on list.

  45. Zash

    daniel, I saw, and I agree.

  46. daniel

    but i think what i wrote above might be some sort of compromise because sonny does have a bit of a point

  47. dwd

    Right, so broadly, I think I'll veto, after skimming this. I'll post to the list on why, but as a summary:

  48. 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

  49. Ge0rG

    159 of the 2726 client connections to yax.im use the non-SRV fallback.

  50. daniel

    Ge0rG, yes we can confirm ~10%

  51. daniel

    last time i checked

  52. Zash


  53. 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.

  54. daniel

    yes I was going to be +0 at best

  55. Ge0rG

    what about: * it's an unprivileged port that a random local user could bind on * it's not IANA approved

  56. daniel

    only because i really try to avoid -1

  57. 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).

  58. Ge0rG

    jonas’: old soho router resolvers lack SRV support. BTDT

  59. daniel

    jonas’, yes resolving SRV on crap wifis is an issue. but that isn’t the case for 156 over http

  60. jonas’

    I think we can move on here.

  61. 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.

  62. jonas’

    dwd, I’ll note down your -1?

  63. dwd

    I hate to veto. I'll ost to the list and see if there are solutions, first.

  64. jonas’


  65. dwd

    But I'm likely to, as far as I can see.

  66. jonas’

    moving on:

  67. jonas’

    4b) PR#1032: Data Forms Clarifications URL: https://github.com/xsf/xeps/pull/1032 Abstract: No description provided.

  68. jonas’

    -1, it does not show sufficiently how this is a clarification and not a massive normative change.

  69. 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.

  70. daniel

    on list. over the bike shedding of websocket i forgot to read this

  71. flow

    form-field type aware parsingof data forms does become more complex if the order is not specified

  72. dwd

    jonas’, I don't think it's a new precedent, actually.

  73. flow

    form-field type aware parsing of data forms does become more complex if the order is not specified

  74. jonas’

    dwd, source please

  75. flow

    and it appears to be actually the norm to have <requirement/> first, simply because most people copy the examples

  76. dwd

    jonas’, The existing text says <reported/> described "the data to follow".

  77. flow

    and it appears to be actually the norm to have <reported/> first, simply because most people copy the examples

  78. dwd

    jonas’, Also, I think Sl{eek|i}XMPP already assumes an order, I noticed it in the code the other day.

  79. daniel

    wait wasn’t the lack of element ordering the reason we can’t use schemas?

  80. jonas’

    dwd, it’s not clear from me that imposes a strict ordering requirement

  81. flow

    daniel, that's why it isn't specified in the schema but in normative text

  82. 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.

  83. flow

    jonas’, hence the clarification ;)

  84. jonas’

    flow, I don’t believe, yet, that this is a clarification instead of a normative change

  85. jonas’

    (and, obviously, as the XML document is the entire XML stream, the wording as written is invalid anyway)

  86. jonas’

    (but that is easy to fix)

  87. flow

    sure, everything which does clarify normative requirement that wasn't previously explicitly spelled out could be considered a normative change

  88. dwd

    jonas’, https://github.com/fritzy/SleekXMPP/blob/develop/sleekxmpp/plugins/xep_0004/stanza/form.py#L27 for example.

  89. flow

    it's a trade-off

  90. Ge0rG

    can we agree that the updated first commit of the PR is a clarification indeed?

  91. jonas’

    flow, I don’t think that imposes a strict ordering during ingestion (as opposed to emission) of such stanzas

  92. jonas’

    Ge0rG, I have to parse that in context first, one moment please

  93. dwd

    Anyway, happy to suggest this should be discussed on list, and not here.

  94. jonas’

    Ge0rG, yes, I agree

  95. Ge0rG

    on-list regarding the ordering requirement.

  96. jonas’

    *sigh* I’ll see that I start a thread on that then

  97. Zash

    Ge0rG, yes

  98. flow

    jonas’, I don't think we should be able to make a difference between ingestion and emission

  99. jonas’

    moving on, let’s take that to the list

  100. dwd

    flow, Except at mealtimes.

  101. jonas’


  102. Zash

    mm. on-list

  103. jonas’

    5) Pending Votes

  104. flow

    I would tolerate implementations changing the order of first level stanza extensions, but not the order of arbitrary elements while en-route

  105. jonas’

    there are still missing votes by daniel and dwd on the Service outage status protoxep, unless I missed any on-list

  106. jonas’

    the vote expires today

  107. daniel

    jonas’, i voted on list

  108. daniel


  109. daniel

    in the minutes thread

  110. jonas’

    thanks, didn’t see that yet

  111. dwd

    Oh, sorry. My bad, very much. +1, I'm pretty sure the general concept is fine.

  112. jonas’

    dwd, thanks!

  113. jonas’

    6) Date of Next

  114. jonas’

    +1w wfm

  115. Zash

    +1w wfm

  116. daniel

    +1w wfm

  117. Ge0rG

    +1W WFM

  118. jonas’

    that’s a quorum, thanks

  119. jonas’

    7) AOB

  120. daniel

    none here

  121. Zash


  122. dwd


  123. jonas’

    that was a lot of effort for saying "no" :)

  124. jonas’

    alright then

  125. jonas’

    8) Ite Meeting Est

  126. jonas’

    thanks everyone!

  127. Ge0rG

    thanks jonas’

  128. daniel

    thanks jonas’

  129. 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

  130. Zash


  131. 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

  132. Zash

    And crappy firewalls will all magically implement this on day 1.

  133. flow

    i guess the sad part is that this is likely to be true

  134. Zash

    false, they will implement the `HTTPS` record only.

  135. 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

  136. moparisthebest

    what matters is browsers will require it so everyone will fall all over themselves to implement it asap, many already have

  137. Zash

    It has been deployed already. It's too late now.

  138. moparisthebest

    yep, something like 5% of sites already using it, support in all chrome channels etc

  139. moparisthebest

    but that's fine, we'll use whatever The Browsers (tm) support, and we'll be set because of it :)

  140. pep.

    moparisthebest, link?

  141. Zash

    s/The Browsers/The Browser/

  142. moparisthebest

    Zash, don't depress me :'(

  143. moparisthebest

    pep., to, which? SRV2 ?

  144. pep.


  145. Zash

    pep., https://mailarchive.ietf.org/arch/msg/dnsop/ldaCto09yaOuSXM92HgJhGqmPJw/

  146. 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

  147. pep.


  148. moparisthebest

    (this also gets us encrypted client hello too, ie, hiding SNI and ALPN)

  149. pep.

    ietf.org is hosted at clownflare..

  150. moparisthebest

    isn't everything? :(

  151. pep.


  152. Zash

    pep., no, www.ietf.org is hosted at cloudflare, but not ietf.org

  153. Zash

    I know this because there's a thread on a mailing list complaining about this.

  154. 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