XMPP Council - 2023-08-09

  1. daniel


  2. daniel

    It's time

  3. daniel

    1) roll call

  4. larma


  5. jonas’


  6. daniel

    theTedd: I read that by the way but I'm following your own suggestion wrt list

  7. moparisthebest


  8. daniel

    Is Ge0rG around too?

  9. Ge0rG

    yes he is!

  10. daniel

    Since we don't have an agenda I'm gonna move right towards date of next and AOB as we've done in the past. (if anyone disagrees with my judgment call to delay voting on 172 until the list is up please rise it as AOB)

  11. daniel

    2) date of next

  12. daniel

    +1w wfm

  13. Ge0rG

    +1w wfm

  14. MattJ

    iteam here noting that lists are delaying council business, will continue to work on solving that one way or another

  15. larma

    +1w wfm

  16. moparisthebest

    +1w wfm

  17. moparisthebest

    And thanks MattJ !

  18. jonas’

    +1w wfm

  19. daniel

    > iteam here noting that lists are delaying council business, will continue to work on solving that one way or another Not all council business. Only that one and even this is maybe debatable.

  20. daniel

    But yes thanks for your work. Having a working list is probably good for non council things too

  21. daniel

    3) aob

  22. daniel

    I guess none

  23. daniel

    4) close

  24. daniel

    Thank you all

  25. pep.

    Btw at some point I'm planning to submit https://bouah.net/specs/muc-token-invite.html It's been some time but I don't think I had any WIP left, maybe just implementing it. I'm happy to get feedback before I submit it. If that can avoid back-and-forth with editors for no reason other than process. (feedback I would get during the ProtoXEP vote, maybe)

  26. daniel

    pep.: I'd say submit it. I mean council is not supposed to give you any guarantees that nobody will have feedback and going through the editor (and submitting an update) shouldn't be a cumbersome tasks that prevents authors from wanting to update

  27. daniel

    But me personally doesn't have any immediate feedback. That said feedback usually comes from demo implementations not from reading the xep

  28. moparisthebest

    pep.: I like it, looks good, and thanks for having good security considerations :D My only comment/question is I'm guessing services can choose to return limits when they aren't requested or lower (or maybe even higher?) limits even when they are requested? If so that might be helpful to note

  29. pep.

    Yeah that's already in there, maybe I should make the wording better. "The reply from the service MUST contain the requested delay and counter attributes. Requested values for these attributes MAY be altered by the server. Values returned indicate actual values that apply to the issued token."

  30. pep.

    The second sentence here

  31. moparisthebest

    What about when the request doesn't contain delay/counter? Can the service still return some?

  32. moparisthebest

    But yes that wording looks good, sorry I missed it

  33. pep.

    Surely yeah. I'll try to adjust wording thanks