XMPP Council - 2024-09-10

Sorry I didn't find the time for editor work the past week and I also didn't send an agenda. I did however just read the two new proto xeps just now and I'm +1 on both

Note that the vote expires today so if you haven't read them yet now might be a good time 😊

> Client Access XEP - I've got a nit about using service-unavailable rather than not-allowed/not-acceptable, but that's not really enough to reject on. It also has no XML schema. What really gives me pause is the opaque client id - there's no implementation notes or suggestions, just that it's 'opaque'. Is there prior art that makes my concern unusual or unreasonable? Anyone got a take on my thoughts on the Client Access XEP? Is it overly harsh?

dan.caseley: not having a schema is pretty common at this stage

> In order for a Standards Track XEP to advance from Proposed to Stable, it must: > 6. be formally defined by an XML schema per XEP-0001, so shouldn't be a hard requirement until then

The opaque client ID bothers me most.

And id being opaque. I thinks that's like an archive id for example? I don't understand why opaque should be an issue

It's not User defined or anything is it?

Or iq ids...

I think all ids in XMPP are opaque

I mean we can make it a UUID like in sasl2/bind2 but I find that pretty nit picky for an experimental xep

Which is usually what you want

Even in sasl2 doesn't it just suggest uuid? Obviously that's a sane choice usually but there's no point to require it ✏

I think it suggest uuidv4 specifically and some server implementations check

But I'm fine with it simply being opaque

I will be +1 on both Though I highly dislike adding the misfeature of user-agent to XMPP, don't most modern things instead ask users to add a nickname for clients? That's just feedback for MattJ I guess, nothing blocking

Okay. If it's established in history as being normal, I'm happy being +0

moparisthebest, I can't recall something asking me to name a login session

Also thanks for the great security considerations on both that's a pet peeve of mine (:

MattJ: every "grant access to this" ux I've seen, uh tokens in gitlab and GitHub and Gmail etc

We have lots of user agent equivalents already just not yours part of auth

moparisthebest, really? Tokens, perhaps, but I don't recall ever seeing that as part of an OAuth flow

It's time

I'm not sure I've ever seen an oauth flow in real life, so token management is the only example of granting/revoking account access I'm familiar with

1) roll call

Hello!

Howdy!

I assume singpolyma dan.caseley are here

Is larma here

yes

2) agenda bashing

No agenda so nothing to bash

3) editors update

I didn't find the time to do editor tasks this week. But my availability will improve towards the end of the day

4) items for voting

None

5) pending votes

None I think. Since people voted just now

6) date of next

+1w wfm

+1w wfm

+1w wfm

+1w wfm

7) AOB

Nothing here

Assuming none

8) close

Thank you all. See you next week

Thanks daniel!

Thanks daniel and all