XMPP Council - 2023-08-09

Hi

It's time

1) roll call

👋️

o/

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

Hello!

Is Ge0rG around too?

yes he is!

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)

2) date of next

+1w wfm

+1w wfm

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

+1w wfm

+1w wfm

And thanks MattJ !

+1w wfm

> 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.

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

3) aob

I guess none

4) close

Thank you all

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)

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

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

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

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."

The second sentence here

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

But yes that wording looks good, sorry I missed it

Surely yeah. I'll try to adjust wording thanks