-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciao Fabio! :)
On 5/29/09 5:00 PM, Fabio Forno wrote: > On Fri, May 29, 2009 at 3:42 AM, Peter Saint-Andre <[email protected]> wrote: >> for historical purposes, so I'd be fine with keeping that as Deprecated. >> It seems to me that both XEPs 93 and 144 (which define different flavors >> of roster item exchange) are not widely implemented, so I'm agnostic >> about those. > > XEP 144 is useful but it has two problems: > > - the result iq is just an ack saying that the receiver has received > the roster modification, be we don't know if the user has accepted the > new items or not (in some cases it can be done indirectly, but it is > not easy) > - there should be more sophisticated way to negotiate the level of > trust with the roster modifier (e.g. in a Facebook gateway we don't > want to accept again the contacts since we already did it) > > Moreover, if we move from a pure IM scenario to a platform for > offering services, I think that XEP-144 is crucial for automating the > interaction with different service providers. For example in a > geolocal based application I don't want users to continuously search > for contacts and approve them while moving, but I'd like to have > roster group which is continuously updated with the services available > in the current context. Yes, I agree. Is XEP-0144 good enough, or do we need to (1) improve it or (2) define yet another approach to solving the problem? 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 iEYEARECAAYFAkogiRAACgkQNL8k5A2w/vwgbACg795vRZgjIhf8s5WIAtBec2uP oYAAn0hazyQEgfRjlp1HWMWAqDJeU78l =HQe3 -----END PGP SIGNATURE-----
