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

[Kevin Smith]

On 7 Dec 2017, at 17:35, Jonas Wielicki (XSF Editor)  
wrote:
> 
> This message constitutes notice of a Last Call for comments on
> XEP-0186.
> 
> Title: Invisible Command
> Abstract:
> This document specifies an XMPP protocol extension for user
> invisibility.
> 
> URL: https://xmpp.org/extensions/xep-0186.html
> 
> This Last Call begins today and shall end at the close of business on
> 2017-12-21.
> 
> 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?

Probably.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Probably. Comments later.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Not currently, I don’t think we need the feature in our code.

> 4. Do you have any security concerns related to this specification?

I think the Security Considerations should list the most obvious leaks that 
still occur when this is implemented (it says they exist, but doesn’t suggest 
what any are).

> 5. Is the specification accurate and clearly written?

It’s not clear to me why we need to both mandate a default for probe, and that 
it’s always included.

I think it would be worth explaining *why* you might want to send invisible 
without a probe, which seems at first glance like it’s the same as not sending 
presence at all (I know it’s not!).

"SHOULD deliver inbound  stanzas whose 'to' address is the bare JID 
 of the user (subject to standard XMPP stanza handling 
rules from RFC 6120 and RFC 6121).”

I think this needs tightening to instead of ‘subject to…’ say something like 
‘if it would otherwise receive…’. Else one could read it as saying that a 
negative priority invisible resource gets messages.

"   • If the server responds to a presence probe, the last available 
presence MUST indicate that the user is unavailable, and if a time is indicated 
it MUST be the time when the client went invisible.”

I don’t think this is right, e.g. two resources, 1 goes invisible, then 2 goes 
offline - the time should be when 2 went offline, not 1 went invisible.

"   • If the server responds to a Last Activity (XEP-0012) [5] request, the 
last activity time MUST be the time when the client went invisible.”

Same.

"If the user wishes to then send presence to all contacts in the roster,”
I think this means those with a presence sub, not just being in the roster 
(this is correctly stated later)

"(the server MAY also send that notification to any entities to which the 
client sent directed presence while invisible, whether or not they are in the 
user's roster)”

This seems weird, as its the only time this would happen; I don’t see a reason 
for the inconsistency with normal directed presence handling.

/K



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[XSF Editor]

This message constitutes notice of a Last Call for comments on
XEP-0186.

Title: Invisible Command
Abstract:
This document specifies an XMPP protocol extension for user
invisibility.

URL: https://xmpp.org/extensions/xep-0186.html

This Last Call begins today and shall end at the close of business on
2017-12-21.

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!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Evgeny Khramtsov]

Sat, 19 Aug 2017 21:17:28 -0600
Peter Saint-Andre  wrote:

> I'll make the relevant fixes soon!

My few cents.

Section 3.1:

> The  element MUST include a 'probe' attribute ...
> The default logical value is FALSE ...

This doesn't make sense: a required attribute cannot have a default
value because it's always present. We should either make it optional
or remove "default logical value" from the spec.

> Although the default value is false (thus protecting the user from
> leaking presence information), the client SHOULD always include the
> 'probe' attribute.

Contradiction: MUST vs SHOULD
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Peter Saint-Andre]

On 6/17/17 10:29 AM, Sam Whited wrote:
> On Sat, Jun 17, 2017 at 1:15 AM, Remko Tronçon  wrote:
>>> This Last Call begins today and shall end at the close of business on
>>> 2017-03-14.
>>
>> FYI, this XEP seems to be in last call after its end date.
> 
> This one was waiting on some updates based on list feedback, IIRC, but
> it's been long enough now that I don't recall what those updates are
> or who was to make them. It should probably just be moved back out of
> LC.

I'll make the relevant fixes soon!

Peter


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

On Sat, Jun 17, 2017 at 1:15 AM, Remko Tronçon  wrote:
>> This Last Call begins today and shall end at the close of business on
>> 2017-03-14.
>
> FYI, this XEP seems to be in last call after its end date.

This one was waiting on some updates based on list feedback, IIRC, but
it's been long enough now that I don't recall what those updates are
or who was to make them. It should probably just be moved back out of
LC.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Remko Tronçon]

