I am also a bit too late but; how does this work with XEP 0184?
/stefan
Christian Schudt skrev 06/07/14 20:56:
I might be too late to the party, but I just began implementing it on client
side and I think 3.1.2 Client Handling lacks some point:
After becoming invisible the client should (automatically?) send directed presence (which
equals the last undirected presence) to all entities in the "communicants
list"!?
Here's my other feedback:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to
clarify an existing protocol?
Yes. I remember using invisibility in ICQ back in the 90s :-) so it should be
in XMPP in 2014...
2. Does the specification solve the problem stated in the introduction and
requirements?
Yes, maintaining a privacy list on client side is cumbersome.
3. Do you plan to implement this specification in your code? If not, why not?
Yes.
4. Do you have any security concerns related to this specification?
Maybe presence leaks, while being invisible and in a MUC room (and some
occupants are also on your roster) could be mentioned?
5. Is the specification accurate and clearly written?
Mostly yes. But some points:
Is "communicants" a good term in this context?
http://en.wiktionary.org/wiki/communicant says its obsolete and has primarily a
religious meaning.
I'm no native speaker though.
I think there's a typo "the client behave as follows". Should be "behaves"?
Integration with privacy lists: How does the server know what are the "relevant privacy
lists". Is it by convention the list named "invisible", which is being activated for
the session?
If yes, wouldn't it prevent directed presence?
XEP-0126 could have been linked in this section.
-- Christian
