I'm not a big fan of invisibility, but if we're going to do it then we
might as well do it right.
Some clients and servers use XEP-0018, but it violates the core XMPP
specs, which seems like a bad idea.
Some clients and server use privacy lists (XEP-0016 + XEP-0126), but
they're complicated and
On 29 May 2012 16:35, Peter Saint-Andre stpe...@stpeter.im wrote:
I'm not a big fan of invisibility, but if we're going to do it then we
might as well do it right.
Some clients and servers use XEP-0018, but it violates the core XMPP
specs, which seems like a bad idea.
Some clients and
On Tue, May 29, 2012 at 4:35 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
I'm not a big fan of invisibility, but if we're going to do it then we
might as well do it right.
Some clients and servers use XEP-0018, but it violates the core XMPP
specs, which seems like a bad idea.
Some
On May 29, 2012, at 09:35, Peter Saint-Andre wrote:
I'm not a big fan of invisibility, but if we're going to do it then we
might as well do it right.
Some clients and servers use XEP-0018, but it violates the core XMPP
specs, which seems like a bad idea.
Some clients and server use
On Tue, May 29, 2012 at 5:03 PM, Matthew Miller
linuxw...@outer-planes.net wrote:
On May 29, 2012, at 09:35, Peter Saint-Andre wrote:
I'm not a big fan of invisibility, but if we're going to do it then we
might as well do it right.
Some clients and servers use XEP-0018, but it violates the
On May 29, 2012, at 10:04, Kevin Smith wrote:
On Tue, May 29, 2012 at 5:03 PM, Matthew Miller
linuxw...@outer-planes.net wrote:
On May 29, 2012, at 09:35, Peter Saint-Andre wrote:
I'm not a big fan of invisibility, but if we're going to do it then we
might as well do it right.
Some
XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
Thoughts?
I'd note that in 3.1.1. the server MUST NOT send presence probes when
being the client is in invisible mode. Of course that makes invisibility
much less useful ;-)
On Tue, May 29, 2012 at 5:12 PM, Philipp Hancke
fi...@goodadvice.pages.de wrote:
XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
Thoughts?
I'd note that in 3.1.1. the server MUST NOT send presence probes when being
the client is in invisible mode. Of course that makes
G'day,
It seems that it's not possible to be visible to only a roster group with
XEP-0186 (except by sending directed presence to each jid individually).
For me it's an important point do manage visibility at the roster group level,
this is possible with privacy lists, not with XEP-0186.
On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote:
XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
Thoughts?
I'd note that in 3.1.1. the server MUST NOT send presence probes when being
the client is in invisible mode. Of course that makes
Version 0.2 of XEP-0289 (Federated MUC for Constrained Environments) has been
released.
Abstract: This document provides a protocol for federating MUC rooms together
in order to reduce the effects of constrained network (e.g. unreliability,
severely limited bandwidth) on the room occupants.
Version 0.3 of XEP-0312 (PubSub Since) has been released.
Abstract: This specification defines a publish-subscribe feature that enables a
subscriber to automatically receive pubsub and PEP notifications since the last
logout time of a specific resource.
Changelog: Corrected namespace to use
On 5/29/12 10:02 AM, Kevin Smith wrote:
On Tue, May 29, 2012 at 4:35 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
I'm not a big fan of invisibility, but if we're going to do it then we
might as well do it right.
Some clients and servers use XEP-0018, but it violates the core XMPP
specs,
On 5/29/12 10:36 AM, Matthew Wild wrote:
On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote:
XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
Thoughts?
I'd note that in 3.1.1. the server MUST NOT send presence probes when being
the client is in
On 5/29/12 10:16 AM, Goffi wrote:
G'day,
It seems that it's not possible to be visible to only a roster group with
XEP-0186 (except by sending directed presence to each jid individually).
For me it's an important point do manage visibility at the roster group
level,
this is possible
On 29 May 2012 17:53, Peter Saint-Andre stpe...@stpeter.im wrote:
On 5/29/12 10:36 AM, Matthew Wild wrote:
On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote:
XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
Thoughts?
I'd note that in 3.1.1. the
On May 29, 2012, at 10:53, Peter Saint-Andre wrote:
On 5/29/12 10:36 AM, Matthew Wild wrote:
On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote:
XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
Thoughts?
I'd note that in 3.1.1. the server MUST
On Tue, May 29, 2012 at 6:02 PM, Matthew Wild mwi...@gmail.com wrote:
On 29 May 2012 17:53, Peter Saint-Andre stpe...@stpeter.im wrote:
On 5/29/12 10:36 AM, Matthew Wild wrote:
On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote:
XEP-0186 move to Draft so that we can deprecate
On 29 May 2012 18:03, Matthew Miller linuxw...@outer-planes.net wrote:
On May 29, 2012, at 10:53, Peter Saint-Andre wrote:
On 5/29/12 10:36 AM, Matthew Wild wrote:
On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote:
XEP-0186 move to Draft so that we can deprecate XEP-0018
On 5/29/12 10:12 AM, Philipp Hancke wrote:
XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126.
Thoughts?
I'd note that in 3.1.1. the server MUST NOT send presence probes when
being the client is in invisible mode. Of course that makes invisibility
much less useful ;-)
On Tue, May 29, 2012 at 6:09 PM, Matthew Wild mwi...@gmail.com wrote:
On 29 May 2012 18:03, Matthew Miller linuxw...@outer-planes.net wrote:
On May 29, 2012, at 10:53, Peter Saint-Andre wrote:
On 5/29/12 10:36 AM, Matthew Wild wrote:
On 29 May 2012 17:12, Philipp Hancke
Am 29.05.2012 19:03, schrieb Matthew Miller:
RFC 6121 specifies probes be sent 'from' a bare JID 'to' a bare JID. I think
this limits the presence leak severely, but that's my interpretation (-:
Well, yes. Unfortunately, my server has a much higher interest in
keeping me informed about who
On Mon, May 21, 2012 at 12:39 PM, Ashley Ward ashley.w...@surevine.com wrote:
Hi,
I have recently been tackling a problem with a BOSH connected chat client
as follows:
1. Client requests a connection, with rid 12345
2. Server has nothing to send so holds the connection open
3. Connection
I don't actually understand how this XEP can work with generic (not PEP)
pubsub? I have to subscribe to each pubsub service which nodes I have
subscribed to? It's an overhead, isn't it?
On 05/29/2012 11:42 PM, XMPP Extensions Editor wrote:
Version 0.3 of XEP-0312 (PubSub Since) has been
On Wed, 2012-05-30 at 00:47 +0700, Sergey Dobrov wrote:
I don't actually understand how this XEP can work with generic (not PEP)
pubsub? I have to subscribe to each pubsub service which nodes I have
subscribed to? It's an overhead, isn't it?
Isn't the reverse, ie the pubsub service needs to
On Tuesday, May 29, 2012 10:09:27 AM Matthew Wild wrote:
PS. and it'll only be a short time after that that a module is written
to automatically send probes randomly while the user is offline...
+1 for faster logins
On 29 May 2012 18:57, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
On Tuesday, May 29, 2012 10:09:27 AM Matthew Wild wrote:
PS. and it'll only be a short time after that that a module is written
to automatically send probes randomly while the user is offline...
+1 for
Am 29.05.2012 20:04, schrieb Matthew Wild:
On 29 May 2012 18:57, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
On Tuesday, May 29, 2012 10:09:27 AM Matthew Wild wrote:
PS. and it'll only be a short time after that that a module is written
to automatically send probes
On 05/30/2012 12:48 AM, Kim Alvefur wrote:
On Wed, 2012-05-30 at 00:47 +0700, Sergey Dobrov wrote:
I don't actually understand how this XEP can work with generic (not PEP)
pubsub? I have to subscribe to each pubsub service which nodes I have
subscribed to? It's an overhead, isn't it?
Isn't
On Tuesday, May 29, 2012 11:04:46 AM Matthew Wild wrote:
On 29 May 2012 18:57, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
On Tuesday, May 29, 2012 10:09:27 AM Matthew Wild wrote:
PS. and it'll only be a short time after that that a module is written
to automatically
On 5/29/12 12:27 PM, Sergey Dobrov wrote:
On 05/30/2012 12:48 AM, Kim Alvefur wrote:
On Wed, 2012-05-30 at 00:47 +0700, Sergey Dobrov wrote:
I don't actually understand how this XEP can work with generic (not PEP)
pubsub? I have to subscribe to each pubsub service which nodes I have
Version 0.10 of XEP-0186 (Invisible Command) has been released.
Abstract: This document specifies an XMPP-compatible protocol for user
invisibility.
Changelog: Further clarified server and client handling of stanzas during an
invisibility session; updated RFC references. (psa)
Diff:
Le 29/05/2012 19:01, Peter Saint-Andre a écrit :
So it sounds as if you're a target user for privacy lists. :) I'm not
necessarily interested in forbidding or deprecating privacy lists, but
in general I think they're complicated and that invisiblity and
blocking are the most common use cases,
On 5/28/12 1:53 AM, Sergey Dobrov wrote:
On 05/26/2012 01:23 AM, Peter Saint-Andre wrote:
On 5/23/12 1:28 AM, Sergey Dobrov wrote:
On 05/23/2012 03:24 AM, Peter Saint-Andre wrote:
But I certainly might want to receive the last published item whenever I
log in. This too seems like a setting
On 5/29/12 4:31 PM, Goffi wrote:
Le 29/05/2012 19:01, Peter Saint-Andre a écrit :
So it sounds as if you're a target user for privacy lists. :) I'm not
necessarily interested in forbidding or deprecating privacy lists, but
in general I think they're complicated and that invisiblity and
Version 0.5 of XEP-0267 (Server Buddies) has been released.
Abstract: This specification defines a convention for presence subscriptions
between XMPP servers.
Changelog: Corrected several examples and points in the text. (psa)
Diff: http://xmpp.org/extensions/diff/api/xep/0267/diff/0.4/vs/0.5
Version 0.3 of XEP-0309 (Service Directories) has been released.
Abstract: This specification shows how to combine and extend a number of
existing XMPP protocols for improved sharing of information about XMPP servers.
Changelog: Corrected a number of details in the text, examples, and XMPP
Question: Can this extension (XEP-00267) used with Components? The ability
for components to send and receive presence is important to us but the Jabber
Component extension doesn't really expand on this much. I believe they can
receive presence information as, at least with OpenFire, you can
Version 0.6 of XEP-0268 (Incident Handling) has been released.
Abstract: This specification defines methods for incident reporting among XMPP
server deployments using the IODEF format produced by the IETF's INCH Working
Group.
Changelog: Aligned document with the IETF guidelines for defining
On 5/29/12 8:33 PM, Todd Herman wrote:
Question: Can this extension (XEP-00267) used with Components? The
ability for components to send and receive presence is important to
us but the Jabber Component extension doesn't really expand on this
much. I believe they can receive presence
Understood. I may take the time to look at the Jabber Component XEP a bit more
and see about fleshing it out some. The XSD shows presence but it doesn't
really discuss how presence is shared. For client's, presence is related to a
roster. I suppose there is nothing stopping you from
I suppose there is nothing stopping you from subscribing directly to a
components presence.
Right, components can do everything a client can do, including sending presence
and handling presence subscriptions (after all, that's part of what makes
gateways work). The distinction, aside from
42 matches
Mail list logo
