On 07.03.2017 12:31, Jonas Wielicki wrote:
I would like a rationale for why after going visible again, the session is
treated as before sending initial presence. This feels counter-intuitive to
me: I would expect all my contacts to see the presence I most recently sent to
those on my "visible list". While a client can surely implement it that way,
is there a rationale to not have it specified that way by setting the outbound
presence to the most recently sent during invisibility?
This thing I actually liked the most - very elegant, just send the
presence you want to be after invisible. In the client it's simple (just
re-send current presence). In the server it's simple (just broadcast and
send probes).
I believe the rationale is consistency of the presence state. If server
just rebroadcast last cached presence (even of cached for this
connection) - it wouldn't be proper presence state since some(most?)
implementations may stop sending presence once they received
'unavailable'. And they are not obliged to re-send it on receiving the
new one. So you may write - server must broadcast and probe but... this
is what happens on initial presence.
What does a server do when a client does not send a <presence/> after going
visible when asked by peers to which the client has sent directed presence vs.
those to which the client has not sent directed presence?
If we follow XEP-0016 way - literally nothing.
Directed presence is special case anyway, and is required to be tracked
regardless the visibility.
Secondly, what is the state of the Privacy Lists if they are used as a backing
store after the client goes offline during invisibility? Are those reset
automatically? This could use some clarification.
Invisibility is quite straight-forward command. It's just one priv.list
item - presence-out. (if we ignore probe thingy). So
<invisible> = <item action='deny'><presence-out/></item> hence to set is
to add such item (auto-creating active list if necessary) and to unset
is just remove any such item (autodeleting empty active list if necessary).
The same semantic as being using in blocking commands. Just with active
list instead of default.
But yes, probe thingy. That changes the whole picture. Meaning normal
priv.list backend can not be used as is, should be modified/extended to
account for probe blocking (which is impossible with priv.lists - except
total blackout case).
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
