XSF Discussion - 2019-01-28

my boss ACKed me taking a day off on 31st

so I can at least attend remotely :)

Awesome!

jonas’: I've added a footnote to "Any other error" - does that make sense? I'm not happy with the rendering though, maybe should move it into braces? https://op-co.de/tmp/xep-0410.html#performingselfping

Ge0rG, no, I don’t think that should be a footnote.

That should be normative language, with a MUST, for the services which implement/advertise the disco#info feature. ✏

what jonas’ said

(the footnote is good for clients having to deal with non-implementing servers)

> Therefore, a MUC service supporting this protocol may directly respond to a participant's Ping request I suppose I need to change that as well, then?

into a SHOULD?

I see no need to change that as well, reads good as it is. Maybe I am missing something. It also appears that a SHOULD would contradict the "service MUST reply with xxx if not joined"

Ge0rG, into a MUST

if it advertises the feature, replying is a MUST

that’s the idea

jonas’, flow: https://op-co.de/tmp/xep-0410.html#serveroptimization

wait there are still cases where the MUC service does not respond directly to a ping, but instead does route it, right? If so, then you can say that a "service MUST respond to a participants ping". Or doex xep410 mandate that participants ping are always handled by the service?

Ge0rG, a html diff would be great

flow: 0410 is only for participant self-ping

flow: I don't know how to create a html diff. I wish we had tooling for that

Ge0rG, hm, what about the case when a ping races with a nickname change?

that would yield (<item-not-found/> (sometimes?) if the nickname isn’t in use again && the client is joined) || (a full round-trip if it is && the client is joined)

jonas’: do you want me to add <item-not-found/> to the list?

I’m not sure

I may want a different IQ if the server explicitly supports this.

something to the bare MUC JID

so that we don’t have to deal with nickname races

flow: the changed text is: > A service implementing this optimization needs to advertise the self-ping-optimization feature in the Service Discovery (XEP-0030) [5] response on the individual MUC room JIDs, and it MUST respond to a self-ping request as follows: > - Successful IQ response: the client is joined to the MUC. > - Error (<not-acceptable>): the client is not joined to the MUC.

(in addition to handling the self-ping IQ efficiently)

Ge0rG, adding <item-not-found/> as an informative thing for client developers in that list is a good thing IMO

jonas’: you know, I've been thinking about that and dropped it because you can't fix all MUC services out there.

jonas’: the informative thing for client developers is in §3.2

right

Ge0rG, we won’t get all MUC sevrices fixed, but that’s why there is a separate feature.

I’d imagine a good client to behave like this: - MUC advertises feature: use specialised IQ - MUC does not advertise feature: use self-ping with kludgy response parsing

I mediocre client would: - MUC advertises feature: use self-ping and less kludgy response parsing - MUC does not advertise feature: use self-ping with kludgy response parsing

A bad client would: use self-ping

A very bad client would: not notice outages at all

jonas’: so you want to at least double the complexity for the benefit of making server-side nickname changes, which are widely considered as broken anyway, more robust when racing with a self-ping?

Ge0rG, how about adding a xep410 error condition to the "client is not joined" error response?

flow: what would that serve?

in case a broken client responds with <not-acceptable/>

http://paste.debian.net/1062860/

Makes life easier (e.g. reading stanza traces) and does not hurt

didn't we want to add a disco feature for xep410?

flow: we have one

I see one for the self-ping-optimization

yes.

But not for "this service implements xep410"

that's the one. What else do you want to have a feature for? Client-side?

the self-ping-optimization is the only xep410 thing that can be implemented service-side

couldn't you implement "sending <not-acceptable/> on not joined" without the self-ping optmization?

flow: as with jonas’' suggestion, I don't want to make the logic even more complex (you'd have to check for the additional condition to be really sure)

flow: most MUCs already do so.

flow: except the ones that return other errors.

If the answer is yes, then I would suggest adding another disco feature, if not, then that would mean that the self-ping optimization is a mandatory part of xep410 and I would suggest changing the disco feature value

to what?

initially, 0410 didn't even need a disco feature for the optimization.

https://xmpp.org/extensions/msp/0

just an example

flow: if the MUC implements self-ping-optimization, you know you won't receive a self-ping resonse from a client anyway.

even less so from a broken client

the important part is that the feature value does not include "self-ping-optimzation" because it make it look like that this is a different optional aspect of xep410

msp standing for muc-self-ping?!

I just saw that you already set the XEPs short name, +1 for that, in this case I would change the xmlns value to https://xmpp.org/extensions/muc-selfping/0

flow: what's your ultimate goal?

`http://jabber.org/protocol/muc#self-ping-optimization` was supposed to be in line with the other MUC features

world peace

flow: world peace is not a goal of XEP-0410

How about http://jabber.org/protocol/muc#self-ping

flow: why?

I mean, that is the name of the XEP, it's not "XEP-0410: MUC Self-Ping Optimization"

Yes. Because the XEP is about more than just the optimization.

But the optimization is what a server can implement. And advertise

But the MUC service could also implement just "send <not-acceptable/> if not joined", without the optimization, right?

flow: yes. That would be XEP-0045 then.

Ge0rG, doex xep45 define that not-acceptable must be send in this case?

Oh. Ugh. https://xmpp.org/extensions/xep-0045.html#disco-occupant

jonas’: ^

Ge0rG, > of making server-side nickname changes or MSN nickname changes

flow, wtf, why https://xmpp.org

we have urn:xmpp for that purpose

I agree with Ge0rG, though, so this is just tangential ✏

jonas’, I see some appeal in xmlns being an URL which ideally would point to the latest revision of the XEP for that particular namespace

flow, not going to happen.

jonas’, I am not so sure about that

flow, we aren’t even able to make redirects from accepted inbox ProtoXEPs to their accepted versions, or maintain the attic reliably

or our registries

that doesn't mean that it has to be that way forever

flow: this was what we had before, and it was decided we went with URNs instead

not ot mention that https vs. http is an ambiguity I do not want to even theoretically have in namespaces when we can avoid it

ralphm, so it is textified/codified somewhere that XEPs have to use urn:xmpp?

jonas’: what do you think about bad-request?

...as the default response for a non-participant, that is

Ge0rG, works for me

I don’t have a strong opinion on the specific type

and the precedent for disco#info is convincing

consistency is nice

flow: https://xmpp.org/extensions/xep-0053.html

jonas’: consistency with a specification that is widely ignored?

(which is referenced from XEP-0001)

ralphm, ta

no problem, sir

One can't know all the things, but people that have been around longer just tend to know a bit more of the ancient bits.

Certainly, although I am pretty sure I have read xep53 before, but unfortunately that piece of information did not stick

You mean the entire section comprising half of the document?

not exactly, more like the whole document