[Standards] XEP-0133 get roster

Dave Cridland dave at cridland.net
Mon Apr 26 19:38:07 UTC 2010

On Mon Apr 26 17:06:53 2010, Florian Zeitz wrote:
> On 26.04.2010 11:57, Kevin Smith wrote:
> > I'd not noticed the oddness in the get-user-roster command in  
> Service
> > Administration before. It seems out of place with the rest of the  
> > (which claims to be an ad-hoc profile) to have this command in  
> there
> > that requires special client support. Should this be returned in a
> > text-multi instead (or as well)? I can see the appeal of re-using
> > roster semantics for returning the roster, but it doesn't seem to  
> fit
> > with the idea of a generic admin interface.
> >
> > Thoughts?
> >
> > /K
> I had this "problem" some time ago when implementing this for  
> Prosody.
> (Don't ask me why I didn't bring it up here, probably just forgot)
> I choose to additionally return the roster XML in a text-multi  
> field.
> This is admittedly pretty ugly, but as close as I got when trying to
> convey the same information.

I'd say strip it out of XEP-0133, and add in the ability for entities  
other than the user to modify the user's roster, and define semantics  
for when they do.

For example, it might be interesting to have roster edits either  
override the existing subscription, or else cause suitable <presence  
type='[un]subscribe[d]'/> stanzas to be emitted.

Then we-XSF have a standardized roster management and manipulation  
protocol, and we-Isode are certainly interested in having one.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list