On 4/26/10 1:38 PM, Dave Cridland wrote: > 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 XEP >> > (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.
This is retrieval, not modification. Personally I'd use this all the time because I ask for roster items in determining if someone is an account owner: http://www.jabber.org/lost-password/ > 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. Sounds like fun, for some value of fun. ;) > Then we-XSF have a standardized roster management and manipulation > protocol, and we-Isode are certainly interested in having one. Alternatively, we could clean up XEP-0133 to use text-multi or jid-multi. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
