XMPP Council - 2020-02-26


  1. moparisthebest has left

  2. stpeter has left

  3. stpeter has joined

  4. paul has left

  5. alin has joined

  6. stpeter has left

  7. alin has left

  8. moparisthebest has joined

  9. paul has joined

  10. moparisthebest has left

  11. Tobias has joined

  12. paul has left

  13. Ge0rG has left

  14. moparisthebest has joined

  15. undefined has joined

  16. paul has joined

  17. Ge0rG has joined

  18. guy has joined

  19. susmit88 has joined

  20. undefined has left

  21. undefined has joined

  22. undefined has left

  23. undefined has joined

  24. undefined has left

  25. undefined has joined

  26. susmit88 has left

  27. undefined has left

  28. undefined has joined

  29. debacle has joined

  30. undefined has left

  31. undefined has joined

  32. undefined has left

  33. undefined has joined

  34. Zash has left

  35. Zash has joined

  36. debacle has left

  37. debacle has joined

  38. undefined has left

  39. undefined has joined

  40. undefined has left

  41. undefined has joined

  42. undefined has left

  43. undefined has joined

  44. undefined has left

  45. undefined has joined

  46. undefined has left

  47. undefined has joined

  48. Holger has left

  49. undefined has left

  50. undefined has joined

  51. Holger has joined

  52. undefined has left

  53. undefined has joined

  54. undefined has left

  55. undefined has joined

  56. Guus has left

  57. Guus has joined

  58. Holger has left

  59. undefined has left

  60. undefined has joined

  61. Holger has joined

  62. susmit88 has joined

  63. undefined has left

  64. undefined has joined

  65. undefined has left

  66. undefined has joined

  67. susmit88 has left

  68. undefined has left

  69. undefined has joined

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

  71. Wojtek has joined

  72. undefined has left

  73. undefined has joined

  74. paul has left

  75. undefined has left

  76. undefined has joined

  77. paul has joined

  78. undefined has left

  79. undefined has joined

  80. undefined has left

  81. undefined has joined

  82. undefined has left

  83. undefined has joined

  84. paul has left

  85. paul has joined

  86. paul has left

  87. jonas’

    will be on time

  88. paul has joined

  89. paul has left

  90. paul has joined

  91. paul has left

  92. paul has joined

  93. paul has left

  94. paul has joined

  95. susmit88 has joined

  96. Zash

    Just got home and sat down

  97. jonas’

    kind of did the same

  98. jonas’

    1) Roll Call

  99. jonas’ is present

  100. Zash 2

  101. daniel

    Here

  102. Ge0rG !

  103. Zash

    dwd?

  104. jonas’

    assuming that dwd will appear, moving on

  105. jonas’

    (we have quorum either way)

  106. jonas’

    2) Agenda Bashing

  107. jonas’

    anything to add?

  108. jonas’

    probably not

  109. Ge0rG

    We need shorter agendas in the future

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

  111. jonas’

    (note the LC which came in after I sent the email yesterday)

  112. jonas’

    4) Items for a Vote

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

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

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

  116. jonas’

    so -1 from my side

  117. Ge0rG

    Some PEP access questions came up, it would make sense to consider those first

  118. jonas’

    so -1 from my side, with the intent of having someone™ fix this

  119. jonas’

    so -1 from my side, with the intent of having someone™ fix this; so no rejection, just back to Experimental for fixes

  120. Ge0rG

    -1 as well due to that

  121. daniel

    Yes I'm fine with updating the pep stuff on relative short notice

  122. daniel

    We can restart next week or so

  123. jonas’

    sounds like a plan

  124. Zash

    -1 (I agree with jonas’ )

  125. dwd

    Hiya folks, sorry for being late.

  126. stpeter has joined

  127. daniel

    -1

  128. jonas’

    that’s massively Veto’d then

  129. jonas’

    next:

  130. dwd

    I can add another veto if you want. :-)

  131. jonas’

    dwd, would be great for formal reasons :)

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

  133. dwd

    -1, for the reasons stated by others.

  134. Ge0rG

    dwd: can you also add more veto reasons?

  135. jonas’

    I am on-list, because I haven’t been able to catch up on the thread yet

  136. Ge0rG

    I'm not sure regarding 0198. It's doing its job great, except for the unclear resume host connection mechanism

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

  138. Zash

    Ge0rG, s2s?

  139. jonas’

    we have zero s2s implementations, do we?

  140. Ge0rG

    So we want actual experience with s2s 0198?

  141. jonas’

    question is whether that even allows us to move it forward

  142. daniel

    -1. I think I (and others) brought up vaild but fixable concerns

  143. Zash

    on-list, haven't read that thread yet

  144. dwd

    jonas’, I honestly don't know. None were explicitly mentioned.

  145. dwd

    jonas’, Which itself is a procedural reason for not advancing.

  146. dwd

    So as such, given the lack of clarity there, I'll be -1 on this.

  147. jonas’

    indeed

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

  149. Zash

    no resumption tho

  150. dwd

    Zash, Right, unclear what resumption would do for S2S.

  151. jonas’

    resending stanzas which weren’t acked?

  152. dwd

    jonas’, Depends if they weren't already bounced.

  153. jonas’

    mmm

  154. jonas’

    okay, that’s a rabbit hole we shouldn’t go down in this context

  155. dwd

    Quite.

  156. jonas’

    moving on

  157. Ge0rG

    so -1 then

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

  159. moparisthebest

    (I promised to make some changes to XEP-0368, mostly clerical, but one SHOULD to a MAY)

  160. jonas’

    I am -1 on 4c, since there need to be some changes made

  161. undefined has left

  162. Ge0rG

    -1 on 4c as well, I liked the proposed wording

  163. jonas’ goes to dig up the proposed wording

  164. Zash

    on-list

  165. daniel

    On list. I'm not caught up on that

  166. dwd

    I'll take "I promised to make some changes" as a "update coming", so -1 for now.

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

  168. dwd

    I'm also unclear on ALPN implementation.

  169. dwd

    Oh, and this reminds me - I have AOB, jonas’

  170. jonas’

    alright, changes will happen here, so moving on

  171. jonas’

    dwd, noted

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

  173. jonas’

    Unsurprisingly, I’m +1 on that one.

  174. daniel

    +1

  175. Zash

    +1

  176. dwd

    +1

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

  178. Ge0rG

    +1

  179. jonas’

    Ge0rG, me too, I intend to fix those in Experimental

  180. jonas’

    excellent, next

  181. jonas’

    4e) Authorship of XEP-0044 Title: Full Namespace Support for XML Streams Abstract: A description of the use of namespaces within Jabber.

  182. Zash

    jonas’, was this the one mentioning something about 0004? I didn't see it

  183. jonas’

    Zash, yes, in the Design Considerations section

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

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

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

  187. jonas’

    ah, it’s stuck in my clients outbox

  188. Ge0rG

    I motion that jonas’ re-sends that email, and if no response happens within of 14d, he may take over authorship

  189. jonas’

    resent it now, so we should probably move that

  190. jonas’

    resent it now, so we should probably move that agendum

  191. jonas’

    alright

  192. jonas’

    5) Outstanding Votes

  193. jonas’

    I think Zash still has one pending on Trust Messages

  194. jonas’

    (noting that we are on two +1 and two ±0 at the moment)

  195. jonas’

    (expires in +1w)

  196. Zash

    +1 then

  197. jonas’

    alright, done

  198. jonas’

    6) Date of Next

  199. jonas’

    +1w wfm, though I might both be late and have to leave on time. Meeting at work before, burgers afterwards.

  200. Ge0rG

    I'm going to miss +1W

  201. dwd

    +1w WFM.

  202. jonas’

    so if someone volunteered to chair (I’ll send an agenda, of course) that’d be great

  203. Zash

    +1w fwm

  204. daniel

    +1w wfm

  205. jonas’ looks at dwd

  206. Ge0rG

    jonas’: maybe you should announce AOB first

  207. jonas’

    can do that

  208. jonas’

    let’s hope someone will be there next week to chair then ;)

  209. jonas’

    7) AOB

  210. jonas’

    dwd had some, so mic to you

  211. dwd

    Yeah...

  212. dwd

    So XEP-0001 says that to move to Final, a spec needs two implementations, etc.

  213. susmit88 has left

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

  215. jonas’

    true

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

  217. daniel

    That sounds sensible

  218. pep.

    So Pubsub and MUC will never be Final?

  219. dwd

    Does anyone think this is important enough to specify properly in XEP-0001, and does anyone have any views on this?

  220. pep.

    (who implements everything?)

  221. jonas’

    dwd, that indeed sounds sensible

  222. Ge0rG

    pep.: zinid does?

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

  224. jonas’

    and ..... highly unlikely to ever apply to MUC and PubSub, indeed.

  225. Ge0rG

    dwd: it's a good idea. Somebody™ should make it happen!

  226. pep.

    yay 1 server implementation, 3 to go

  227. daniel

    In practice the number of implementations never seems to be an issue

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

  229. jonas’

    daniel, in practice, we haven’t tried to Final '45 yet ;)

  230. dwd

    daniel, Normally, no - specs are either widely implemented or not at all.

  231. 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?

  232. dwd

    moparisthebest, ALPN support in XEP-0368 would be an interesting case in point, actually.

  233. dwd

    jonas’, Yes, happy to do that.

  234. jonas’

    either way, in this non-vote, I’m +1 to making this clear in '1 and to adhere to IETF standards

  235. 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?

  236. jonas’

    needs to be sanctioned by board either way

  237. jonas’

    dwd, yes

  238. dwd

    OK, will do.

  239. Zash

    Clarification is good.

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

  241. moparisthebest

    I think maybe just your Metre ?

  242. dwd

    moparisthebest, And Openfire - I think Guus did it there anyway.

  243. Zash

    Prosody can if you enable port multiplexing

  244. Zash

    Listen, not connect tho.

  245. dwd

    Anyway, that's me done, jonas’

  246. jonas’

    anyone else any AOB?

  247. daniel

    None here

  248. Ge0rG

    My usual meta-oob comes and goes.

  249. jonas’

    we’re running out of time either way

  250. jonas’

    Ge0rG, I’m not sure which one that would be, does it fit in 30s?

  251. Ge0rG

    jonas’: of course not. It's about persistence of message errors.

  252. jonas’

    ew, right

  253. jonas’

    then:

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

  255. Ge0rG

    Or rather, that is one of three or so meta-OOBs that I have around

  256. jonas’

    And with that:

  257. jonas’

    8) Ite Meeting Est

  258. jonas’

    thank you all

  259. jonas’

    thank you, Tedd

  260. Ge0rG

    thank you, jonas’

  261. Zash

    Thanks all

  262. dwd

    Ge0rG, Didn't I handle persisting message errors somewhere in XEP-0427?

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

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

  265. Ge0rG

    > The second form, "full", presents every message stanza in the results, including all fastenings, errors, and so on.

  266. Ge0rG

    dwd: I don't think that's normative.

  267. Ge0rG

    jonas’: it will be one of those arcane procedures nobody knows the reasons for

  268. dwd

    Ge0rG, That is normative. It's a statement of fact. I can put MUST somewhere to clarify though.

  269. Ge0rG

    dwd: my point is: I want that to be explicit and well-visible to all developers

  270. Ge0rG

    and not part of a very new XEP that is still being rewritten

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

  272. Ge0rG

    dwd: still, I'd like to keep that separate

  273. dwd

    Ge0rG, Split out "simplified" and "full" from XEP-0427?

  274. Ge0rG

    dwd: split out "you MUST store message errors in MAM"

  275. Ge0rG

    dwd: split out "you MUST store message errors in MAM and Carbon-copy them everywhere"

  276. paul has left

  277. paul has joined

  278. larma has left

  279. Guus

    > moparisthebest, And Openfire - I think Guus did it there anyway. Yes, but has a bug.

  280. moparisthebest

    buggy implementations probably still count as implementations? :) good to know though

  281. moparisthebest

    Guus, does openfire do ALPN at all?

  282. moparisthebest

    ALPN support seems far more widespread today than just a few years ago when XEP-0368 was written, thanks http/2 I guess!

  283. Guus

    moparisthebest: don't think so. Seem to recall it was not supported in java 8

  284. moparisthebest

    java unsupported-for-over-a-year-now ? yea probably not :)

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

  286. Guus

    I think it is in newer versions, but Openfire retains compatibility with older Kava

  287. Guus

    I think it is in newer versions, but Openfire retains compatibility with older Java

  288. larma has joined

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

  290. moparisthebest

    jonas’, does aioxmpp ?

  291. jonas’

    moparisthebest, I don’t think so

  292. jonas’

    oh it does

  293. moparisthebest

    *can* it? (does python let you?)

  294. moparisthebest

    oh cool

  295. jonas’

    if the PyOpenSSL version is recent enough

  296. moparisthebest

    anything that supports http2 supports ALPN so that should be fairly widespread at this point

  297. jonas’

    and it’ll log a warning if DirectTLS is attempted and PyOpenSSL doesn’t support ALPN

  298. jonas’

    https://github.com/horazont/aioxmpp/blob/devel/aioxmpp/connector.py#L296-L307

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

  300. moparisthebest

    nginx and sslh both support this though, probably haproxy and others too

  301. moparisthebest

    "support" or "implementations" is hard to define

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

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

  304. moparisthebest

    yep and that's always been true even when servers just supported "legacy ssl" before 368

  305. moparisthebest

    they didn't recognize the TLS extension and just ignored it

  306. Syndace has left

  307. Syndace has joined

  308. daniel has left

  309. daniel has joined

  310. stpeter has left

  311. Tobias has left

  312. Tobias has joined

  313. undefined has joined

  314. undefined has left

  315. undefined has joined

  316. stpeter has joined

  317. larma has left

  318. larma has joined

  319. stpeter has left

  320. stpeter has joined

  321. Tobias has left

  322. Tobias has joined

  323. debacle has left

  324. paul has left

  325. Tobias has left

  326. Wojtek has left