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

Dave Cridland dave at cridland.net
Wed Jul 16 07:39:47 UTC 2014

On 15 July 2014 23:59, Graham King <graham at gkgk.org> wrote:

> I have recently been working with XEP-0186, and I wanted to add notes
> from my experience. I think some minor clarifications around when
> invisibility stops could be added.
These comments are great, thanks.

> In 2. Requirements / point 2, it says "Invisible mode is active only
> for the current session". Could it say ".. only for the current
> *presence* session (as defined in RFC 6121 section 4.1)"? I puzzled
> over what "session" meant.
A presence session only begins when available presence is sent, so this
would mean you'd only be able to become invisible after telling everyone
you were there. I would have thought that would go against the
requirements, but it turns out that's not explicitly stated.

> In "3.2 User Becomes Visible" I think it would be worth mentioning
> that a user can also become visible by ending their presence session,
> sending an unavailable presence.
So in your model, I'm assuming you're flexible about when exactly a
presence session begins, but the sequence <presence/><presence
type='unavailable'/> would always implicitly clear invisibility?

I have to say I dislike the implicit changes here.

But you're right that the use of the term "session" with no explicit
definition is confusing. I thought that the term was actually defined
somewhere, but it turns out not to be. I thought it meant a client stream,
as (possibly) extended over multiple connections by XEP-0198.

> Finally as an implementation note, we noticed that Smack (3.2.2, over
> BOSH) was sending two unavailable stanzas when it disconnects. The
> first would end the presence session and implicitly the invisibility,
> so the second got forwarded, which was not the client's intention. An
> implementation note might want to remark that the user should stay
> invisible until they start a new presence session (rather than until
> the current one ends). We fixed this by not forwarding unavailable
> stanzas for an already unavailable user, probably something we should
> have been doing already.
FWIW, I think presence is a state, and as such, eliding repeated presence
is entirely acceptable.

> I would be happy to send a patch for any part of this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140716/0aa58085/attachment.html>

More information about the Standards mailing list