XMPP Council - 2020-02-26


  1. jonas’ heads up, work and public transport hate my scheduling today. I might run a few minutes late. Feel free to start without me, I'll join. Ideally, I'll at least be on my phone when 1600Z strikes
  2. jonas’ will be on time
  3. Zash Just got home and sat down
  4. jonas’ kind of did the same
  5. jonas’ 1) Roll Call
  6. jonas’ is present
  7. Zash 2
  8. daniel Here
  9. Ge0rG !
  10. Zash dwd?
  11. jonas’ assuming that dwd will appear, moving on
  12. jonas’ (we have quorum either way)
  13. jonas’ 2) Agenda Bashing
  14. jonas’ anything to add?
  15. jonas’ probably not
  16. Ge0rG We need shorter agendas in the future
  17. jonas’ 3) Editor’s Update - ProtoXEP: Extended Channel Search - Expired calls: CFE on XEP-0198, CFE on XEP-0368, LC on XEP-0398 - Calls in progress: - LC: XEP-0402 (PEP Native Bookmarks), ends: 2020-03-03 - CFE: XEP-0066 (Out of Band Data), ends: 2020-03-10 - LC: XEP-0429 (Special Interests Group End to End Encryption), ends: 2020-03-10
  18. jonas’ (note the LC which came in after I sent the email yesterday)
  19. jonas’ 4) Items for a Vote
  20. jonas’ 4a) Decide on advancement of XEP-0398 Title: User Avatar to vCard-Based Avatars Conversion URL: https://xmpp.org/extensions/xep-0398.html Abstract: This specification describes a method for using PEP based avatars and vCard based avatars in parallel by having the user’s server do a conversion between the two.
  21. jonas’ 4a) Decide on advancement of XEP-0398 Title: User Avatar to vCard-Based Avatars Conversion URL: https://xmpp.org/extensions/xep-0398.html Abstract: This specification describes a method for using PEP based avatars and vCard based avatars in parallel by having the user’s server do a conversion between the two.
  22. jonas’ I would like to see changes on the Security Considerations section before this moves on. Since we need to touch normative language, I guess it’s better to handle this in Experimental
  23. jonas’ so -1 from my side
  24. Ge0rG Some PEP access questions came up, it would make sense to consider those first
  25. jonas’ so -1 from my side, with the intent of having someone™ fix this
  26. jonas’ so -1 from my side, with the intent of having someone™ fix this; so no rejection, just back to Experimental for fixes
  27. Ge0rG -1 as well due to that
  28. daniel Yes I'm fine with updating the pep stuff on relative short notice
  29. daniel We can restart next week or so
  30. jonas’ sounds like a plan
  31. Zash -1 (I agree with jonas’ )
  32. dwd Hiya folks, sorry for being late.
  33. daniel -1
  34. jonas’ that’s massively Veto’d then
  35. jonas’ next:
  36. dwd I can add another veto if you want. :-)
  37. jonas’ dwd, would be great for formal reasons :)
  38. jonas’ 4b) Decide on advancement of XEP-0198 Title: Stream Management URL: https://xmpp.org/extensions/xep-0198.html Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption. (The CFE ends today, so be sure to send in your feedback if you haven’t already.)
  39. dwd -1, for the reasons stated by others.
  40. Ge0rG dwd: can you also add more veto reasons?
  41. jonas’ I am on-list, because I haven’t been able to catch up on the thread yet
  42. Ge0rG I'm not sure regarding 0198. It's doing its job great, except for the unclear resume host connection mechanism
  43. dwd For XEP-0198, I noted a comment from - I think - MattJ on S2S I've yet to consider. But it's fair to say that 198 on S2S is under specified at best.
  44. Zash Ge0rG, s2s?
  45. jonas’ we have zero s2s implementations, do we?
  46. Ge0rG So we want actual experience with s2s 0198?
  47. jonas’ question is whether that even allows us to move it forward
  48. daniel -1. I think I (and others) brought up vaild but fixable concerns
  49. Zash on-list, haven't read that thread yet
  50. dwd jonas’, I honestly don't know. None were explicitly mentioned.
  51. dwd jonas’, Which itself is a procedural reason for not advancing.
  52. dwd So as such, given the lack of clarity there, I'll be -1 on this.
  53. jonas’ indeed
  54. Zash mod_smacks for Prosody does support 198 on s2s, but it's disabled by default and I don't think anyone ever enabled it
  55. Zash no resumption tho
  56. dwd Zash, Right, unclear what resumption would do for S2S.
  57. jonas’ resending stanzas which weren’t acked?
  58. dwd jonas’, Depends if they weren't already bounced.
  59. jonas’ mmm
  60. jonas’ okay, that’s a rabbit hole we shouldn’t go down in this context
  61. dwd Quite.
  62. jonas’ moving on
  63. Ge0rG so -1 then
  64. jonas’ 4c) Deviced on advancement of XEP-0368 Title: SRV records for XMPP over TLS URL: https://xmpp.org/extensions/xep-0368.html Abstract: This specification defines a procedure to look up xmpps-client/xmpps-server SRV records (for direct TLS connections) in addition to xmpp-client/xmpp-server and mix weights/priorities.
  65. moparisthebest (I promised to make some changes to XEP-0368, mostly clerical, but one SHOULD to a MAY)
  66. jonas’ I am -1 on 4c, since there need to be some changes made
  67. Ge0rG -1 on 4c as well, I liked the proposed wording
  68. jonas’ goes to dig up the proposed wording
  69. Zash on-list
  70. daniel On list. I'm not caught up on that
  71. dwd I'll take "I promised to make some changes" as a "update coming", so -1 for now.
  72. Ge0rG I think that leaving this to clients is good, because right now, priorizing DirectTLS over STARTSSL will add an RTT on servers without DirectTLS SRV records
  73. dwd I'm also unclear on ALPN implementation.
  74. dwd Oh, and this reminds me - I have AOB, jonas’
  75. jonas’ alright, changes will happen here, so moving on
  76. jonas’ dwd, noted
  77. jonas’ 4d) Proposed XMPP Extension: Extended Channel Search URL: https://xmpp.org/extensions/inbox/extended-channel-search.html Abstract: This specification provides a standardised protocol to search for public group chats. In contrast to XEP-0030 (Service Discovery), it works across multiple domains and in contrast to XEP-0055 (Jabber Search) it more clearly handles extensibility.
  78. jonas’ Unsurprisingly, I’m +1 on that one.
  79. daniel +1
  80. Zash +1
  81. dwd +1
  82. Ge0rG I have issues with that, mainly regarding the discoverability of whether the service is a local search for the given host domain or a proxy
  83. Ge0rG +1
  84. jonas’ Ge0rG, me too, I intend to fix those in Experimental
  85. jonas’ excellent, next
  86. jonas’ 4e) Authorship of XEP-0044 Title: Full Namespace Support for XML Streams Abstract: A description of the use of namespaces within Jabber.
  87. Zash jonas’, was this the one mentioning something about 0004? I didn't see it
  88. jonas’ Zash, yes, in the Design Considerations section
  89. jonas’ I would like to take authorship of XEP-0044, polish it, add namespaced attributes and a stream feature to it and bring it back on TRack
  90. jonas’ I would like to take authorship of XEP-0044, polish it, add namespaced attributes and a stream feature to it and bring it back on Track
  91. jonas’ I tried to contact the author already, but neither did I get a reply nor can I find the sent mail, so maybe I didn’t
  92. jonas’ ah, it’s stuck in my clients outbox
  93. Ge0rG I motion that jonas’ re-sends that email, and if no response happens within of 14d, he may take over authorship
  94. jonas’ resent it now, so we should probably move that
  95. jonas’ resent it now, so we should probably move that agendum
  96. jonas’ alright
  97. jonas’ 5) Outstanding Votes
  98. jonas’ I think Zash still has one pending on Trust Messages
  99. jonas’ (noting that we are on two +1 and two ±0 at the moment)
  100. jonas’ (expires in +1w)
  101. Zash +1 then
  102. jonas’ alright, done
  103. jonas’ 6) Date of Next
  104. jonas’ +1w wfm, though I might both be late and have to leave on time. Meeting at work before, burgers afterwards.
  105. Ge0rG I'm going to miss +1W
  106. dwd +1w WFM.
  107. jonas’ so if someone volunteered to chair (I’ll send an agenda, of course) that’d be great
  108. Zash +1w fwm
  109. daniel +1w wfm
  110. jonas’ looks at dwd
  111. Ge0rG jonas’: maybe you should announce AOB first
  112. jonas’ can do that
  113. jonas’ let’s hope someone will be there next week to chair then ;)
  114. jonas’ 7) AOB
  115. jonas’ dwd had some, so mic to you
  116. dwd Yeah...
  117. dwd So XEP-0001 says that to move to Final, a spec needs two implementations, etc.
  118. dwd But we're not clear if that means that every optional part needs implementing, and we're not clear on whether this might be one client and one server.
  119. jonas’ true
  120. dwd I've always just assumed that we demand the same levels as the IETF, which would be 2xClient and 2xServer covering all optional parts.
  121. daniel That sounds sensible
  122. pep. So Pubsub and MUC will never be Final?
  123. dwd Does anyone think this is important enough to specify properly in XEP-0001, and does anyone have any views on this?
  124. pep. (who implements everything?)
  125. jonas’ dwd, that indeed sounds sensible
  126. Ge0rG pep.: zinid does?
  127. dwd pep., The idea would be that a spec moving to Final either gets the weird bits nobody actually does removed, or at least moved to a different XEP.
  128. jonas’ and ..... highly unlikely to ever apply to MUC and PubSub, indeed.
  129. Ge0rG dwd: it's a good idea. Somebody™ should make it happen!
  130. pep. yay 1 server implementation, 3 to go
  131. daniel In practice the number of implementations never seems to be an issue
  132. moparisthebest then there are odd xeps like 368, where there are 3 parts, 1 client, and 2 server, all servers implemented 1 of them before 368, but I'm not sure we have 2 impls of the 2nd part
  133. jonas’ daniel, in practice, we haven’t tried to Final '45 yet ;)
  134. dwd daniel, Normally, no - specs are either widely implemented or not at all.
  135. jonas’ dwd, if you prepare a patch for '1, can you remind me to update the CFE template to specifically instruct to mention pieces which were left out in the implementation?
  136. dwd moparisthebest, ALPN support in XEP-0368 would be an interesting case in point, actually.
  137. dwd jonas’, Yes, happy to do that.
  138. jonas’ either way, in this non-vote, I’m +1 to making this clear in '1 and to adhere to IETF standards
  139. dwd So consensus is that I'll take this on, pen some text, get agreement on lists and prepare a patch for this and CFE template?
  140. jonas’ needs to be sanctioned by board either way
  141. jonas’ dwd, yes
  142. dwd OK, will do.
  143. Zash Clarification is good.
  144. moparisthebest dwd, that's true also, I was more meaning all servers supported listening for TLS on c2s, but how many 1) listen on TLS for s2s 2) connect TLS for s2s
  145. moparisthebest I think maybe just your Metre ?
  146. dwd moparisthebest, And Openfire - I think Guus did it there anyway.
  147. Zash Prosody can if you enable port multiplexing
  148. Zash Listen, not connect tho.
  149. dwd Anyway, that's me done, jonas’
  150. jonas’ anyone else any AOB?
  151. daniel None here
  152. Ge0rG My usual meta-oob comes and goes.
  153. jonas’ we’re running out of time either way
  154. jonas’ Ge0rG, I’m not sure which one that would be, does it fit in 30s?
  155. Ge0rG jonas’: of course not. It's about persistence of message errors.
  156. jonas’ ew, right
  157. jonas’ then:
  158. jonas’ As a closing note, I’d like to encourage all Council members to read up and potentially advance on this thread: https://mail.jabber.org/pipermail/standards/2020-January/036870.html
  159. Ge0rG Or rather, that is one of three or so meta-OOBs that I have around
  160. jonas’ And with that:
  161. jonas’ 8) Ite Meeting Est
  162. jonas’ thank you all
  163. jonas’ thank you, Tedd
  164. Ge0rG thank you, jonas’
  165. Zash Thanks all
  166. dwd Ge0rG, Didn't I handle persisting message errors somewhere in XEP-0427?
  167. jonas’ (at some point, when Tedd finally disappears into the magic cloud of dust they must’ve come from, council chairs will still say that in the hopes to summon minutes.)
  168. jonas’ (at some point, when Tedd eventually disappears into the magic cloud of dust they must’ve come from, council chairs will still say that in the hopes to summon minutes.)
  169. Ge0rG > The second form, "full", presents every message stanza in the results, including all fastenings, errors, and so on.
  170. Ge0rG dwd: I don't think that's normative.
  171. Ge0rG jonas’: it will be one of those arcane procedures nobody knows the reasons for
  172. dwd Ge0rG, That is normative. It's a statement of fact. I can put MUST somewhere to clarify though.
  173. Ge0rG dwd: my point is: I want that to be explicit and well-visible to all developers
  174. Ge0rG and not part of a very new XEP that is still being rewritten
  175. dwd Ge0rG, Sure. I need to do a fairly extensive pass over that spec; I'll make it clear that an implication of supporting the spec for servers is that they need to store everything inclusing errors.
  176. Ge0rG dwd: still, I'd like to keep that separate
  177. dwd Ge0rG, Split out "simplified" and "full" from XEP-0427?
  178. Ge0rG dwd: split out "you MUST store message errors in MAM"
  179. Ge0rG dwd: split out "you MUST store message errors in MAM and Carbon-copy them everywhere"
  180. Guus > moparisthebest, And Openfire - I think Guus did it there anyway. Yes, but has a bug.
  181. moparisthebest buggy implementations probably still count as implementations? :) good to know though
  182. moparisthebest Guus, does openfire do ALPN at all?
  183. moparisthebest ALPN support seems far more widespread today than just a few years ago when XEP-0368 was written, thanks http/2 I guess!
  184. Guus moparisthebest: don't think so. Seem to recall it was not supported in java 8
  185. moparisthebest java unsupported-for-over-a-year-now ? yea probably not :)
  186. moparisthebest looks like it's been supported since Java 9 though, and 13 is the only supported version of java, until next month when 14 will be
  187. Guus I think it is in newer versions, but Openfire retains compatibility with older Kava
  188. Guus I think it is in newer versions, but Openfire retains compatibility with older Java
  189. moparisthebest Conversations was the first impl and it always supported ALPN, Gajim I think supports ALPN, I don't think Dino does but not sure anymore
  190. moparisthebest jonas’, does aioxmpp ?
  191. jonas’ moparisthebest, I don’t think so
  192. jonas’ oh it does
  193. moparisthebest *can* it? (does python let you?)
  194. moparisthebest oh cool
  195. jonas’ if the PyOpenSSL version is recent enough
  196. moparisthebest anything that supports http2 supports ALPN so that should be fairly widespread at this point
  197. jonas’ and it’ll log a warning if DirectTLS is attempted and PyOpenSSL doesn’t support ALPN
  198. jonas’ https://github.com/horazont/aioxmpp/blob/devel/aioxmpp/connector.py#L296-L307
  199. moparisthebest that's also where it gets hairy, server-side alpn support, probably most servers don't but then it's not the xmpp server's job to proxy to nginx or whatever
  200. moparisthebest nginx and sslh both support this though, probably haproxy and others too
  201. moparisthebest "support" or "implementations" is hard to define
  202. jonas’ I think in this case it means that the server side mustn’t break if the client attempts ALPN in a standard-conformant way
  203. jonas’ I think in this case it means that the server side mustn’t break if the client attempts xmpp-related ALPN in a standard-conformant way
  204. moparisthebest yep and that's always been true even when servers just supported "legacy ssl" before 368
  205. moparisthebest they didn't recognize the TLS extension and just ignored it