XSF Discussion - 2019-04-18

let's see if it flies?

As long as it doesn't nose-dive...

Ge0rG, I don’t have my github credentials with me, but this wording needs fixing (re #787): > <p>This behavior can not be distinguished from a presence update from a MUC-supporting client that was desynchronized from the room. Treating this as a groupchat 1.0 join will mask the error and leave the client in a partially-synchronized state. Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a &lt;presence&gt; without an &lt;x&gt; element responds with an explicit kick to that client.</p> I suggest: > <p>This behavior can not be distinguished from a presence update from a MUC-supporting client that was desynchronized from the room. Treating this as a groupchat 1.0 join will mask the error and leave the client in a partially-synchronized state. Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a &lt;presence&gt; without an &lt;x&gt; element from a non-occupant full JID responds with an explicit kick to that client.</p>

(note the added `from a non-occupant full JID`)

jonas’: I was going to ask for a mini-diff.

or even better: word diff

jonas’: https://github.com/xsf/xeps/pull/787/commits/84674a922133ac1cbee98f46ee2e0d87214f5fda

+1 :)

Ge0rG: How do you feel about adding a new status code for 'you were kicked because you're not in the room'? Then 'new' clients could receive this and know that they need to autorejoin (which you shouldn't normally do on a kick).

Otherwise, that PR LGTM, thanks.

I was wondering if 333 couldn't be of use here, but maybe it's a bit different

333 probably works actually, yeah.

Although equally, creating a new code specifically for this seems fine too, and possibly clearer.

maybe defer this to the magic MUC application-specific-error-conditions XEP which flow volunteered to write? :)

I think this one we may as well just do Right Now, while merging Georg's PR, as it's such a simple change. Even if we choose 333.

Kev: a code or a condition or a 333?

Wait. Not 0333 the XEP but 333 the status code.

Yes the status code

Yes, 333 is a logical addition there.

I'd just like a sign to a post-1.32 client that it's allowed to rejoin after this kick.

`urn:xmpp:muc:1.32`

And then I think we've got 'gc1 joins' providing full resyncs for a client that understands them, and still letting the user know they're not in the room any more for those that don't.

Kev: I can't parse that statement

anybody ever thought about advertising "up to what version a client supports"? :-°

If we have a mechanism (such as 333) such that a client written after this text knows that the kick was because of a desync, it means that sending a presence when not in the room (i.e. gc1 join) will give us a full resync mechanism. While clients written before this text (so not understanding that 333 or whatever means they can rejoin) will still be telling the user they're not in the room any more.

Ge0rG: See if that parses better.

I think I'd prefer a new code with unique semantics, rather than 333, but I think 333 also works.

Kev: yes. But please avoid using "gc1 join" if you actually mean "desync occupant presence update"

Kev: why not a new error condition, one that could be added to Self Ping.

Not sure I entirely understand the suggestion, but as long as it's something that can annotate a kick, I expect I'm ok with it.

Kev: we had an idea of creating a custom error condition of `<not-an-occupant xmlns="http://jabber.org/protocol/muc"/>` for Self-Ping, but then we realized it would be a good extension to 0045, and I think it would be a perfect match for the "kick"

So you're suggesting putting that alongside the kick element?

(As well as using it in self-ping)

I see no reason that wouldn't work.

Kev: I'm pretty sure you can't have a kick that's also an error.

It doesn't need to be an error for a kick does it?

Does it make sense to put an error condition into a non-error?

I thought you were suggesting something like: <presence from='harfleur@chat.shakespeare.lit/pistol' to='pistol@shakespeare.lit/harfleur' type='unavailable'> <x xmlns='http://jabber.org/protocol/muc#user'> <item affiliation='none' role='none'> <actor nick='Fluellen'/> <reason>Avaunt, you cullion!</reason> </item> <status code='110'/> <status code='307'/> <not-an-occupant xmlns="http://jabber.org/protocol/muc"/> </x> </presence> or I thought you were suggesting something like: <presence from='harfleur@chat.shakespeare.lit/pistol' to='pistol@shakespeare.lit/harfleur' type='unavailable'> <x xmlns='http://jabber.org/protocol/muc#user'> <item affiliation='none' role='none'> <actor nick='Fluellen'/> <reason>Avaunt, you cullion!</reason> </item> <status code='110'/> <status code='307'/> </x> <not-an-occupant xmlns="http://jabber.org/protocol/muc"/> </presence>

