[Standards] LAST CALL: XEP-0186 (Invisible Command)

Peter Saint-Andre stpeter at stpeter.im
Wed Jul 16 16:31:38 UTC 2014

On 7/6/14, 11:56 AM, Christian Schudt wrote:
> I might be too late to the party,

Definitely not!

> 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"!?

That seems reasonable, although I think the presence could be "mere 
presence" with no availability state (e.g., if there was no previous 
presence notification because the user came online).

> 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...

Well we have it, but in other ways. This way is better. IMHO. :-)

>> 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?

Will add.

>> 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.

They're not really contacts (as in the roster), and "the list of people 
you communicate with" is awkward. I'll see if I can find a better term.

> I think there's a typo "the client behave as follows". Should be
> "behaves"?

That's a subjunctive. :-)

> 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.

I'll look into this part of the spec.

Thanks for your feedback!


More information about the Standards mailing list