XMPP Council - 2024-03-26


  1. daniel

    > On the 5th rule... if you've already got the server doing assisting, can't it strip the full jid to a bare jid? I'm sure there's a good reason, but it isn't given. No you can't because group chat PM (full jid) vs normal jid (bare jid)

  2. daniel

    > The first business rule in s5 talks about IDs only moving forward. Is this practical? It's not required by XEP-0359. It doesnโ€™t say that. It talkes about the display state and makes no statement about the underlying ID

  3. daniel

    > The second business rule requires that server knows all prior stanza IDs. all but the last business rules were really meant for the client. to make that more clear I divided the business rules up into a server and a client part https://xmpp.org/extensions/inbox/xep-mds.html

  4. dan.caseley

    That was quick! Last thing was publish-options, but I've spotted that XEP-0223 (Best practices...) is required and itself requires publish-options, so no further change needed. +1

  5. daniel

    Itโ€™s time

  6. daniel

    1) roll call

  7. dan.caseley

    ๐Ÿ‘‹

  8. moparisthebest

    Hello!

  9. singpolyma

    hello

  10. daniel

    larma are you here too?

  11. daniel

    2) Agenda bashing

  12. daniel

    any proposed changes to the agenda?

  13. daniel

    assuming none

  14. dan.caseley

    I don't have pending votes any more :)

  15. daniel

    3) Editors update

  16. larma

    ๐Ÿ‘‹๏ธ

  17. daniel

    two more last calls have started (displayed markers and message processing hints)

  18. daniel

    and a bunch of xeps have been updated

  19. daniel

    4) Items for voting

  20. moparisthebest

    Thanks so much for doing all the editor stuff again

    ๐Ÿ’ฏ๏ธ 1
  21. daniel

    so we are going to vote on advancing two xeps to stable. there is generally 3 different directions this could go. rejected, stable, move back to experimental.

  22. daniel

    which obviously isnโ€™t covered by a +1/-1 vote

  23. singpolyma

    what does rejected mean?

  24. daniel

    see xep-0001 (we have given up on the xep donโ€™t think it a good idea)

  25. larma

    rejected means we tell the author that the XEP is not needed at all, move back means we say that the XEP has its purpose, but needs further work or something else before it can advance

  26. daniel

    personally i'm not seeing either of those xeps going back to experimental

  27. daniel

    so I would suggest we make the votes about stable vs rejected

  28. dan.caseley

    ๐Ÿ‘

  29. daniel

    but we could vote on 'do we want to move x to state y' individually if people feel otherwise

  30. larma

    I would suggest to generally vote first for advancement and if it's decided to not advance, vote on what to do instead. I think this would be a good practice for the future, but not strictly needed here (at least not for me)

  31. moparisthebest

    ^

  32. singpolyma

    sounds good

  33. dan.caseley

    No objections.

  34. daniel

    ok. we will do it like that. (I do however want to avoid xeps getting stuck in 'proposed' if we none of the votes succeed)

  35. daniel

    a) Move XEP-0360 to Stable

  36. larma

    the second vote would be either "move back" or "reject", never "keep proposed"

  37. dan.caseley

    If Stable and Rejected fail, shouldn't it be automatically Experimental?

    ๐Ÿ‘†๏ธ 1
  38. Kev

    (Historical note for interest: There used to be no 'back to Experimental'. Once you asked for an LC on your XEP, it either advanced, or it was rejected)

  39. dan.caseley

    Interesting cliff!

  40. larma

    Kev, yes, but that turned out to not be very useful if there is clear understanding that a XEP is needed, but it needs to be improved before advancing

  41. daniel

    anyway on the 360 to stable iโ€™m -1

  42. larma

    -1

  43. moparisthebest

    -1

  44. larma

    -1 on 360 to stable

  45. daniel

    I wrote at lenght about it on the mailing list thread

  46. singpolyma

    +0

  47. dan.caseley

    -1

  48. moparisthebest

    -1 on 360 to stable

  49. daniel

    give me one second i'm going to record those votes

  50. moparisthebest

    I've read the mailing list on this just haven't responded, generally agree no need for this

  51. daniel

    b) Move 360 to rejected (if this fails it goes back to experimental)

  52. dan.caseley

    I'm not inherently against it, but I think there's enough sustained and varied objection that it wouldn't benefit the community to include it.

  53. daniel

    +1

  54. dan.caseley

    +1

  55. moparisthebest

    +1 move 360 to rejected

  56. singpolyma

    +1

  57. larma

    +0 move 360 to rejected

  58. daniel

    c) Move XEP-0392 (Consistent Color Generation) to stable

  59. daniel

    +1

  60. moparisthebest

    +1

  61. singpolyma

    +1

  62. dan.caseley

    +0 - I've not seen a response to singpolyma's valid comments on the mailing list.

  63. singpolyma

    which ones?

  64. dan.caseley

    CbCr mentions RGB impossible calculation

  65. dan.caseley

    They are minor, if I'm reading it correctly, and could be changed at Stable without impact to implementations

  66. dan.caseley

    Hence the +

  67. singpolyma

    oh yeah, the CbCr thing is basically a typo

  68. moparisthebest

    > They are minor, if I'm reading it correctly, and could be changed at Stable without impact to implementations That was my impression too, still many implementations in the wild and this seems editorial

  69. singpolyma

    I also think there's no reason for it to mention hsluv specifically or at least not in a normative way, but I don't really care about that strongly

  70. daniel

    I was going to respond to the hsluv thing but forgot. yes s and l are chosen by the implementation. but they are fixed for application or per theme

  71. daniel

    so the benefit of hsluv is that the colors like equally luminous (I'm not a color guy; is this the right terminology)

  72. singpolyma

    Yeah, I'm not saying using hsluv is bad. I do in my implementations. I just meant that using whatever HSL space you want won't change the algorithm at all

  73. larma

    I think the reason it mentions HSLuv is that people were unhappy about HSL with constant S and L due to it's perceived nonuniformness

  74. singpolyma

    since the algorithm just gives you the H

  75. daniel

    I donโ€™t know what witchcraft is going on with hsluv. all i know it looks nice in practice

  76. moparisthebest

    I'm partially colorblind and this does as good of a job as anything I've seen in trying to get colors that are distinguishable for me

  77. daniel

    any way do you want to vote on this now larma ?

  78. singpolyma

    Anyway this is all editorial or interpretive so still +1 from me

  79. moparisthebest

    If I ever come across something better I'll be sure to try to steal/propose it :)

  80. larma

    I would consider to change the XEP to mention exactly that: - make HSLuv a SHOULD, explain that other HSL could be used - state that implementations SHOULD use constant S and L for specific usecases/themes for uniformity

  81. larma

    I think those can be covered after move to stable, so I'm +0

  82. singpolyma

    larma: yes, I agree

  83. moparisthebest

    Is 3 +1s enough to move it? I don't recall the majority rules ๐Ÿ˜

  84. daniel

    I agree that those are good additions to the xep

  85. daniel

    moparisthebest, i believe it is

  86. Kev

    Majority, no objection.

    ๐Ÿ‘†๏ธ 1
  87. moparisthebest

    Sweet thanks

  88. daniel

    5) Pending votes

  89. daniel

    none

  90. daniel

    6) Date of Next

  91. daniel

    +1w wfm

  92. larma

    +1w wfm

  93. singpolyma

    +1w I will be in a car. might wfm

  94. dan.caseley

    +1w wfm

  95. daniel

    I will be unavailable from the 20th to the 30th (that's two council meetings. one on the 23rd on one on the 30th)

  96. moparisthebest

    +1w wfm

  97. Kev

    ``` After a XEP has been proposed to the XMPP Council, any change in its status shall be determined by a vote of the XMPP Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A XEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the XEP to advance. A majority of Council members must vote +1 in order for a XEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the XMPP Council.) A vote of the XMPP Council is final and binding, although a XEP author or Document Shepherd is free to address the concerns of the Council and to resubmit the XEP for future consideration. ``` For reference

  98. daniel

    just letting you know ahead of time

  99. daniel

    7) AOB

  100. dan.caseley

    Can object to it being nearly April already? The year only just started.

  101. moparisthebest

    Seconded...

  102. moparisthebest

    But no aob here

  103. daniel

    8) Close

  104. daniel

    Thank you all. See you next week

  105. dan.caseley

    Thanks daniel ๐Ÿ‘‹

  106. moparisthebest

    Thanks all!

  107. larma

    Thanks all, and daniel in particular