Hi,

> This Last Call begins today and shall end at the close of business on
2017-03-14.

FYI, this XEP seems to be in last call after its end date.

> 1. Is this specification needed to fill gaps in the XMPP protocol stack
or
> to clarify an existing protocol?

Yes. AFAICT, there's no other way to reliably have conversations using XMPP
without exposing presence information to (other) contacts.

> 2. Does the specification solve the problem stated in the introduction
and
> requirements?

Yes.

> 3. Do you plan to implement this specification in your code?

If I had time, it would be high on my list :)

> 4. Do you have any security concerns related to this specification?

Not beyond what's stated in section 6.

> 5. Is the specification accurate and clearly written?

Yes.

Note that server implementations oft his XEP currently seem to be very
scarce.

Remko
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Ruslan N. Marchenko]

On 07.03.2017 12:31, Jonas Wielicki wrote:


I would like a rationale for why after going visible again, the session is
treated as before sending initial presence. This feels counter-intuitive to
me: I would expect all my contacts to see the presence I most recently sent to
those on my "visible list". While a client can surely implement it that way,
is there a rationale to not have it specified that way by setting the outbound
presence to the most recently sent during invisibility?
This thing I actually liked the most - very elegant, just send the 
presence you want to be after invisible. In the client it's simple (just 
re-send current presence). In the server it's simple (just broadcast and 
send probes).
I believe the rationale is consistency of the presence state. If server 
just rebroadcast last cached presence (even of cached for this 
connection) - it wouldn't be proper presence state since some(most?) 
implementations may stop sending presence once they received 
'unavailable'. And they are not obliged to re-send it on receiving the 
new one. So you may write - server must broadcast and probe but... this 
is what happens on initial presence.



What does a server do when a client does not send a  after going
visible when asked by peers to which the client has sent directed presence vs.
those to which the client has not sent directed presence?

If we follow XEP-0016 way - literally nothing.
Directed presence is special case anyway, and is required to be tracked 
regardless the visibility.


Secondly, what is the state of the Privacy Lists if they are used as a backing
store after the client goes offline during invisibility? Are those reset
automatically? This could use some clarification.

Invisibility is quite straight-forward command. It's just one priv.list 
item - presence-out. (if we ignore probe thingy). So
 =  hence to set is 
to add such item (auto-creating active list if necessary) and to unset 
is just remove any such item (autodeleting empty active list if necessary).
The same semantic as being using in blocking commands. Just with active 
list instead of default.
But yes, probe thingy. That changes the whole picture. Meaning normal 
priv.list backend can not be used as is, should be modified/extended to 
account for probe blocking (which is impossible with priv.lists - except 
total blackout case).


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Florian Schmaus]

On 07.03.2017 12:31, Jonas Wielicki wrote:
> On Dienstag, 28. Februar 2017 16:27:59 CET XMPP Extensions Editor wrote:
>> This message constitutes notice of a Last Call for comments on XEP-0186
>> (Invisible Command).
>>
>> 4. Do you have any security concerns related to this specification? 
> 
> The Security Considerations section is very vague. While I can imagine some 
> of 
> the scenarios hinted at, I think that mentioning some cases would not hurt. 
> Examples I am currently thinking of are disco#* (or all IQs to the client in 
> general) and Message Delivery Receipts. I’m sure there is more.

A presence leak is a generic XMPP security consideration which should be
handled in one canonical place, possibly put in one of the RFCs, and not
in one of the 300+ XEPs. Then XEP-0186, and other relevant XEPs like the
Message Delivery Receipts one, could point to that canonical place.

Unfortunately I only found RFC 6120 § 13.10.2 which discusses the
service's responsibility. Maybe it is worth to write an extra XEP for
this until 6120bis arrives?

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Jonas Wielicki]

On Dienstag, 28. Februar 2017 16:27:59 CET 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 protocol extension for user
> invisibility.
> 
> URL: https://xmpp.org/extensions/xep-0186.html
> 
> This Last Call begins today and shall end at the close of business on
> 2017-03-14.
> 
> 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? 

