On 15 July 2014 23:59, Graham King <[email protected]> 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. >