Kev: I hadn't thought through what I was actually suggesting.

In retrospect, it doesn't make much sense. But maybe it's because MUC is a _bad_ spec and not because it's inherently a bad idea to have that condition code.

> A MUC service MAY support adding the 333 status code to presences when a user gets removed by the service due to a technical problem (e.g. s2s link failure). This is OPTIONAL.

Why the FFFF is it OPTIONAL?

Something something backwards compat something something

Kev: https://github.com/xsf/xeps/pull/787/commits/049f186631592cde21dc404c5f6bca4da887e7ea

I've gone with a MUST for 333, because the kicking itself is only RECOMMENDED

but maybe I need to reword that into a MAY + lowercase "recommended"

Old-school rendering: https://op-co.de/tmp/xep-0045.html#enter-gc

I don't pretend the situation is perfect, but I think this is the best option we've currently thought of.

Thanks Ge0rG

Kev: I suppose 333 makes more sense than stuffing a condition into a non-error.

why not both?

Or at least put a human readable string into it

flow: like... `<reason>You are not in the room.</reason>`

flow: can you please clarify "both" in terms of XML?

Anything which helps the recipient looking at the raw stanza to understand why he received it

Ge0rG, similar to what key wrote above + 333

flow: > I suppose 333 makes more sense than stuffing a condition into a non-error.

Right, but why not also add the condition (or alternative another text)?

flow: have a look at https://op-co.de/tmp/xep-0045.html#example-44

flow: an application-specific error condition is supposed to be inside of an <error/>. Putting it into <x/> doesn't quite make sense. It would be just yet another MUC presence element.

I don't see an issue with that. But again, I am mostly concerenced that the protocol is throwing around with numbers when it could also use strings which would be much more accessible regarding what is going on when looking at the raw stanzas

flow: let's reinvent MUC.

but if there is always supposed to be a </reason> then that is fine I guess

flow: you need to i18nize reasons.

The rendered XEPs in the attic fail to load the navigation after the CSS update :(

intosi, yes, that is an open issue

we need to do some file shuffling

By that, you mean make the CSS and files available in /attic as well?

* and support files

I am in a meeting right now, I don’t know off the top of my head what’s needed

Okay.

board o'clock.

MattJ ralphm ?

Nyco excused himself.

uh-oh.

While we wait: Seve, if I recall correctly, we agreed to volunteer you to create a job board proposal, right?

can we remove that from 'awaiting feedback' until a proposal is ready?

Guus, yes :), I don't have something yet unfortunately, but I've been looking at what the guys at opensourcedesign and I think we could follow something similar (at least the way of posting a job)

Guus, yes, completely

No problem, I'm not rushing you - but I don't think that there's anything for Board to discuss on that, that's why I'm asking.

We also don't have it as an item yet, but I think we could consider the following suggestion for the badges: https://opensourcedesign.net/jobs/jobs/2019-03-19-design-of-badges-for-different-xmpp-compliance-levels

I will add it

Well, actually, what I want to discuss is how do we want to proceed on this :)

oh, I didn't see those badge proposals. Ge0rG cc ^^

"this" being the badges?

or the job board?

Guus, sorry, the badges. I added a card there, to talk about it.

Cool, looks like we kind of did something anyway, Guus :)

indeed 🙂

lacking others, I shall now resume doing somethings that actually earn me money though 🙂

I can't make it next week (I already sent an email about that)

I'm +1 on that! :)

Yes

We are on a holidays period, so it was quite expected anyway.

I archived the job board card

let's bring it up again after we've something to show.

Yup!

(a job board 😛 )

:)

kk, ttyl!

New XEP html looks nice :)

jjrh, thanks :)