On Wed, 24 Sep 2003, Robert Norris wrote: [for the interested, links to "roster push by s10n subscribed packet":]
- Andrew & Rob's discussion http://www.jabber.org/chatbot/logs/conference.jabber.org/jdev/2003-09-23.html (search for "presence type") - "Bug" in jabberd2 http://www.jabberstudio.org/pipermail/jabberd/2002-December/000411.html - "Transports&contacts" thread on jdev in January 2003 http://article.gmane.org/gmane.network.jabber.devel/17874 (this is almost the same as the current thread) > I've been thinking about allowing (with certain restrictions) entities > to set and get a users roster. This (by itself) would require no client > changes. Basically, a transport could do normal roster get/set > operations (just like a client) If this was handled by extension of "subscribed" presence, it even would be more or less backwards compatible with jabberd14. But of course if it breaks XMPP... > - It allows transports to override the normal Jabber roster semantics. As Andrew said, the normal roster semantics is to *add new* contacts but we *import existing* contacts here. It's simply a thing that does not occur with Jabber-only usage. > - Suitable access controls are required. Obviously, it won't do to > allow anyone to change anyone elses roster. One thought we had is to > restrict operations based on the transport JID (domain) - ie, the > transport can only set roster items of its own users, and when a > roster is retrieved, it only receives items for its own users. (Roster retrieval would be indeed great and solve a great deal of hassle I described in http://article.gmane.org/gmane.network.jabber.devel/20097 :-) > - It seems that some sort of opt-in mechanism is required, whereby > users can authorise certain remote entities to modify their roster. > However, this requires client support, unless someone can think of > something better (one hackish idea we had was to make it based on > whether or not you've subscribed to a server (domain only) - if you > have, then they can play). One can combine these ideas - no opt-in required if domain already added to roster, opt-in required if not. Registering with the transport (and the following s10n exchange) means "I want to use the transport's services and let the transport do what it needs to" I think. Regards _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
