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

2014-07-16 Thread Dave Cridland
On 15 July 2014 23:59, Graham King gra...@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

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

2014-07-16 Thread Peter Saint-Andre
On 6/19/14, 9:30 PM, Lance Stout wrote: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? This is a feature that has received a lot of end-user requests, and we have no other good way to do it, so yes. If anyone is going to ever

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

2014-07-16 Thread Peter Saint-Andre
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

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

2014-07-16 Thread Stefan Karlsson
Silly question: Why not just have invisible as a presence mode, and remove the silly enforced empty presence/ at initialization? /stefan Peter Saint-Andre skrev 16/07/14 17:11: On 6/19/14, 9:30 PM, Lance Stout wrote: 1. Is this specification needed to fill gaps in the XMPP protocol stack

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

2014-07-16 Thread Kamil Kisiel
Actually with the current iq scheme, that's one thing that should be clarified: Can the invisible iq be sent before initial presence? It seems that would need to be supported in order to not leak your presence when you first log on, otherwise a contact may see you come online momentarily and

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

2014-07-16 Thread Graham King
On 14-07-16 12:39 AM, Dave Cridland wrote: On 15 July 2014 23:59, Graham King gra...@gkgk.org 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

[Standards] XEP-0045 MUC should mention component

2014-07-16 Thread Graham King
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, XEP-0045 (Multi-User Chat) doesn't say that it should be implemented as a Component (XEP-0114). I think it should mention that. I remember getting quite confused when I first worked on implementing MUCs because I was new to XMPP. All the

Re: [Standards] XEP-0045 MUC should mention component

2014-07-16 Thread Dave Cridland
On 16 July 2014 19:33, Graham King gra...@gkgk.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, XEP-0045 (Multi-User Chat) doesn't say that it should be implemented as a Component (XEP-0114). I think it should mention that. I don't think there's such a requirement.