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

Graham King graham at gkgk.org
Wed Jul 16 18:21:37 UTC 2014


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

We both assumed a different meaning for 'session', so it would be great
to have the XEP clarify that. I like your meaning better, that
invisibility applies to an XML Stream (RFC 6121, section 4). That would
for example have avoided the multiple 'unavailable' bug we experienced.

Applying invisibility to the XML Stream also supports Kamil's question
about sending invisible iq before initial presence. If 'session' means
'presence session' it's ambiguous if you can make a not-yet-existing
presence session invisible. If it applies to the XML Stream you are
currently in, the behavior is more obvious.




More information about the Standards mailing list