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