[Standards] XEP-0133 get roster
stpeter at stpeter.im
Wed Jun 2 04:20:35 UTC 2010
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards