Re: [Standards] xep - 144
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 to put there. - 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.jabber.org yes, but not s...@jabber.org)? I prefer to restrict to the domain I think it MUST be restricted to the domain. The x...@msn.net would become xpto\40msn@msn.jabber.org. - what happens when the main roster contains jids in the same subdomain of the service? I'd say that all that entries should be ignored by the client Not sure yet. I don't see this as causing problems to the XMPP network as a whole, and in those cases, i don't see the need to restrict something that might be used creatively by smart client authors. - do we allow full jids export their own roster to other clients? I'd say no in the case, roster providers can be just domain jids. I don't see a useful use case for having JIDs export roster items to another, but I also don't see what harm would it cause. Best regards,
Re: [Standards] xep - 144
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.net is you roster, and then what? If your server > doesn't know that presence is never routed. This seems a special case > where some collaboration with server itself is needed > In all the other cases instead the presence to the service jid is sufficient Point taken. So even if you're running a shared roster service, it still needs to do JID transformation, and you could well be right :) >> You continue as usua (e.g. for a transport you could have the service >> and the service admin both in your main roster). > I was thinking of removal. If it happens that you have > s...@msn.jabber.org in the main roster and not more in the gateway it > means that you have deleted it, perhaps with a different client, but > you server will still think that you have a subscription. Instead if > we limit the secondary rosters to a subdomain the client know that > missing jids must be deleted from the main roster. (this should happen > in the ideal world, but during the transition it will be the rule) I'm not sure why this one's a big deal - I don't see why the same contact should end up in both your transport roster and your main roster. >>> - do we allow full jids export their own roster to other clients? I'd >>> say no in the case, roster providers can be just domain jids. >> I don't follow - are you asking if e.g. I could share my roster with you? > I was just wondering if a client entity could be a roster provider for > a different client entity. I've no idea of possible applications, and > I'd forbid it, but perhaps it's just lack of "vision" ;) It does sound interesting to be able to see other people's rosters, where authorised, so I wouldn't outright forbid it unless we need to. I have no real use case, though. Best, /K
Re: [Standards] xep - 144
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.jabber.org yes, but not s...@jabber.org)? >> I prefer to restrict to the domain > > 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.net is you roster, and then what? If your server doesn't know that presence is never routed. This seems a special case where some collaboration with server itself is needed In all the other cases instead the presence to the service jid is sufficient >> - what happens when the main roster contains jids in the same >> subdomain of the service? I'd say that all that entries should be >> ignored by the client > > You continue as usua (e.g. for a transport you could have the service > and the service admin both in your main roster). I was thinking of removal. If it happens that you have s...@msn.jabber.org in the main roster and not more in the gateway it means that you have deleted it, perhaps with a different client, but you server will still think that you have a subscription. Instead if we limit the secondary rosters to a subdomain the client know that missing jids must be deleted from the main roster. (this should happen in the ideal world, but during the transition it will be the rule) >> - do we allow full jids export their own roster to other clients? I'd >> say no in the case, roster providers can be just domain jids. > > I don't follow - are you asking if e.g. I could share my roster with you? I was just wondering if a client entity could be a roster provider for a different client entity. I've no idea of possible applications, and I'd forbid it, but perhaps it's just lack of "vision" ;) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
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 own > domain, e.g. msn.jabber.org) contain jids from other domains or only > in the same domain (s...@msn.jabber.org yes, but not s...@jabber.org)? > I prefer to restrict to the domain They can come from any domain - think of a shared roster/user groups service. > - what happens when the main roster contains jids in the same > subdomain of the service? I'd say that all that entries should be > ignored by the client You continue as usua (e.g. for a transport you could have the service and the service admin both in your main roster). > - do we allow full jids export their own roster to other clients? I'd > say no in the case, roster providers can be just domain jids. I don't follow - are you asking if e.g. I could share my roster with you? Best, /K
Re: [Standards] xep - 144
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 domains or only in the same domain (s...@msn.jabber.org yes, but not s...@jabber.org)? I prefer to restrict to the domain - what happens when the main roster contains jids in the same subdomain of the service? I'd say that all that entries should be ignored by the client - do we allow full jids export their own roster to other clients? I'd say no in the case, roster providers can be just domain jids. bye On Thu, Jul 16, 2009 at 12:11 PM, Fabio Forno wrote: > On Thu, Jul 16, 2009 at 9:49 AM, Pedro Melo wrote: [...[ > -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
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 one situation where you would have to use a big bang > approach: each user decides which protocol he wants to use, and all his > clients must use that one. > > I'm hoping someone smarter will come up with something better though :) > > Best regards, I've been thinking about it too. Indeed which is the real problem? Just duplicated entries, which will be seen by the new client only, and we can cope with them while merging the rosters and giving precedence to the component's entries. The benefits are so high that we can live with this little issue ;) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
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 use one client that doesn't support the protocol, which is indeed painful. That's why I would only check that at registration time, but that in turn will lead to questions like "Why don't i see my contacts if i log in with my mobile client?" 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 if it tries to add the contatcs to the main roster. After that for client A all the contacts are duplicated, and their handling may not be trivial. 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 one situation where you would have to use a big bang approach: each user decides which protocol he wants to use, and all his clients must use that one. I'm hoping someone smarter will come up with something better though :) Best regards,
Re: [Standards] xep - 144
> 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 if it tries to add the contatcs to the main > roster. After that for client A all the contacts are duplicated, and > their handling may not be trivial. That's what I tried to say ;-) cheers, Remko
Re: [Standards] xep - 144
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 protocol, > which is indeed painful. That's why I would only check that at > registration time, but that in turn will lead to questions like "Why > don't i see my contacts if i log in with my mobile client?" 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 if it tries to add the contatcs to the main roster. After that for client A all the contacts are duplicated, and their handling may not be trivial. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
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 software is upgraded to 3921bis, > and until then, they may not route jabber:iq:roster packages to > components (because of the special treatment of jabber:iqRoster in > 3921). A new protocol will not have this problem. Well, yes - but just using a new namespace everywhere would work ok too. Clients will have to jabber:iq:roster if their server only understands that regardless, but we can use the new namespace where it's supported everywhere. Yes, my motivation for this is largely that of the other thread - I'd like to upgrade roster handling while we're at it. /K
Re: [Standards] xep - 144
> 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 is very > common, since nobody uses the same client for teh desktop or mobiles) 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 protocol, which is indeed painful. That's why I would only check that at registration time, but that in turn will lead to questions like "Why don't i see my contacts if i log in with my mobile client?" cheers, Remko
Re: [Standards] xep - 144
> 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, and until then, they may not route jabber:iq:roster packages to components (because of the special treatment of jabber:iqRoster in 3921). A new protocol will not have this problem. cheers, Remko
Re: [Standards] xep - 144
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 > urn:xmpp:roster for the share groups functionality. 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? Best, /K
Re: [Standards] xep - 144
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:xmpp:roster for the share groups functionality. Sure, that would work, as long as the two schemas were fundamentally equal aside from namespace. If there was a single namespace with a backwards-compatibility mode, it would give us a chance to define an extensibility model, however. -- Joe Hildebrand
Re: [Standards] xep - 144
-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't work while using two >> different clients of which just one supports it (and the case is very >> common, since nobody uses the same client for teh desktop or mobiles) > > 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:xmpp:roster for the share groups functionality. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpdU8UACgkQNL8k5A2w/vzrGQCgh0Wz1bKvyZ40iBrhpdijydUc 2UQAn3eTGWunXXMjIYYa/IF57cYjwsY0 =88rf -END PGP SIGNATURE-
Re: [Standards] xep - 144
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 > common, since nobody uses the same client for teh desktop or mobiles) 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? If we were to do this, of course, it opens the question of what that new roster protocol should look like, but we could choose be relatively conservative about changes. -- Joe Hildebrand
Re: [Standards] xep - 144
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" with any other entity, such as shared groups service. With the only caveat that clients must pay attention to the from in roster sets. This puts a bit more complexity in the service and the client, especially if we want to support roster versioning for all the components, but the overall advantages are clear. I like it also for social applications, in that way the service can add/remove special contacts accordingly to the active feeds of the user, without cluttering the main roster >> So yes, let's use standard rosters for transports and shared groups, >> and let's keep roster item exchange just for sharing contacts. > > WFM. 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 common, since nobody uses the same client for teh desktop or mobiles) -- Fabio Forno, Ph.D. Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
-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 get all the XSF members in a special "Members" group). > > This is so simple and solves the problem so well that I have no idea > why we haven't been doing it from the start. Good catch. > It solves a bunch of issues, like levels of trust with the transport > to edit your roster, of migration between transports or servers, > groups within the transport, contact naming, and jid escaping. 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" with any other entity, such as shared groups service. > So yes, let's use standard rosters for transports and shared groups, > and let's keep roster item exchange just for sharing contacts. WFM. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpcymMACgkQNL8k5A2w/vzq1gCgulBtR8U2mhlA+2Y+rYXo0+/u UO8AoJFeaVlpXBvA9BUpComKYqfDRDyP =IOCk -END PGP SIGNATURE-
Re: [Standards] xep - 144
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 problem so well that I have no idea why we haven't been doing it from the start. Good catch. It solves a bunch of issues, like levels of trust with the transport to edit your roster, of migration between transports or servers, groups within the transport, contact naming, and jid escaping. So yes, let's use standard rosters for transports and shared groups, and let's keep roster item exchange just for sharing contacts. Yay. /K
Re: [Standards] xep - 144
-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 >> don't want to hack into the server, is to directly tell the client >> what to do. > > Openfire lets the components use jabber:iq:roster on a user's roster, > but that involves quite a bit of trust on the component (as it has > access to the full roster). > > I meant something different: > - The client logs in > - It gets presence from "gateway.example.com", which includes the > "shared-roster" capability > - It does a jabber:iq:roster request on gateway.example.com > - It adds the resulting items to the *displayed* roster (not the master > roster) > - The gateway acts as a real server from now on: it sends presence, > subscription requests, and roster pushes for all contacts in its > roster to the client that requested the roster, and forwards presence > to all contacts in the reverse direction. 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). I agree that it would be better to have two different protocols: one for sharing roster items with friends (preferably also coupled with the ability to make introductions) and another for shared groups. I've never liked how XEP-0144 muddied the waters of roster item sharing, which were much clearer in XEP-0093. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpctsMACgkQNL8k5A2w/vwzcACeNM7pndb2Uw75ZOLfF0QBqgjp S8AAn31k3tqgUGhvxEfkgs66G6nmDUPk =iNw8 -END PGP SIGNATURE-
Re: [Standards] xep - 144
> 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 lets the components use jabber:iq:roster on a user's roster, but that involves quite a bit of trust on the component (as it has access to the full roster). I meant something different: - The client logs in - It gets presence from "gateway.example.com", which includes the "shared-roster" capability - It does a jabber:iq:roster request on gateway.example.com - It adds the resulting items to the *displayed* roster (not the master roster) - The gateway acts as a real server from now on: it sends presence, subscription requests, and roster pushes for all contacts in its roster to the client that requested the roster, and forwards presence to all contacts in the reverse direction. This will of course only work for clients supporting the protocol, but I don't think there's a clean other way that doesn't have too much trust or privacy issues. A component could check at registration time whether the client supports the protocol, and use the old ways if not. This would mean that the user needs to re-register if it switches to a client which does / does not support the protocol and wishes to use the gateway, but this should phase out eventually. cheers, Remko
Re: [Standards] xep - 144
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 think we should try defining a better protocol > for this. Indeed psi still has the problem of storms, since after presenting the addition request it asks to authorize each presence subscription arriving from the gateway as an answer. However this is just an implementation issue easily fixable. > I liked the thought we had a few years ago where you could use > jabber:iq:roster on something else than a server JID (which was > prohibited by the RFC back then, I forgot if we did something about > that in bis). Remote rosters such as component rosters wouldn't need > to be mirrored in your real roster any more, which would solve quite a > bit of problems. 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. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
> 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 better protocol for this. I liked the thought we had a few years ago where you could use jabber:iq:roster on something else than a server JID (which was prohibited by the RFC back then, I forgot if we did something about that in bis). Remote rosters such as component rosters wouldn't need to be mirrored in your real roster any more, which would solve quite a bit of problems. cheers, Remko
Re: [Standards] xep - 144
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 command containing the block of roster "commands" that the client should apply, ad we wait for the list of accepted commands as result bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
-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 >> solves compelling use cases. XEP-0093 was simpler and therefore better, >> IMHO. >> > > We have two use cases: > - exchange of business cards, where xep-0093 was good, since we don't > care if the items are processed > - roster sync with a component (it may be a transport, but also a > component hosting different services), and for that we'd like to see > the result of the operation Right, but I keep wondering if modifying XEP-0093 to include the second use case was wrong... Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpbvGQACgkQNL8k5A2w/vwchgCfey+WKPauaUcWSwpM0ZLTl7M6 WeQAoJcfLvPVAnsCpP5BYc6gihdtkzcN =BMMW -END PGP SIGNATURE-
Re: [Standards] xep - 144
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 cases: - exchange of business cards, where xep-0093 was good, since we don't care if the items are processed - roster sync with a component (it may be a transport, but also a component hosting different services), and for that we'd like to see the result of the operation bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
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 merely advises the client to make changes to its roster and > is only concerned with the client having accepted the changes (even if it > didn't employ them). If a client decides not to take a change a future > request for a roster push probably shouldn't push out that change again (the > client already reviewed it and said, "no"). Indeed this is the problem we have in absence of feedback: we don't know if the client reject it or it simply didn't process it, and therefore we can't resend additions. The result we observed is that after a while the roster then to be de-synchronized > As for re-synchronizing the roster, as I recall the spec there's no > way to synchronize the roster either. Hence the ad-hoc command interface, > which can be easily extended to do a full push again, if necessary. This is one option we have, however there is no easy way to detect deletions with the present specs (the client can't keep track of who added the contacts, so missing contacts in the resend can't be dedected > 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. Briedly waht we have in mind: - for the first issue we plan to add an id to the addition The client therefore sends a result when it receives the stanza, as it happens now. Then after the user has processed the changes it sends backcontaining the accepted items - for the second issue we would like to send an of type get, specifying a "query" asking for all the contacts of a given group or domain, so that we can compare the result with the contacts we have in the roster and detect deletions too; as you say this can be done with an ad hoc command too, in that case I'd like to write an example in the xep in order to document the practice. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
-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, 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. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpbq8YACgkQNL8k5A2w/vxxNACeKdPBAdTh11kI1eAQBM1Zxs0Y gooAn02BHq36Igbl4EAqtZHsnPF7FuGm =F19j -END PGP SIGNATURE-
Re: [Standards] xep - 144
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 modifications of the roster have been accepted - lack of any mechanism for re-synchronizing the roster if something wen wrong Therefore we are thinking to extend the XEP in order to address these issues, the only problem is that we could propose some breaking changes, therefore we'd like to know if anybody is : - using the XEP (we know that psi does, but the implementation is not very usable, I think for the lack of testing since no transport is using it) - planning to use it, in that case any suggestion? There were some implementations of XEP-0093 in the old old days (Gabber, Winjab, etc.), but this has never been the most popular feature. If we want to design yet another approach, that would be fine with me (if it fixes all the issues). 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 merely advises the client to make changes to its roster and is only concerned with the client having accepted the changes (even if it didn't employ them). If a client decides not to take a change a future request for a roster push probably shouldn't push out that change again (the client already reviewed it and said, "no"). As for re-synchronizing the roster, as I recall the spec there's no way to synchronize the roster either. Hence the ad-hoc command interface, which can be easily extended to do a full push again, if necessary. 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. -bjc
Re: [Standards] xep - 144
-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 which > modifications of the roster have been accepted > - lack of any mechanism for re-synchronizing the roster if something wen wrong > > Therefore we are thinking to extend the XEP in order to address these > issues, the only problem is that we could propose some breaking > changes, therefore we'd like to know if anybody is : > - using the XEP (we know that psi does, but the implementation is not > very usable, I think for the lack of testing since no transport is > using it) > - planning to use it, in that case any suggestion? There were some implementations of XEP-0093 in the old old days (Gabber, Winjab, etc.), but this has never been the most popular feature. If we want to design yet another approach, that would be fine with me (if it fixes all the issues). Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpbh+YACgkQNL8k5A2w/vwC9ACgzPU0W0GdOfeZYE9BM9rzDD4w 8xoAoN5J8PlUc8dPFnhnoPNTZCxoK6gb =zFeI -END PGP SIGNATURE-
[Standards] xep - 144
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-synchronizing the roster if something wen wrong Therefore we are thinking to extend the XEP in order to address these issues, the only problem is that we could propose some breaking changes, therefore we'd like to know if anybody is : - using the XEP (we know that psi does, but the implementation is not very usable, I think for the lack of testing since no transport is using it) - planning to use it, in that case any suggestion? bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
