Ge0rGjonas’: 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
flowwhat 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?
Ge0rGinto a SHOULD?
jjrhhas left
Half-ShotXhas left
flowI 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"
j.rhas joined
Half-ShotXhas joined
jonas’Ge0rG, into a MUST
jonas’if it advertises the feature, replying is a MUST
flowwait 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?
flowGe0rG, a html diff would be great
Ge0rGflow: 0410 is only for participant self-ping
Ge0rGflow: 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
Ge0rGjonas’: 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
Ge0rGflow: 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
Ge0rGjonas’: you know, I've been thinking about that and dropped it because you can't fix all MUC services out there.
Ge0rGjonas’: 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
Ge0rGjonas’: 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
flowGe0rG, how about adding a xep410 error condition to the "client is not joined" error response?
Alexhas joined
Ge0rGflow: what would that serve?
flowin case a broken client responds with <not-acceptable/>
flowhttp://paste.debian.net/1062860/
Half-ShotXhas left
Half-ShotXhas joined
flowMakes life easier (e.g. reading stanza traces) and does not hurt
flowdidn't we want to add a disco feature for xep410?
Ge0rGflow: we have one
Half-ShotXhas left
Half-ShotXhas joined
flowI see one for the self-ping-optimization
Ge0rGyes.
flowBut not for "this service implements xep410"
Ge0rGthat's the one. What else do you want to have a feature for? Client-side?
Ge0rGthe self-ping-optimization is the only xep410 thing that can be implemented service-side
flowcouldn't you implement "sending <not-acceptable/> on not joined" without the self-ping optmization?
Ge0rGflow: 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)
Ge0rGflow: most MUCs already do so.
Ge0rGflow: except the ones that return other errors.
flowIf 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
Ge0rGto what?
Ge0rGinitially, 0410 didn't even need a disco feature for the optimization.
flowhttps://xmpp.org/extensions/msp/0
flowjust an example
Ge0rGflow: if the MUC implements self-ping-optimization, you know you won't receive a self-ping resonse from a client anyway.
Ge0rGeven less so from a broken client
flowthe 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
Ge0rGmsp standing for muc-self-ping?!
flowI 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
Ge0rGflow: 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
flowworld peace
Ge0rGflow: world peace is not a goal of XEP-0410
flowHow about http://jabber.org/protocol/muc#self-ping
Ge0rGflow: why?
flowI mean, that is the name of the XEP, it's not "XEP-0410: MUC Self-Ping Optimization"
Ge0rGYes. Because the XEP is about more than just the optimization.
alexdehas joined
Ge0rGBut the optimization is what a server can implement. And advertise
alexdehas left
j.rhas joined
flowBut the MUC service could also implement just "send <not-acceptable/> if not joined", without the optimization, right?
jjrhhas left
jjrhhas joined
Ge0rGflow: yes. That would be XEP-0045 then.
flowGe0rG, doex xep45 define that not-acceptable must be send in this case?
XSF Discussion - 2019-01-28