XMPP Council - 2023-12-12


  1. nous

    This is cool

  2. dan.caseley

    Noticed that https://xmpp.org/extensions/xep-0484.html has a copyright date that's behind the publication date. Is that a choice or an error?

  3. singpolyma

    dan.caseley: it doesn't really matter, but see https://github.com/xsf/xeps/pull/1310 for solution

  4. Kev

    Yes, Flow's PR should fix this.

  5. dan.caseley

    ♥️

  6. daniel

    Heads up. I have some offline meeting right after our council meeting. I will try to get through today's meeting in fifteen minutes or so

  7. moparisthebest

    My body is ready

  8. daniel

    It's time.

  9. daniel

    1) roll call

  10. larma

    👋️

  11. daniel

    moparisthebest, dan.caseley, singpolyma:?

  12. moparisthebest

    Hello

  13. daniel

    We technically have quorum so moving on

  14. daniel

    2) Agenda Bashing

  15. daniel

    Any additions to the agenda?

  16. moparisthebest

    Nope

  17. daniel

    Assuming none

  18. dan.caseley

    Nope

  19. daniel

    3) Editors update

  20. singpolyma

    hi

  21. daniel

    I spare you the copy paste. But see the emails. Editor released a bunch of changes. Thank you Kev

  22. daniel

    4) Items for voting

  23. daniel

    a) XEP-0077: Specify account creation via HTTP as non-exclusive alternative to XMPP (https://github.com/xsf/xeps/pull/1299)

  24. singpolyma

    I'm fine with the substance of the change, but the new paragraph is pretty messy imo

  25. daniel

    -1 from my side. The language is weird. The justification for the change is now in the xep. I don't like changing final xeps without prior discussion

  26. Kev

    (Reminder that this is Final and therefore obliged to try to avoid breaking changes if at all possible)

  27. daniel

    Or at all for the most part

  28. singpolyma

    > The language is weird. The justification for the change is now in the xep I agree with both of these

  29. singpolyma

    (as being problems)

  30. singpolyma

    I don't think it's a breaking change since it wasn't disallowed before, and it's not clear why it was ever not recommended

  31. moparisthebest

    I'm not opposed to the principal but needs some work and discussion so -1 as-is but open to it changing

  32. Kev

    Isn't this the one that changes SHOULD NOT to MAY?

  33. daniel

    I get that the person who made the PR ran into some minor implementation problems but I don't think this justifies changing a final xep

  34. Zash

    Observation: There's already a "Needs List Discussion" label.

  35. singpolyma

    changes NOT RECOMMENDED to MAY

  36. Kev

    > changes NOT RECOMMENDED to MAY NOT RECOMMENDED == SHOULD NOT

  37. singpolyma

    sure, which is not the same as a ban. so it's not a breaking change

  38. daniel

    Note that individual implementations can still do it if they think it's absolutely necessary

  39. singpolyma

    right, for sure

  40. singpolyma

    changing to MAY just makes it more clear that this is reasonable to do. you have to assume it might happen either way due to being allowed already

  41. Kev

    > sure, which is not the same as a ban. so it's not a breaking change I don't think SHOULD NOT means what you think SHOULD NOT means :)

  42. MattJ

    SHOULD (NOT) indeed allows for things to break if that behaviour is followed

  43. MattJ

    SHOULD (NOT) indeed allows for things to break if that behaviour is (not) followed

  44. daniel

    If this were an experimental xep we could obviously talk about it. It's not a stupid proposal or anything

  45. moparisthebest

    Well SHOULD NOT certainly doesn't mean MUST NOT

  46. daniel

    > Well SHOULD NOT certainly doesn't mean MUST NOT Yes that's what I meant by as an implementation you can still do it

  47. moparisthebest

    Right

  48. Zash

    So your code MUST handle either way

  49. moparisthebest

    Yes that exactly

  50. singpolyma

    right. consumers must allow for it to be there, even if they just ignore it

  51. singpolyma

    because it might be

  52. Kev

    No.

  53. singpolyma

    but probably won't be

  54. MattJ

    > So your code MUST handle either way I don't think that's the case

  55. MattJ

    That's what I was trying to say with my previous statement

  56. Kev

    If it is SHOULD NOT you do not need to deal with it in your implementation.

  57. MattJ

    ^

  58. Kev

    If it is truly optional, you have MAY for that.

  59. singpolyma

    then your implementation will be broken when someone does it

  60. larma

    Depends on how you define "handle". Your code should not delete the user's hard drive when they see the server not complying with a SHOULD NOT 😉

  61. Kev

    And that implementation would be broken for ignoring the SHOULD NOT :)

  62. singpolyma

    larma: right. handle doesn't mean handle *well*

  63. singpolyma

    but not break

  64. moparisthebest

    Eh yea I think code must account for SHOULD NOT, for some definition of account

  65. dan.caseley

    We're definitely at "not approvable" 😂

  66. moparisthebest

    Anyway it's been -1 as is, move on for now?

  67. singpolyma

    well, I think we all voted no based on the weird wording issues anyway

  68. singpolyma

    the question is just if we woul;d ever say yes or if it's a waste of time for them to fix wording

  69. moparisthebest

    I would consider after some discussion yes

  70. daniel

    For now only I have voted. Even if it's vetod it I'd still be interested in hearing your votes

  71. singpolyma

    I would also

  72. larma

    A reasonable handling in this case would certainly be to not support registration at all (claiming the server does not correctly implement the specification)

  73. moparisthebest

    > I'm not opposed to the principal but needs some work and discussion so -1 as-is but open to it changing I voted

  74. singpolyma

    -1

  75. daniel

    larma, dan.caseley:?

  76. daniel

    I would like to move on. You can also vote later

  77. dan.caseley

    I'm abstaining for now

  78. larma

    I even have doubts about the usecase in general. That itself makes it rather unacceptable for me to do this change to something that's already Final. -1, but might change after discussion and wording change

  79. daniel

    (for the new people we usually say 'on list' even thought we mostly now vote in here)

  80. daniel

    Thanks

  81. daniel

    b) Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All (https://xmpp.org/extensions/inbox/host-meta-2.html)

  82. larma

    on-list

  83. daniel

    +1

  84. singpolyma

    -1 I'd like to see the authors of https://xmpp.org/extensions/xep-0156.html approached about extending

  85. moparisthebest

    I still have some editorial moving around to do on this, but would like to do it on the list and/or under the XSF umbrella so +1 obviously hehe

  86. moparisthebest

    Awkward in the inbox, I don't think I can touch that copy

  87. moparisthebest

    fwiw I don't think a +1 prevents merging with 156 later does it singpolyma ? Still up to you

  88. daniel

    That's fair. In the past we've still accepted overlapping xeps. For example the online meetings one

  89. singpolyma

    well if we approve this it gets a xep number

  90. larma

    I'd like to raise (what I already mentioned in XSF discussion) that this might break / be incompatible with RFC 6415 and indirectly RFC 5785

  91. daniel

    Experimental is not stable

  92. singpolyma

    so merging becomes awkward

  93. daniel

    But new council members can obviously have different opinions

  94. moparisthebest

    Right but it can be deprecated and a link to 156

  95. larma

    I'd like to raise (what I already mentioned in XSF discussion) that this might break / be incompatible with RFC 6415 and indirectly RFC 5785 by essentially reassigning the content specification for a well-known file.

  96. singpolyma

    sure, but it's still xep number proliferation even when deprecated

  97. moparisthebest

    We have unlimited numbers

  98. daniel

    (there have also been previous councils who reject things quite often. So either way is fair)

  99. singpolyma

    I also have substance concerns, but the procedural one is top of mind for me

  100. daniel

    Any more votes?

  101. dan.caseley

    On list

  102. daniel

    larma:?

  103. dan.caseley

    Already on-list'd?

  104. larma

    > on-list as dan.caseley said

  105. daniel

    Ah sorry.

  106. daniel

    5) pending votes

  107. daniel

    None

  108. daniel

    6) date of next

  109. daniel

    +1w wfm

  110. singpolyma

    wfm

  111. moparisthebest

    +1w wfm

  112. larma

    +1w wfm

  113. daniel

    7) aob

  114. larma

    no

  115. moparisthebest

    Nothing here

  116. dan.caseley

    Nope

  117. singpolyma

    none

  118. daniel

    8) close

  119. daniel

    Thank you all

  120. larma

    Thanks daniel

  121. moparisthebest

    Ok one aob, thanks to Kev for editor work and singpolyma for mailing list work :)

  122. moparisthebest

    Thanks all!

  123. dan.caseley

    Thanks all!

  124. Kev

    Thanks all.