XMPP Council - 2023-04-12

  1. daniel

    it's time

  2. Ge0rG

    good morning everyone!

  3. daniel

    1) roll call

  4. jonas’


  5. Ge0rG

    I'm finally back

  6. larma


  7. daniel


  8. daniel

    ah he said last week that he wont be here I think

  9. daniel

    2) Agenda bashing

  10. daniel

    nothing to bash

  11. daniel

    3) Editors update

  12. daniel

    I don’t have one this week but i'll try to compose a list for next week now that the list is working again

  13. daniel

    4) Items for voting

  14. daniel

    a) Proposed Extension: SASL Upgrade Tasks https://xmpp.org/extensions/inbox/xep-scram-upgrade.html

  15. daniel


  16. Ge0rG

    I'm quite lacking in SCRAM things, but this looks good from a brief review, so +1

  17. Kev

    Be aware that the lists are not 100% working at the moment. Archives liable to not be there etc.

  18. jonas’


  19. larma

    I guess it's good enough to start with, even though I think there are some issues with it, so +1

  20. daniel

    b) XEP-0198: Add section defining SASL2 and BIND2 interaction https://github.com/xsf/xeps/pull/1215

  21. daniel


  22. Ge0rG

    This is still blocked by advancement of BIND2?

  23. jonas’


  24. daniel

    it was previously blocked by bind 2 not being published. whether or not it should be blocked by bind 2 not being stable is up for debate

  25. Ge0rG


  26. daniel

    i'm leaning towards 'no' hence my +1 vote

  27. Ge0rG

    I can get behind that

  28. larma

    I'm confused because 90% of that PR is already in 0386?

  29. daniel

    is it?

  30. daniel

    i think that's just examples not normative

  31. larma

    e.g. "Note: If the client included a <resume/> element in its SASL2 negotiation, that MUST be processed first by the server. If that resumption is successful, the server MUST skip resource binding (a resumed session already has a resource bound) and MUST entirely ignore the <bind/> request."

  32. larma

    same sentence in both XEPs

  33. daniel

    maybe we forgot to remove them from bind 2... ?

  34. daniel

    i just remember that council was asked do you want this in bind 2 or in SM or in a new xep and we said we want this in SM

  35. larma

    there's also at least one thing that's probably wrong in the PR "the server adds a <feature/> element in the namespace "urn:xmpp:sm:3" into the <inline/> element of BIND2 which is sent in the stream features" -> bind 2 uses "<feature var="urn:xmpp:sm:3" />", no namespace here

  36. larma

    it's "just" wording, but I don't like adding wrong wording to a stable XEP

  37. daniel

    that’s fair.

  38. daniel

    do you want to veto until this is fixed?

  39. tmolitor

    well, I guess that's because I created the XEP when BIND2 syntax wasn't stable yet

  40. larma

    yes, I'll go through the PR and see if there are other issues

  41. tmolitor


  42. daniel

    but generally speaking do we still agree that this belongs into SM?

  43. larma

    and then let tmolitor know 🙂

  44. tmolitor

    larma, sure :)

  45. daniel

    and by extension that duplicate bits from bind 2 should probably be removed?

  46. tmolitor

    removed where? in bind2 or in 0198?

  47. daniel

    ok I'm recording a -1 for now (just so it doesn’t expire and goes through accidentially)

  48. larma

    daniel, yes, thanks

  49. daniel

    i meant removed from bind2

  50. daniel

    but it was framed as a question

  51. larma

    yes, I would remove it from bind2 and have sm only show up in bind2 in examples, but not beyond that

  52. daniel

    ok. let's move on then

  53. daniel

    c) Reconsider 'Proposed Extension: Content Types in Messages' https://xmpp.org/extensions/inbox/content-types.html

  54. daniel


  55. daniel

    personally i'm not a fan. but that shouldn’t stop it from being a XEP

  56. Ge0rG

    What's the normative action behind "reconsider"? A new last call?

  57. tmolitor

    MattJ: can you update bind2 accordingly?

  58. daniel

    we are voting to accept it as experimental

  59. daniel

    it is in inbox

  60. larma

    Ge0rG, think of it as being resubmitted as protoxep

  61. Ge0rG

    +1 then

  62. Kev

    I think the main reason to -1 it would be if it was considered actively harmful to adopt (which original Council did consider), or if nothing has changed in the interim.

  63. larma

    I've very mixed feeling on this one. I'm +1 because I don't want to block something from experimental that fits the formal requirements, but I have high doubts that this will be good for the ecosystem and I already fear people sending around markdown in various incompatible flavors arguing that it's "supported" by this XEp

  64. larma

    I've very mixed feeling on this one. I'm +1 because I don't want to block something from experimental that fits the formal requirements, but I have high doubts that this will be good for the ecosystem and I already fear people sending around markdown in various incompatible flavors arguing that it's "supported" by this XEP

  65. jonas’

    I share the concerns of larma

  66. Kev

    I haven't looked to see if there's anything in procedure that would prevent future Councils accepting what was previously rejected.

  67. jonas’

    also the text/xml encoding example in there gives me headaches

  68. Ge0rG

    What's the original author's stance?

  69. Kev

    They liked it then and they still like it now.

  70. daniel

    i don’t think "fits the ecosystem" is something that matters at this stage

  71. daniel

    i think that's a question that will come up in last call

  72. Kev

    > i don’t think "fits the ecosystem" is something that matters at this stage I think "not actively harmful to the ecosystem" is almost the only thing that matters at this stage.

  73. larma

    Can we instantly issue a last call and then reject it? 😀

  74. Kev

    Was that a serious procedural question?

  75. larma


  76. larma

    But if it was proposed for last call now, I would vote to reject and I don't see how this can be changed without fundamentally changing the idea of the XEP

  77. Ge0rG

    larma: I think the procedural difference is that the community gets a chance to discuss it, and to convince you of its importance

  78. jonas’

    I'm +1.

  79. larma

    Well, if one entirely removed the alternative encodings I'd probably be fine with it

  80. jonas’

    Even though this may not be fully useful or even good for messaging contexts, I guess it makes sense to have something like this at least for pubsub use-cases (atom).

  81. daniel

    fwiw I think the author specifically wanted those

  82. larma

    Actually, you can just do content type multipart/alternative then 😉

  83. Kev

    > I would like to re-introduce this proposal for publication as an experimental XEP. More and more use Markdown (as an example). While there are objections by some to use Markdown, the purpose of the XEP is not to force those that do not want to use Markdown, to use it, but to allow those that want to send Markdown with a common way to do it, without just sending it as plain text (as many do). The extension is not focused on Markdown, but tries to solve the more general problem on how to send content, regardless of format, in a way that is understandable by those that support that format, as well as those that don’t. It reuses the common content types available in other protocols on the Internet to do so, so the pattern is well known and works in other non-XMPP-based protocols.

  84. daniel

    because multiple contents is one of the main points the previous council complain about too

  85. Kev

    (From Peter Waher)

  86. Link Mauve

    jonas’, Atom already has this, all three elements of title, summary and content can be either plain text, &lt;-encoded HTML, or embedded XHTML.

  87. larma

    I'd like to point out that RFC 7763 has a specific section to mention that markdown should not be used for publishing, but only for writing and editing. If one wants to use markdown in XMPP, the "correct" way to do so would be to convert it to (X)HTML before sending

  88. larma

    daniel, please record a 0 for me

  89. daniel

    we are technically running over but we have 2 more items to vote on. is everyone ok by extending this meeting by 15-20 mins?

  90. larma

    fine by me

  91. daniel

    Ge0rG, jonas’ are you still here or should we continue next week?

  92. Ge0rG

    I'm sorry I had to get on an urgent call and am afk

  93. daniel

    OK. I’ll move the remaining two items to next week

    👍️ 1
  94. daniel

    Pending votes

  95. daniel

    i’m going to quickly take the chance to vote on publish_node_full +1

  96. jonas’

    I am still here

  97. jonas’


  98. jonas’

    do you have a link to pubsub node full please?

  99. larma


  100. jonas’

    also, I'd like to join larma in a +0 on the content type thing, I think that more appropriately reflects what I think of it

  101. daniel

    https://github.com/xsf/xeps/pull/1275 <= that's from two weeks ago and you voted +1

  102. jonas’

    ah great :)

  103. daniel

    jonas’, I've changed your vote

  104. daniel


  105. daniel

    6) Date of next

  106. daniel

    +1w wfm

  107. jonas’

    +1w wfm

  108. larma

    I'm travelling next week, but will likely be able to make it nonetheless

  109. daniel

    larma, noted

  110. daniel

    7) AOB

  111. daniel

    please note that we are already over time so unless it's urgent just tell me to put it on the agenda for next week

  112. daniel

    ok assuming nothing urgent then

  113. daniel

    8) Close

  114. daniel

    Thanks all

  115. larma

    Thanks daniel

  116. jonas’

    Thanks daniel