[Standards] MUC rooms on roster.

Robin Redeker elmex at x-paste.de
Sat Aug 4 10:50:31 UTC 2007

On Fri, Aug 03, 2007 at 11:30:05AM +0200, Tomasz Sterna wrote:
> Dnia 03-08-2007, pią o godzinie 11:10 +0200, Robin Redeker napisał(a):
> > Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ?
> Hmm... I had always found this JEP awkward.
> We have roster to store these kinds of things.
> Early versions of jabberd/2 allowed storing an <x/> element with the
> roster item, that clients could store the additional item information.
> But it was explicitly forbidden by Standards JIG, thus removing support,
> which in turn resulted in JEP-0048.

Just some random thoughts here...

I also find XEP-0048 a bit awkward, but the limitation of the roster
for presence subscriptions seems to let no room for other informations
stored there. See also http://www.xmpp.org/extensions/xep-0083.html
(Nested Roster Groups) which I find equally awkward!

See also http://www.xmpp.org/extensions/xep-0057.html, which is probably
what you meant with storing additional <x> elements with the roster.

Also interesting is the way tkabber stores notes for roster items:

   <iq id='19' type='set' xml:lang='en-US'>
      <query xmlns='jabber:iq:private'>
         <storage xmlns='storage:rosternotes'>
            <note jid='ejabberd at conference.jabber.ru'
            <note jid='elmex at jabber.org'

Private XML storage is IMO a good solution for that. But I've not seen
any XEP for this kind of note storage (maybe I just couldn't find it).

Applications have to sync the roster with other places where information
for that JID is stored. I also miss a registrar for this kind of usage
of private XML storage.

Also note that the private XML storage will become more and more messy
with the number of different programs storing information there.

Does a way exist to purge all information in the XML storage? Or even
list the stored information? Listing stored information would allow the
removal of unknown elements by clients.

> > That works (see below) but there is a more pressing problem here:
> > [...]
> This is why I asked, to hear others feedback and issues.
> Could we use standard roster for it, or we really have to stick with the
> XEP-0048 defined alternative roster.

Well, back to the issue: I would not like to join every MUC I have on my
list just because I'm available. I would still like some MUCs only
optionally joined and not automatically.

How should that work? By unsubscribing from the MUC and not delete the
roster item? Would work I guess.

The problem here is XEP-0045 which defines the <x> element for
MUC-ability-signalling. I see no issues in storing many other things
in the roster, but I see issues with making that work with MUC the way
MUC is defined (which I don't really like either, but can't tell yet why


More information about the Standards mailing list