Yes.

> 2. Does the specification solve the problem stated in the introduction and 
> requirements? 

From reading it, it appears so.

> 3. Do you plan to implement this specification in your code? If not, why 
> not? 

Yes.

> 4. Do you have any security concerns related to this specification? 

The Security Considerations section is very vague. While I can imagine some of 
the scenarios hinted at, I think that mentioning some cases would not hurt. 
Examples I am currently thinking of are disco#* (or all IQs to the client in 
general) and Message Delivery Receipts. I’m sure there is more.

> 5. Is the specification accurate and clearly written?

I would like a rationale for why after going visible again, the session is 
treated as before sending initial presence. This feels counter-intuitive to 
me: I would expect all my contacts to see the presence I most recently sent to 
those on my "visible list". While a client can surely implement it that way, 
is there a rationale to not have it specified that way by setting the outbound 
presence to the most recently sent during invisibility?

What does a server do when a client does not send a  after going 
visible when asked by peers to which the client has sent directed presence vs. 
those to which the client has not sent directed presence?


Secondly, what is the state of the Privacy Lists if they are used as a backing 
store after the client goes offline during invisibility? Are those reset 
automatically? This could use some clarification.


kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Ruslan N. Marchenko]

On 28.02.2017 17:27, 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 protocol extension for user 
invisibility.

URL: https://xmpp.org/extensions/xep-0186.html

This Last Call begins today and shall end at the close of business on 
2017-03-14.

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?

Not really, but is handy nevertheless for client implementation

2. Does the specification solve the problem stated in the introduction and 
requirements?

Yes

3. Do you plan to implement this specification in your code? If not, why not?

Yes

4. Do you have any security concerns related to this specification?

No, security section list them accurately

5. Is the specification accurate and clearly written?
Spec still refers to XEP-0016 and XEP-0126 however latest amendment 
(probe blocking) directly contradicts to those XEPs making it incompatible.

I think it should be called out in interoperability section (Chapter 5).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[XMPP Extensions Editor]

This message constitutes notice of a Last Call for comments on XEP-0186 
(Invisible Command).

Abstract: This document specifies an XMPP protocol extension for user 
invisibility.

URL: https://xmpp.org/extensions/xep-0186.html

This Last Call begins today and shall end at the close of business on 
2017-03-14.

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!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Tomasz Sterna]

Dnia 2014-06-20, pią o godzinie 02:59 +, XMPP Extensions Editor
pisze:
 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
 clarify an existing protocol?

No.


 2. Does the specification solve the problem stated in the introduction and 
 requirements?

It appears so, but has numerous issues.


 3. Do you plan to implement this specification in your code? If not, why not?

No. I feel uncomfortable providing my users with something that only
appears to work, but is known to fail and be exploitable.
My opinion is that it's better to have none sense of security, than
having a false one.

I already implemented XEP-0191 in jabberd2, which I see as far better
solution to providing this feature.


 4. Do you have any security concerns related to this specification?

Yes.
It has been demonstrated over time, that there are numerous way of
probing real user presence. Also the specification has issues already
mentioned in this thread.


 5. Is the specification accurate and clearly written?

Yes.


-- 
Tomasz Sterna @ http://abadcafe.pl/ @ http://xiaoka.com/

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

[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 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.

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

[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 implement this feature, let's have a thought out 
approach for them instead of horrible hacks.



2. Does the specification solve the problem stated in the introduction and 
requirements?


Yes, it does.



3. Do you plan to implement this specification in your code? If not, why not?


I've implemented this twice already on the client side - in SleekXMPP and 
stanza.io.

However, I'm not aware of any server-side implementation to use those with.


I've been talking about adding it to Prosody. :-)


4. Do you have any security concerns related to this specification?


As mentioned in the XEP, it's still very easy to expose the fact that you're 
online, but any method of accomplishing presence invisibility will have that 
issue.


Yes, and this is one reason I don't like the entire concept of invisibility.

However, as noted, if we're going to do invisibility (and users want it 
so clients will be written to support it), then let's at least have a 
reasonable protocol for it.



One thing I notice not mentioned in the XEP is client handling of bookmarks set 
to auto join.


Good point. I'll add a note about that.

Peter

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

[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 the last undirected presence) to all
entities in the communicants list!?


That seems reasonable, although I think the presence could be mere 
presence with no availability state (e.g., if there was no previous 
presence notification because the user came online).



Here's my other feedback:


1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?


Yes. I remember using invisibility in ICQ back in the 90s :-) so it
should be in XMPP in 2014...


