XMPP Council - 2024-05-07


  1. daniel

    Hi

  2. daniel

    It's time

  3. daniel

    1) Roll call

  4. larma

    👋️

  5. moparisthebest

    Hello!

  6. daniel

    singpolyma, dan.caseley?

  7. singpolyma

    hello

  8. daniel

    2) Agenda bashing

  9. daniel

    nothing to bash I assume

  10. daniel

    3) Editiors update. I started the last call on Channel Binding and moved Avatar vCard conversation to stable (as per council votes)

  11. daniel

    4) Items for voting

  12. daniel

    a) PR: XEP-0030: Note known wart https://github.com/xsf/xeps/pull/1341

  13. daniel

    is the SHOULD too strong here?

  14. singpolyma

    because it's technically a breaking change?

  15. dan.caseley

    Apologies. Here.

  16. daniel

    would either non normative language or a MAY do?

  17. singpolyma

    I would support the SHOULD, but I can see the argument for MAY

  18. moparisthebest

    I tend to think SHOULD is fine, MUST would not be fine

  19. daniel

    i'm pretty much just asking / opening it up for debate

  20. daniel

    i don’t have strong feelings

  21. moparisthebest

    But SHOULD means if you don't you still comply...

  22. singpolyma

    moparisthebest: we're supposed to think of those as basically the same I think

  23. dan.caseley

    I agree with SHOULD.

  24. moparisthebest

    > moparisthebest: we're supposed to think of those as basically the same I think Hmm I don't think we SHOULD 😉

  25. singpolyma

    since what we actually want to do is remove the requirement entirely, but that would be much too much a breaking change, I'm in for SHOULD here

  26. moparisthebest

    +1 as-is with SHOULD

  27. daniel

    fair enough

  28. daniel

    +1

  29. singpolyma

    +1

  30. dan.caseley

    +1

  31. larma

    +1

  32. daniel

    b) PR: XEP-0045: Remove conflicting keyword in §7.2.2 https://github.com/xsf/xeps/pull/1342

  33. singpolyma

    the idea is to move to non-normative because a subset of this stuff has normative language about it elsewhere in the xep, correct?

  34. dan.caseley

    Interesting. Was it originally MAY because the server might not have those to send?

  35. moparisthebest

    > the idea is to move to non-normative because a subset of this stuff has normative language about it elsewhere in the xep, correct? I think so yes

  36. daniel

    I have very little context for that but yes

  37. daniel

    I guess the assumption is that the MAY weakens the MUST send subject

  38. singpolyma

    or could be read that way at least

  39. moparisthebest

    +1 it's at least less confusing than before, can always merge better language later

  40. singpolyma

    I think I agree that MAY reads strangely on a list that basically ends with "etc"

  41. daniel

    I mean i don’t really like how the entire sentence is phrased. but non normative language is probably more approriate here

  42. singpolyma

    +1

  43. daniel

    +1

  44. dan.caseley

    There's an argument for restructuring the sentence that makes all of this clearer, but this is an increment better. +1

  45. daniel

    larma?

  46. larma

    I don't see the conflict and I think it is the result of a misunderstanding

  47. singpolyma

    yes, but I think that's because the sentence is easy to misunderstand. this makes it slightly clearer

  48. larma

    Indeed 7.2.15 requires sending a message with empty subject, but it does not require to do so after joining which is what is described in 7.2.2

  49. larma

    I think 7.2.15 was misunderstood that the server must for all eternity send an empty subject after join if a subject was ever set, which I don't think was the intention (or is a good idea)

  50. larma

    If you misunderstand 7.2.15 like this, 7.2.2's MAY would indeed be a conflict

  51. singpolyma

    7.2.15 seems to say to me that you MUST always send a message with a subject, no matter if one was ever set or not

  52. singpolyma

    this could be to ensure you know when you are "joined" and live messages will now begin

  53. singpolyma

    additionally, 7.2.16 seems to have almost the same sentence as 7.2.2 but with SHALL in place of MAY

  54. singpolyma

    also why is SHALL a thing, isn't that just MUST?

  55. larma

    It is, and it is probably wrong here

  56. dan.caseley

    Yes, shall = must

  57. dan.caseley

    I thought the misinterpretation to be about what the MAY meant was optional. e.g. The server might not have room history to send, but if it does, it needs to wait for the presence broadcast before sending it.

  58. moparisthebest

    We can't remove a MUST, we can remove a conflicting MAY...

  59. larma

    The MUST is just untrue for obvious other reasons

  60. larma

    e.g. if the room is configured to not broadcast presence changes, it in fact MUST NOT broadcast presence changes even if 7.2.16 claims it does

  61. larma

    So it seems there are some weird conflicts there, but I'm not sure if this one change really improves the situation

  62. moparisthebest

    I don't think it makes it worse, but there's certainly room for more improvement

  63. dan.caseley

    ^this

  64. daniel

    yes I don’t know. larma convinced me that the situation is more complicated and I'm thinking about changing my vote to a 0

  65. daniel

    non normative language in that sentence is probably very slightly better

  66. daniel

    but the reasoning for the PR might be misguided

  67. larma

    I also just realize that current 7.1 should actually be the first subsection of what is now 7.2.

  68. Zash

    Perhaps there's some left-over confusion from the removal of the Groupchat 1.0 text?

  69. larma

    And then all these ordering stuff should be removed from everywhere else and just referred to the one section that defines the ordering of stuff

  70. larma

    Anyway, the PR does not worsen the current situation, so I guess I'm fine with it

  71. daniel

    larma, is this a +1 or a 0?

  72. larma

    +1

  73. daniel

    ok. moving on

  74. daniel

    5) Pending Votes

  75. larma

    And I heard people want to create an updated MUC XEP anyway (with all the modern features defined properly), so it's probably not worth fixing everything in this one

  76. daniel

    larma is pending on last call on xep-0421

  77. larma

    +1

  78. daniel

    6) Date of Next

  79. daniel

    +1w wfm

  80. larma

    +1w wfm

  81. dan.caseley

    +1w _probably_ wfm.

  82. dan.caseley

    I might get roped into family transport duties.

  83. singpolyma

    +1w wfm

  84. dan.caseley

    If I miss it, I'll catch up within a couple of hours.

  85. moparisthebest

    +1w wfm

  86. daniel

    7) AOB

  87. dan.caseley

    None

  88. daniel

    assuming none

  89. daniel

    8) Close

  90. daniel

    thank you all

  91. dan.caseley

    Thanks Daniel

  92. moparisthebest

    Thanks all!