On 2009/07/16, at 14:19, Fabio Forno wrote:
Some more thoughts, which are the business rules for accepting roster
items? I explain with some cases:
- in the main roster on the server we have jids coming from any domain
The main roster is under the client control, so I guess he decides
what
We have two clients, A and B, only A supports the new protocol. A
registers with the gateway so that contacts are not set in the main
roster. Then B sends its presence and the gw what should do? If if
does nothing, since the client won't get roster we just miss the
contacts, but it is worse
On 2009/07/15, at 22:15, Fabio Forno wrote:
2009/7/15 Remko Tronçon re...@el-tramo.be:
True. If we use a new protocol, a client can announce support of it
through entity capabilities, and the service can decide what to do at
presence-receive time. Of course, this will still mean an add/auth
On Thu, Jul 16, 2009 at 9:49 AM, Pedro Melom...@simplicidade.org wrote:
I've been thinking about this problem and I don't see a solution for this
that is compatible with different generation of clients (those who support
trusted sources for jabber:iq:roster and those that don't).
I think
Some more thoughts, which are the business rules for accepting roster
items? I explain with some cases:
- in the main roster on the server we have jids coming from any domain
- can rosters coming form separate services (each one with its own
domain, e.g. msn.jabber.org) contain jids from other
On Thu, Jul 16, 2009 at 2:19 PM, Fabio Fornofabio.fo...@gmail.com wrote:
Some more thoughts, which are the business rules for accepting roster
items? I explain with some cases:
- in the main roster on the server we have jids coming from any domain
- can rosters coming form separate services
On Thu, Jul 16, 2009 at 3:27 PM, Kevin Smithke...@kismith.co.uk wrote:
- in the main roster on the server we have jids coming from any domain
- can rosters coming form separate services (each one with its own
domain, e.g. msn.jabber.org) contain jids from other domains or only
in the same
On Thu, Jul 16, 2009 at 3:01 PM, Fabio Fornofabio.fo...@gmail.com wrote:
They can come from any domain - think of a shared roster/user groups service.
Uhm, I'm trying to think together with presence delivery too. Shared
roster is bit tricky in that, since shared.jabber.org could tell you
that
On Wed, Jul 15, 2009 at 4:59 AM, Peter Saint-Andrestpe...@stpeter.im wrote:
Could we just do a new urn:xmpp:roster namespace, expose your master roster
via that namespace (also), and use that new namespace to talk to external
entities?
Or we could use jabber:iq:roster as we always have in the
I'm sure there were good reasons for both these suggestions - I can
understand why if we upgrade the usage we can upgrade the namespace,
but what is the motivation for suggesting two different namespaces for
the same job?
It will take some time until server software is upgraded to 3921bis,
Two small issues:
- it won't work until servers route the packets (small fix, but
upgrades are needed)
Indeed. This could be solved by using a new protocol.
- transition will be difficult, since if it can't work while using two
different clients of which just one supports it (and the case
2009/7/15 Remko Tronçon re...@el-tramo.be:
I'm sure there were good reasons for both these suggestions - I can
understand why if we upgrade the usage we can upgrade the namespace,
but what is the motivation for suggesting two different namespaces for
the same job?
It will take some time until
2009/7/14 Remko Tronçon re...@el-tramo.be:
Right, but I keep wondering if modifying XEP-0093 to include the second
use case was wrong...
It wasn't really a good flow, no. Psi implements this XEP too, and it
helps with the whole auth-storm-on-gateway-registration, but still has
quite some
Openfire allows this, and the gateways use jabber:iq:roster. It works
fine, but in order to use too roster sequencing I'd like to have a
centralized repository of the roster, and the best approach, if we
don't want to hack into the server, is to directly tell the client
what to do.
Openfire
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/14/09 3:42 AM, Remko Tronçon wrote:
Openfire allows this, and the gateways use jabber:iq:roster. It works
fine, but in order to use too roster sequencing I'd like to have a
centralized repository of the roster, and the best approach, if we
On Tue, Jul 14, 2009 at 5:48 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
- It does a jabber:iq:roster request on gateway.example.com
This is not limited to gateways, but also to shared groups services
(e.g., you get all the XSF members in a special Members group).
This is so simple and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/14/09 11:04 AM, Kevin Smith wrote:
On Tue, Jul 14, 2009 at 5:48 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
- It does a jabber:iq:roster request on gateway.example.com
This is not limited to gateways, but also to shared groups services
On Tue, Jul 14, 2009 at 8:11 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
We have long resisted this because we saw jabber:iq:roster as all and
only between you and your server (cf. recent discussion about 3921bis on
the XMPP WG list). If we remove that restriction, you can have a roster
On 7/14/09 1:15 PM, Fabio Forno fabio.fo...@gmail.com wrote:
Two small issues:
- it won't work until servers route the packets (small fix, but
upgrades are needed)
- transition will be difficult, since if it can't work while using two
different clients of which just one supports it (and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/14/09 9:45 PM, Joe Hildebrand wrote:
On 7/14/09 1:15 PM, Fabio Forno fabio.fo...@gmail.com wrote:
Two small issues:
- it won't work until servers route the packets (small fix, but
upgrades are needed)
- transition will be difficult, since
On 7/14/09 8:59 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
Could we just do a new urn:xmpp:roster namespace, expose your master roster
via that namespace (also), and use that new namespace to talk to external
entities?
Or we could use jabber:iq:roster as we always have in the past, with
Hi,
we are trying to use XEP 144 for synchronizing the roster of our
mobile client with remote services, but we encountered a number of
issues, mainly:
- lack of feedback from the client to the service of which
modifications of the roster have been accepted
- lack of any mechanism for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/13/09 3:44 AM, Fabio Forno wrote:
Hi,
we are trying to use XEP 144 for synchronizing the roster of our
mobile client with remote services, but we encountered a number of
issues, mainly:
- lack of feedback from the client to the service of
On 13-Jul-2009, at 15:15, Peter Saint-Andre wrote:
On 7/13/09 3:44 AM, Fabio Forno wrote:
we are trying to use XEP 144 for synchronizing the roster of our
mobile client with remote services, but we encountered a number of
issues, mainly:
- lack of feedback from the client to the service of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/13/09 3:07 PM, Brian Cully wrote:
That being said, I'm not the biggest fan of XEP-0144, and would be
keen to see any proposed changes although I lack any of my own at this
time.
I like the idea of being able to share roster items,
On Mon, Jul 13, 2009 at 11:07 PM, Brian Cullybcu...@gmail.com wrote:
I am using it in-house with an ad-hoc command interface, and it works
passably. I'm not sure about the points raised here. Regarding lack of
feedback, this might be considered a feature. My understanding of roster
push
On Mon, Jul 13, 2009 at 11:48 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
I like the idea of being able to share roster items, introduce one
person to another over IM, etc. But I'm not convinced that XEP-0144
solves compelling use cases. XEP-0093 was simpler and therefore better,
IMHO.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/13/09 4:57 PM, Fabio Forno wrote:
On Mon, Jul 13, 2009 at 11:48 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
I like the idea of being able to share roster items, introduce one
person to another over IM, etc. But I'm not convinced that
On Tue, Jul 14, 2009 at 12:59 AM, Peter Saint-Andrestpe...@stpeter.im wrote:
Right, but I keep wondering if modifying XEP-0093 to include the second
use case was wrong...
An approach could be resurrecting xep-0093 for the first case and use
ad hoc commands for the whole second one. We just
29 matches
Mail list logo
