Re: [Standards] XEP-0191 leads to stale presence?
On Sat, 22 Jun 2019 at 19:12, Dave Cridland wrote: > > > On Thu, 20 Jun 2019 at 20:32, Kim Alvefur wrote: > >> Hi, >> >> While working on a fix for Prosodys XEP-0191 implementation¹ regarding >> presence sent to a blocked JID to pretend that the blocking user is >> offline, and then re-send presence again if they unblock. >> >> However, since if you block someone, your view of their presence will >> become stale. The XEP does not say anything about this. Is it implied >> that the server should send a presence probe or otherwise try to do >> something about that? >> >> > Yes. > > More usefully: I always assumed the intent of XEP-0191 was to make the subject appear offline to any blocked contacts, and make any blocked contacts appear offline, for the duration of the block. So as I recall - and no doubt Edwin and Kev can say if I recall correctly - when I last implemented it from scratch, I had the server probe a contact when unblocked, and and otherwise make it appear as if both sides had just come online (or stayed offline, or whatever). But you're quite right, none of this is in the letter of the specification (even the intent). Dave. > >> ¹ https://issues.prosody.im/1380 >> >> -- >> Regards, >> Kim "Zash" Alvefur >> ___ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: standards-unsubscr...@xmpp.org >> ___ >> > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0191 leads to stale presence?
On Thu, 20 Jun 2019 at 20:32, Kim Alvefur wrote: > Hi, > > While working on a fix for Prosodys XEP-0191 implementation¹ regarding > presence sent to a blocked JID to pretend that the blocking user is > offline, and then re-send presence again if they unblock. > > However, since if you block someone, your view of their presence will > become stale. The XEP does not say anything about this. Is it implied > that the server should send a presence probe or otherwise try to do > something about that? > > Yes. > > ¹ https://issues.prosody.im/1380 > > -- > Regards, > Kim "Zash" Alvefur > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0191 leads to stale presence?
Hi, Also consider clients that do not understand XEP-0191, for which it would be even more confusing, as they would not have any way to know that the presence they've seen is stale. (Clients that implement '191 can know via blocklist push.) Having server generate unavailable presence when blocking and probe for fresh presence when unblocking for the JID being (un-)blocked would help keep all clients have a consistent view. This should still look like the user doing the blocking went offline and came back online from the perspective of the one being blocked? Is this something that was implied all along by the XMPP RFCs but not explicitly spelled out in XEP-0191 or a potentially breaking change to a Draft XEP? -- Kim "Zash" Alvefur signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] PR #793 - XEP-0166: Relax transport element requirement
In response to Council Minutes 2019-06-19 quote from https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method Another problem with early (before accept) transport replace is the fact we have to send the same offer twice. For example we have S5B and IBB. The lousy s5b implementation can only gather s5b proxy candidates so it may fail before we sent initial offer (session/content accept). So after proxy discovery failure we may want to send transport-replace request to IBB which will contain everything needed for IBB negotiation (at least block size). Then we have to repeat transport offer with session/content-accept which will force the remote party to reinitialize IBB transport what looks like a bad practice, which may be even worse with other transports. To make things right it has to be allowed to send session/content-accept without transport element if it was accepted earlier. To solve this we have https://github.com/xsf/xeps/pull/793 but may be it require more actions. Let's discuss. Best Regards, Sergey ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0191 leads to stale presence?
Thanks for the explanation - I obviously didn't read that very carefully (don't post late at night!) Still, it should be as if you just came online with regard to the unblocked contact - that means for both sending and receiving presence. Blocking will most likely last longer than five minutes, so the server may discard any presence information it was holding. If the contact is ever unblocked then fresh presence should be retrieved. But the XEP should probably explain this. From: Standards on behalf of Philipp Hörist Sent: 22 June 2019 00:28 To: XMPP Standards Subject: Re: [Standards] XEP-0191 leads to stale presence? Hi, The section means, my server sends my presence to the now unblocked contact. Yes this would look like im coming online to the contact. But this does not solves the problem that i dont have current presence information about the unblocked contact. The server sending my presence to the contact does not lead to getting up-to-date presence information of the contact back. So if you follow the XEP, you end up with stale presence of the unblocked contact. Regards Philipp ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
