Thank you singpolyma for a very prompt feedback.

Fetching the list of rooms that are children of a space is done via a disco#items directed at the JID of the space on the urn:xmpp:spaces:0 node.  Using a node on top of the JID makes it possible for a space to be a room itself, which is possible but not required by this specification.

I don't think using a node is needed to fulfill this requirement. Any MUCs found as items on a MUC would be members surely? And any items on a space JID would be items in that space surely.

In https://xmpp.org/extensions/xep-0045.html#disco-roomitems

> An implementation MAY return a list of existing occupants if that information is publicly available, or return no list at all if this information is kept private.

So a spaces-capable public MUC room would return both its occupants and its children rooms, all mixed up together? I can see that working, since occupants have a resource part, while MUC rooms don't, so we have a (fragile?) heuristic to discriminate the two. Also, maybe MUC services actually do not implement this MAY for various reasons.

I am not against removing this node and just doing the disco#items dance on the space JID without node. I put it there because I was worried mixing occupants and children rooms would be a source of trouble for clients. I wonder what other client devs think about this. Maybe no actual implementation relies on disco#items queries on a room so it does not matter?

If we decide a node *is* needed, I think the node needs a name related to what it is. Naming the node the same name you suggest for a list of spaces to list the items in a space is confusing IMO.

Maybe we won't need it at all as you, but if we do, let's make it "urn:xmpp:space" (singular) then?

-- nicoco