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:
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
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
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
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
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
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
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?
>
>
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:
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
25 matches
Mail list logo