Well we have it, but in other ways. This way is better. IMHO. :-)


2. Does the specification solve the problem stated in the
introduction and requirements?


Yes, maintaining a privacy list on client side is cumbersome.


3. Do you plan to implement this specification in your code? If
not, why not?


Yes.


4. Do you have any security concerns related to this
specification?


Maybe presence leaks, while being invisible and in a MUC room (and
some occupants are also on your roster) could be mentioned?


Will add.


5. Is the specification accurate and clearly written?


Mostly yes. But some points: Is communicants a good term in this
context? http://en.wiktionary.org/wiki/communicant says its obsolete
and has primarily a religious meaning. I'm no native speaker though.


They're not really contacts (as in the roster), and the list of people 
you communicate with is awkward. I'll see if I can find a better term.



I think there's a typo the client behave as follows. Should be
behaves?


That's a subjunctive. :-)


Integration with privacy lists: How does the server know what are the
relevant privacy lists. Is it by convention the list named
invisible, which is being activated for the session? If yes,
wouldn't it prevent directed presence? XEP-0126 could have been
linked in this section.


I'll look into this part of the spec.

Thanks for your feedback!

Peter

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

[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 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 implement this feature, let's have a 
thought out approach for them instead of horrible hacks.



2. Does the specification solve the problem stated in the 
introduction and requirements?


Yes, it does.


3. Do you plan to implement this specification in your code? If not, 
why not?


I've implemented this twice already on the client side - in SleekXMPP 
and stanza.io.


However, I'm not aware of any server-side implementation to use those 
with.


I've been talking about adding it to Prosody. :-)


4. Do you have any security concerns related to this specification?


As mentioned in the XEP, it's still very easy to expose the fact that 
you're online, but any method of accomplishing presence invisibility 
will have that issue.


Yes, and this is one reason I don't like the entire concept of 
invisibility.


However, as noted, if we're going to do invisibility (and users want 
it so clients will be written to support it), then let's at least have 
a reasonable protocol for it.


One thing I notice not mentioned in the XEP is client handling of 
bookmarks set to auto join.


Good point. I'll add a note about that.

Peter

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

[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 then go offline.


-K


On Wed, Jul 16, 2014 at 9:47 AM, Stefan Karlsson s...@synergysky.com wrote:

 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
 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 implement this feature, let's have a thought
 out approach for them instead of horrible hacks.


  2. Does the specification solve the problem stated in the introduction
 and requirements?


 Yes, it does.


  3. Do you plan to implement this specification in your code? If not,
 why not?


 I've implemented this twice already on the client side - in SleekXMPP
 and stanza.io.

 However, I'm not aware of any server-side implementation to use those
 with.


 I've been talking about adding it to Prosody. :-)

  4. Do you have any security concerns related to this specification?


 As mentioned in the XEP, it's still very easy to expose the fact that
 you're online, but any method of accomplishing presence invisibility will
 have that issue.


 Yes, and this is one reason I don't like the entire concept of
 invisibility.

 However, as noted, if we're going to do invisibility (and users want it
 so clients will be written to support it), then let's at least have a
 reasonable protocol for it.

  One thing I notice not mentioned in the XEP is client handling of
 bookmarks set to auto join.


 Good point. I'll add a note about that.

 Peter

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

[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 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.

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

[Graham King]

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

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

[Christian Schudt]

I might be too late to the party, 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 the last undirected presence) to all entities in the 
communicants list!?

Here's my other feedback:

 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
 clarify an existing protocol?

Yes. I remember using invisibility in ICQ back in the 90s :-) so it should be 
in XMPP in 2014...

 2. Does the specification solve the problem stated in the introduction and 
 requirements?

