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
On Thu, Jul 16, 2009 at 3:01 PM, Fabio Forno 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 ham...@danemark.n
On Thu, Jul 16, 2009 at 3:27 PM, Kevin Smith 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 domain (s...@msn
On Thu, Jul 16, 2009 at 2:19 PM, 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
> - can rosters coming form separate services (each one with its o
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 doma
On Thu, Jul 16, 2009 at 9:49 AM, Pedro Melo 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 this might be on
On 2009/07/15, at 22:15, Fabio Forno wrote:
2009/7/15 Remko Tronçon :
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
storm if you ever
> 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 wor
2009/7/15 Remko Tronçon :
> 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
> storm if you ever use one client that doesn't support the p
2009/7/15 Remko Tronçon :
>> 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 s
> 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 ca
> 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,
On Wed, Jul 15, 2009 at 4:59 AM, Peter Saint-Andre 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
>
On 7/14/09 8:59 PM, "Peter Saint-Andre" 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
> urn:xm
-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" 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'
On 7/14/09 1:15 PM, "Fabio Forno" 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 case is very
>
On Tue, Jul 14, 2009 at 8:11 PM, Peter Saint-Andre 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
> relationship" wit
-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-Andre 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
On Tue, Jul 14, 2009 at 5:48 PM, Peter Saint-Andre 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 solves the probl
-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 w
> 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.
Openf
2009/7/14 Remko Tronçon :
>> 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 drawbacks. I
> 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 drawbacks. I think we should try defining a bett
On Tue, Jul 14, 2009 at 12:59 AM, Peter Saint-Andre 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 send an ad hoc
comma
-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-Andre 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
>> solve
On Mon, Jul 13, 2009 at 11:48 PM, Peter Saint-Andre 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.
>
We have two use
On Mon, Jul 13, 2009 at 11:07 PM, Brian Cully 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 is that it m
-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, intr
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 which
-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 o
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 re-synchroniz
31 matches
Mail list logo
