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
ThibGhas joined
ThibGhas joined
Half-ShotXhas joined
Half-ShotXhas left
pep.has joined
rtq3has left
rtq3has joined
wurstsalathas joined
alacerhas joined
Half-ShotXhas joined
jonas’
Ge0rG, no, I don’t think that should be a footnote.
jonas’
That should be normative language, with a MUST, for the services which implement the disco#info feature.✎
jonas’
That should be normative language, with a MUST, for the services which implement/advertise the disco#info feature. ✏
neshtaxmpphas left
neshtaxmpphas left
moparisthebesthas joined
neshtaxmpphas joined
moparisthebesthas joined
rtq3has left
rtq3has joined
lumihas left
flow
what jonas’ said
olihas joined
Half-ShotXhas left
Half-ShotXhas joined
jonas’
(the footnote is good for clients having to deal with non-implementing servers)
Half-ShotXhas left
valohas left
valohas joined
vaulorhas left
vaulorhas joined
Half-ShotXhas joined
Half-ShotXhas left
j.rhas joined
Half-ShotXhas joined
Ge0rG
> 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?
Ge0rG
into a SHOULD?
jjrhhas left
Half-ShotXhas left
flow
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"
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?
flow
Ge0rG, a html diff would be great
Ge0rG
flow: 0410 is only for participant self-ping
Ge0rG
flow: I don't know how to create a html diff. I wish we had tooling for that
jonas’
Ge0rG, hm, what about the case when a ping races with a nickname change?
jonas’
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)
Half-ShotXhas left
Half-ShotXhas joined
Ge0rG
jonas’: do you want me to add <item-not-found/> to the list?
jonas’
I’m not sure
jonas’
I may want a different IQ if the server explicitly supports this.
jonas’
something to the bare MUC JID
jonas’
so that we don’t have to deal with nickname races
Ge0rG
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.
jonas’
(in addition to handling the self-ping IQ efficiently)
jonas’
Ge0rG, adding <item-not-found/> as an informative thing for client developers in that list is a good thing IMO
Ge0rG
jonas’: you know, I've been thinking about that and dropped it because you can't fix all MUC services out there.
Ge0rG
jonas’: the informative thing for client developers is in §3.2
vanitasvitaehas left
jjrhhas joined
vanitasvitaehas joined
jjrhhas left
jjrhhas joined
jonas’
right
jonas’
Ge0rG, we won’t get all MUC sevrices fixed, but that’s why there is a separate feature.
Half-ShotXhas left
Half-ShotXhas joined
ThibGhas joined
jonas’
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
jonas’
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
jonas’
A bad client would: use self-ping
jonas’
A very bad client would: not notice outages at all
Ge0rG
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?
ThibGhas joined
rtq3has left
Half-ShotXhas left
Half-ShotXhas joined
Half-ShotXhas left
Half-ShotXhas joined
jjrhhas left
jjrhhas joined
jjrhhas left
jjrhhas joined
flow
Ge0rG, how about adding a xep410 error condition to the "client is not joined" error response?
Alexhas joined
Ge0rG
flow: what would that serve?
flow
in case a broken client responds with <not-acceptable/>
flow
http://paste.debian.net/1062860/
Half-ShotXhas left
Half-ShotXhas joined
flow
Makes life easier (e.g. reading stanza traces) and does not hurt
flow
didn't we want to add a disco feature for xep410?
Ge0rG
flow: we have one
Half-ShotXhas left
Half-ShotXhas joined
flow
I see one for the self-ping-optimization
Ge0rG
yes.
flow
But not for "this service implements xep410"
Ge0rG
that's the one. What else do you want to have a feature for? Client-side?
Ge0rG
the self-ping-optimization is the only xep410 thing that can be implemented service-side
flow
couldn't you implement "sending <not-acceptable/> on not joined" without the self-ping optmization?
Ge0rG
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)
Ge0rG
flow: most MUCs already do so.
Ge0rG
flow: except the ones that return other errors.
flow
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
Ge0rG
to what?
Ge0rG
initially, 0410 didn't even need a disco feature for the optimization.
flow
https://xmpp.org/extensions/msp/0
flow
just an example
Ge0rG
flow: if the MUC implements self-ping-optimization, you know you won't receive a self-ping resonse from a client anyway.
Ge0rG
even less so from a broken client
flow
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
Half-ShotXhas left
Half-ShotXhas joined
Ge0rG
msp standing for muc-self-ping?!
flow
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
Ge0rG
flow: what's your ultimate goal?
Half-ShotXhas left
Half-ShotXhas joined
Ge0rG
`http://jabber.org/protocol/muc#self-ping-optimization` was supposed to be in line with the other MUC features
flow
world peace
Ge0rG
flow: world peace is not a goal of XEP-0410
flow
How about http://jabber.org/protocol/muc#self-ping
Ge0rG
flow: why?
flow
I mean, that is the name of the XEP, it's not "XEP-0410: MUC Self-Ping Optimization"
Ge0rG
Yes. Because the XEP is about more than just the optimization.
alexdehas joined
Ge0rG
But the optimization is what a server can implement. And advertise
alexdehas left
j.rhas joined
flow
But the MUC service could also implement just "send <not-acceptable/> if not joined", without the optimization, right?
jjrhhas left
jjrhhas joined
Ge0rG
flow: yes. That would be XEP-0045 then.
flow
Ge0rG, doex xep45 define that not-acceptable must be send in this case?