Yes, maintaining a privacy list on client side is cumbersome.

 3. Do you plan to implement this specification in your code? If not, why not?

Yes.

 4. Do you have any security concerns related to this specification?

Maybe presence leaks, while being invisible and in a MUC room (and some 
occupants are also on your roster) could be mentioned?

 5. Is the specification accurate and clearly written?

Mostly yes. But some points:
Is communicants a good term in this context?
http://en.wiktionary.org/wiki/communicant says its obsolete and has primarily a 
religious meaning.
I'm no native speaker though.

I think there's a typo the client behave as follows. Should be behaves?

Integration with privacy lists: How does the server know what are the relevant 
privacy lists. Is it by convention the list named invisible, which is being 
activated for the session?
If yes, wouldn't it prevent directed presence?
XEP-0126 could have been linked in this section.

-- Christian

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

[Stefan Karlsson]

I am also a bit too late but; how does this work with XEP 0184?

/stefan

Christian Schudt skrev 06/07/14 20:56:

I might be too late to the party, 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 the last undirected presence) to all entities in the communicants 
list!?

Here's my other feedback:


1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?

Yes. I remember using invisibility in ICQ back in the 90s :-) so it should be 
in XMPP in 2014...


2. Does the specification solve the problem stated in the introduction and 
requirements?

Yes, maintaining a privacy list on client side is cumbersome.


3. Do you plan to implement this specification in your code? If not, why not?

Yes.


4. Do you have any security concerns related to this specification?

Maybe presence leaks, while being invisible and in a MUC room (and some 
occupants are also on your roster) could be mentioned?


5. Is the specification accurate and clearly written?

Mostly yes. But some points:
Is communicants a good term in this context?
http://en.wiktionary.org/wiki/communicant says its obsolete and has primarily a 
religious meaning.
I'm no native speaker though.

I think there's a typo the client behave as follows. Should be behaves?

Integration with privacy lists: How does the server know what are the relevant privacy 
lists. Is it by convention the list named invisible, which is being activated for 
the session?
If yes, wouldn't it prevent directed presence?
XEP-0126 could have been linked in this section.

-- Christian

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

[Kamil Kisiel]

Apologies for not replying in the thread, I joined the list after it was
posted so I'm not sure how to join the thread :)

For some background: I'm part of a team working on a (currently)
proprietary XMPP server and client. I have been working on the server side
and was responsible for the invisibility implementation.

1. Is this specification needed to fill gaps in the XMPP protocol stack or
to clarify an existing protocol?

Our service has a requirement to implement invisibility, and the other
invisibility specifications are woefully ill-defined compared to this one,
so I think it certainly fills a gap.

2. Does the specification solve the problem stated in the introduction and
requirements?

It appears to, though our experience using it is still limited at this
point.

3. Do you plan to implement this specification in your code? If not, why
not?

We have already implemented it in our server and client.

4. Do you have any security concerns related to this specification?

Inadvertently leaking presence is always a concern, but I don't believe
there's any easy solution to that.

5. Is the specification accurate and clearly written?

Yes, it specifies the rules in enough detail to make implementation
relatively straight-forward. There are of course lots of edge cases to
handle in other parts of the server code to avoid leaking presence but of
course it's not possible for the spec to exhaustively cover those.

-K

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

[XMPP Extensions Editor]

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!

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

[Lance Stout]

 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 implement this feature, let's have a thought out 
approach for them instead of horrible hacks.


 2. Does the specification solve the problem stated in the introduction and 
 requirements?

Yes, it does.


 3. Do you plan to implement this specification in your code? If not, why not?

I've implemented this twice already on the client side - in SleekXMPP and 
stanza.io.

However, I'm not aware of any server-side implementation to use those with.


 4. Do you have any security concerns related to this specification?

As mentioned in the XEP, it's still very easy to expose the fact that you're 
online, but any method of accomplishing presence invisibility will have that 
issue.


One thing I notice not mentioned in the XEP is client handling of bookmarks set 
to auto join.


 5. Is the specification accurate and clearly written?

Yes.



- Lance



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[XMPP Extensions Editor]

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 
2012-07-13.

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!