Hi goffi and thanks for your feedback.
In §5.2 it may be worth noting that XEP-0497 lets you retrieve metadata directly with the disco#items request, avoiding to request each individual node.
I did not find where that was possible with XEP-0497, which I think is interesting to mention nevertheless. Can you point me to where getting metadata with disco#items request is possible in the text? I agree that subscribing to metadata updates is very interesting so I did mention XEP-0497 in "joining a space" nevertheless.
https://github.com/xsf/xeps/pull/1461/commits/bd3c9a933995c78b0624a67f5a2de2d28f119ee6
In §5.3 you may want to mention XEP-0465 (Pubsub Public Subscriptions) as it solves issues with XEP-0330 (but requires server support, so XEP-0330 is useful if XEP-0465 is not supported by the server).
Fair enough, added. https://github.com/xsf/xeps/pull/1461/commits/47658a8739a88592dfe62a4f43cd1d582eb1296e
In §5.4 you're making a confusion between disco#items request and pubsub get request. A disco#items request doesn't return the payload; it's a pubsub get that you want to do here.
Indeed. Fixed! https://github.com/xsf/xeps/pull/1461/commits/baf0c711de29640c378057779184fb869ee3f7a7
The reason is mostly syntax re-use. But it is a SHOULD, so it is not entirely forbidden to use another syntax to include pubsub nodes, right? I guess it would be nice if the element had a "name" or "description" element too.In §5.4 I don't see the point of using a <subscription> element to indicate a pubsub node. I mean, we only want the JID and node here, but it's ultimately the user/client who decides if they want to subscribe or not. It's just semantic, not a big deal though.
In §5.5 I think that `muc#roominfo_pubsub` is a poor choice. IMO it should be
a dedicated field that could be used for all items MUC, Pubsub, whatever alike
(something like `{urn:xmpp:spaces:0}parent`). And it should be a list of
strings, because a MUC or a node could be part of several spaces.
I made it a dedicated data form and mentioned muc#roominfo_pubsub as a fallback (compatible with current MUC service implementations). I agree that a dataform allows a consistent way for entities to advertise their parents, which is a good idea.
https://github.com/xsf/xeps/pull/1461/commits/ec9bc3eb4521be321a5d0a211eed4c73a3fc7100I am reluctant to allowing several parent spaces though, this sounds like a can of worms for clients to offer a consistent UI around. You could have additional spaces in other custom fields (which could be part of another XEP) if you have a use-case for this?
This could be done by using child nodes with XEP-0496. Not that it's really needed at this point, but it would be nice to leave the door open for child spaces.
Deal! I mentioned it. https://github.com/xsf/xeps/pull/1461/commits/9e44800b7c99f3719b9a3726fdb68d0cf2d51238
Another thing I would like to see is the possibility to add URLs, notably HTTP ones (e.g., if I make a space about my XMPP client, I want to add the official website, my blog, and maybe link my account on Mastodon or other platforms).
The space node can contain whatever, I added an <oob> element to point to a web site, does that work for you?
https://github.com/xsf/xeps/pull/1461/commits/e7a4efd287ae56b3843becc247f50f5048c26d2b Best, -- nicoco _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
