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
