XMPP Council - 2022-01-12


  1. moparisthebest

    hello ! apologies about last week, just the stupid alarm didn't go off, dumbest excuse possible

  2. daniel

    Hi

  3. jonas’

    well, better for a council meeting than, say, for your mother's 50th birthday

  4. daniel

    It's time again

  5. jonas’

    (completely made up example about calendar alerts not working. ha. ha.)

  6. daniel

    1) Roll call

  7. jonas’ is here

  8. larma

    👋️

  9. Ge0rG

    Good morning!

  10. daniel

    i'll give you some time while i very quickly grab a coffee

  11. jonas’

    good luck

  12. moparisthebest

    let's time him to see what he calls quick

  13. jonas’

    there must be some pun in there with quicksy, daniel, and calling, but I can't find it

  14. moparisthebest

    also something about coffee and java...

  15. jonas’

    so many possibilities should be there

  16. daniel

    i see you've been able to entertain yourself without me

  17. daniel

    2) agenda bashing

  18. daniel

    there is a late addition via pep and jonas’

  19. daniel

    3) editors update

  20. daniel

    a) An Update to XEP-0353 (Jingle Message Initiation) has been released. (https://xmpp.org/extensions/xep-0353.html)

  21. daniel

    cool update btw thanks to thilo for writing that up

  22. daniel

    4) items for voting

  23. daniel

    a) https://github.com/xsf/xeps/pull/1140

  24. daniel

    there is a normative change in there technically

  25. jonas’

    yes

  26. jonas’

    hence it goes by us :)

  27. larma

    lgtm +1

  28. jonas’

    I am +1, any other behaviour than the one described doesn't make sense

  29. daniel

    i personally thing it's fine. because what else would you do with those headers

  30. daniel

    i'd consider every implementation that doesn’t include the headers buggy

  31. jonas’

    it also tightens down the corner case of multiple values for a single header being present

  32. daniel

    so +1 from me

  33. Ge0rG

    do we have a rendered delta? ;)

  34. moparisthebest

    I think some HTTP libs don't allow you to specify header order

  35. jonas’

    Ge0rG, I find the github diff reasonably well readable

  36. jonas’

    moparisthebest, order of values, not order of headers

  37. moparisthebest

    but that's a them-problem I reckon, so also +1 from me

  38. jonas’

    oh

  39. jonas’

    moparisthebest, that's a very good point

  40. jonas’

    -1

  41. daniel

    > I think some HTTP libs don't allow you to specify header order that crossed my mind too

  42. Ge0rG

    I have a small nitpick about "These headers MUST be included in the HTTP PUT request" - it's not clear whether it relates to the headers that are in the XML or to the three allowed header names.

  43. jonas’

    -1: The wording has a bug which can easily be misread as "the headers' order must be preserved", while the intent was to preserve the order of values of a given header, if multiple values are given

  44. jonas’

    Ge0rG, yep, that was another bit

  45. jonas’

    I'll propose an updated wording in a minute

  46. jonas’

    pep., I'll hijack your PR if I may

  47. moparisthebest

    oh, well yea it would be best if header order wasn't required, especially if it wasn't intended

  48. Ge0rG

    also how do you sign a HTTP header?

  49. moparisthebest

    presumably you sign the header's value, but again, some wording

  50. Ge0rG

    there are schemes where signatures are sent out-of-band, and that wouldn't be compatible

  51. jonas’

    proposed fix for the wording: https://github.com/xsf/xeps/pull/1140/commits/85ff424a9e2aab8a4aab56fcd490c341ae50b3a5

  52. jonas’

    Ge0rG, there are standards for that, let's not go into that ;)

  53. larma

    thanks jonas’ for the hotfix 🙂

  54. jonas’

    Ge0rG, I'm sure HTTP header signing schemes are compatible with header reordering, as relative header order is AFAIK not guaranteed

  55. Ge0rG

    jonas’: there be dragons

  56. jonas’

    HTTP's dragons, not ours :)

  57. moparisthebest

    ok now I'm no-hesitation +1 :D

  58. jonas’

    I'll be +1 with my patch

  59. daniel

    ok. i'll restart voting *with* jonas' fix

  60. jonas’

    Ge0rG, we already tighten down the available headers, which restricts what can be done anyway

  61. larma

    +1

  62. Ge0rG

    jonas’: I'm +1 with your patch

  63. jonas’

    Ge0rG, tell that to daniel, I'm not chair anymore :)

  64. Ge0rG

    jonas’: I'm pretty sure that most http libraries won't honor the order of equally named headers

  65. daniel

    +1 here as well

  66. Ge0rG

    daniel: +1 ;)

  67. daniel

    i recorded your vote Ge0rG

  68. moparisthebest

    +1 again

  69. jonas’

    Ge0rG, let's not get into that here

  70. daniel

    ok great. moving on

  71. daniel

    b) XEP-0030: remove security considerations preventing requests on a bare JID (https://github.com/xsf/xeps/pull/1145)

  72. daniel

    i'm on list for that

  73. jonas’

    note that there's already a thread on list

  74. jonas’

    but I, too, am on-list

  75. jonas’

    haven't gotten around to read it yet

  76. moparisthebest

    also on-list, worries me a bit

  77. jonas’

    (the thread has the subject [XEP-0030] we can't get basic information on a bare JID without presence subscription, it's also linked from the PR)

  78. jonas’

    ack, -1 is my first inclination, too

  79. Ge0rG

    on-list

  80. jonas’

    but I'll read the rationale first, so please don't record that yet

  81. larma

    on-list

  82. daniel

    ok thank you

  83. daniel

    5) Pending votes

  84. daniel

    Ge0rG and moparisthebest are pending on the four xeps proposed last week

  85. Ge0rG

    Yup.

  86. daniel

    note the pubsub namespace one has technically already been vetoed

  87. moparisthebest

    I'm +1 on all of them except Proposed XMPP Extension: PubSub Namespaces where I'm -1

  88. jonas’

    I'm not sure what I voted on PubSub Namespaces, but the discussion has confirmed my perception that it should be -1 until fixed up as discussed on list

  89. Ge0rG

    I'm still on-list

  90. larma

    I'm 0 on pubsub-ns, I feel there is need for clarification, but this is not how it should be

  91. daniel

    jonas’, i did record a -1 for you

  92. jonas’

    excellent

  93. jonas’

    speaking of, can I get a link to the current spreadsheet of doom? I lost it somehow :)

  94. jonas’

    it's useful for editor work

  95. moparisthebest

    for logs sake I'm +1 on: https://xmpp.org/extensions/inbox/compatibility-fallback.html https://xmpp.org/extensions/inbox/call-invites.html https://xmpp.org/extensions/inbox/replies.html

  96. moparisthebest

    https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit#gid=0

  97. jonas’

    moparisthebest, thanks :)

  98. daniel

    moparisthebest, yes thank you i recorded that

  99. moparisthebest

    also I swear I voted -1 on https://github.com/xsf/xeps/pull/1126 but it was rejected already so meh :)

  100. daniel

    6) Date of next

  101. daniel

    +1w wfm

  102. jonas’

    +1w wfm most likely

  103. moparisthebest

    good for me

  104. larma

    wfm as well

  105. Ge0rG

    +1W WFM, but I'll be on vacation the following two weeks

  106. daniel

    7) AOB

  107. jonas’

    covid19: "well, we'll see about that"

  108. jonas’

    no AOB from me

  109. moparisthebest

    no AOB

  110. larma

    same here

  111. daniel

    8) Close

  112. daniel

    Thank you everyone

  113. larma

    Thanks daniel 🙂

  114. jonas’

    Thanks daniel :)

  115. moparisthebest

    thanks!

  116. moparisthebest

    as an aside, the http header thing was fresh in my mind, because curl preserves both header order and case, and they recently added a backend using hyper (rust http lib) which preserves neither, which curl considered a bug :)

  117. larma

    What else would I use to craft special http requests than curl. I would consider this a bug as well if they lost those features...

  118. jonas’

    larma, openssl s_client ;)

  119. moparisthebest

    I just use curl for virtually everything http based

  120. larma

    jonas’: that's already my XMPP client of choice :)

  121. jonas’

    larma, see, it's a multi-protocol client ;)

  122. moparisthebest

    larma, great job on all these XEPs by the way, seeing XEPs created with actual public code behind them is infinitely better than "in theory" XEPs

  123. pep.

    “jonas’> pep., I'll hijack your PR if I may” < Sure.