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

Graham King graham at gkgk.org
Tue Jul 15 22:59:08 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

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.

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.

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.

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.

I would be happy to send a patch for any part of this.

Best regards,
Graham


On 14-06-19 07:59 PM, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0186 (Invisible Command).
> 
> Abstract: This document specifies an XMPP-compatible protocol for
> user invisibility.
> 
> URL: http://xmpp.org/extensions/xep-0186.html
> 
> This Last Call begins today and shall end at the close of business
> on 2014-07-03.
> 
> Please consider the following questions during this Last Call and
> send your feedback to the standards at xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol? 2. Does the specification
> solve the problem stated in the introduction and requirements? 3.
> Do you plan to implement this specification in your code? If not,
> why not? 4. Do you have any security concerns related to this
> specification? 5. Is the specification accurate and clearly
> written?
> 
> Your feedback is appreciated!
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTxbI0AAoJEBJ8/NmzuSnSBY4P/1i1rzM5I+F5BG+T29Yqre5z
lZ0BPIY90LZEBSWT1sNECmZXP4/B+v5nfLuCgs6a6Ao4yN9Emvln9PeFHmjqORbK
ZDFnhLOM3zRXMrahZko8j0nLY3m09NeZrpe4EkuRITkzQgwN9KPofaLmO6vV3lDs
vIU1YxK9N+iG5TDFa3VO5ZDCahsnUgpCr9r8dBfqb2xm5MZWTtntGyiD8bEsYWds
XvXWulAuc0Utur7VSc9uB67rOe8R0kzB7pEEf+EX4FMbClDHR/uHge0fjUSCw9fh
aFgGfhdsvT0/DTEQ2tuPYo1EQrm0tXjfNWPemQiiOzzHk9QgwVWzWGM85/sRFA/j
2KhPtXriTTB2gLivx/0MfwMEEIepnD1M9WKRo5GLffMzAKQPblxLy5U4JxVyj/wa
3lqV1MGjWOiqs/QYQQ+lrTIkTFWzSuP+9NpppdW+RJJ2I9X83V7KFW/zJOdJ2jvL
pHLtu5Evs3xTG2oHHZ5wIjkseDAYw0Amp6qBAWMQKuVRnkPsyM7Fmxt/4V9yryE3
SBQWGBJnQIO8h2t8da7D8nraj8VG4BMrwKhr8za7fL3JwL8lHxa6HRcCwV+OE9wJ
RQyuF2AxMMKp+E0nLvvZijKka8c1wyrtEfF6KjLlxXvZIWF436Z6H5M0RoWrBpeL
XmWTi2EMquoAqPdhmJ2L
=ry5u
-----END PGP SIGNATURE-----



More information about the Standards mailing list