Thanks Goffi, Thanks! I agree: it is desirable to have a section in XEP-0060 that allows nodes to be discovered. Am I right to assume that, in the context of XEP-0060 *without* XEP-0248, this is a single service disco#items request (to the pubsub service JID), that returns one result (possibly paginated/searchable)? If that is indeed true, then I think we should replace examples 9, 10, 11 and 12 (and corresponding texts) with just two examples that do 'only' that: this removes significant complexity. What is now 9, 10, 11 and 12 should go into XEP-0248. As I explained in my previous email, I don't think that this is breaking backwards compatibility. However, if Node Discovery is important, as you state (and I am certainly not arguing against that), then I think we need something extra. As I read section 5.2 of XEP-0060, Node Discovery functionality is not mandatory: it is a MUST *only *when the service implements a hierarchy of nodes. I don't think that we can have a hierarchy of nodes without Collection Nodes / XEP-0248, right? That means that it's not mandatory at all now. I think we should consider changing that. Summarizing, the desired changes: 1. Replace XEP-0248 Section 5.2 with much of the content that is now in XEP-0060 Section 5.2. 2. Reduce XEP-0060 Section 5.2 to an example that does not include hierarchy / Collection Nodes. 3. Add to XEP-0060 Section 5.2 that it must be possible to discover nodes (even if there's no hierarchy). I would like to add a MUST condition there, but given that this XEP is Stable, I don't know if we can. As this change adds a new requirement, it may cause pre-existing implementations to suddenly be no longer compliant. Is that "breaking backwards compatibility" as defined in XEP-0001? What do you think? Kind regards, Guus On Thu, Sep 4, 2025 at 6:18 PM Goffi <goffi(a)goffi.org> wrote:

Hi Goffi, We're in agreement, I think. I do prefer example 11 to be removed. Your argument of keeping it is based on it being used to discover _items_. That practice (discovering items) is not defined in section 5.2. Instead, that is in section 5.5. Section 5.5 already has an appropriate example). Kind regards, Guus On Thu, Sep 4, 2025 at 9:53 PM Goffi <goffi(a)goffi.org> wrote:

Hi again! I'll certainly make a PR, but I'm waiting for a while, to: - give others an opportunity to provide feedback - find out, while I continue working down the XEP, if there are other things that I'd like to address. One such 'other thing' is this: XEP-0060 in section 4.6 defines two forms of addressing: JID and JID+NodeID. It states the JID format SHOULD be used when using a protocol that does not support the node attribute. However, it does not explicitly prohibit the JID format from being used if the protocol _does_ support the node attribute, right? I believe that this leaves the door open to using the JID address format with Service Discovery. Unless I'm mistaken, this is then a valid equivalent of example 10: <iq type='result' from='pubsub.shakespeare.lit' to=&#39;francisco(a)denmark.lit/barracks&#39; id='nodes1'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='pubsub.shakespeare.lit/blogs' name='Weblog updates'/> <item jid='pubsub.shakespeare.lit/news' name='News and announcements'/> </query> </iq> This seems to be indistinguishable from a response that discovers items (rather than nodes) as specified in section 5.5. Using JID+NodeID in a protocol that supports the node attribute seems a silly thing to do to me, but I don't think it is forbidden by the XEP. Should we add a restriction (or at least a recommendation)? Kind regards, Guus On Fri, Sep 5, 2025 at 10:32 AM Goffi &lt;goffi(a)goffi.org&gt; wrote:

Hi all, As discussed, I have been preparing a PR with the changes discussed so far. That PR is now available, here: https://github.com/xsf/xeps/pull/1455 I have added a few more that have not explicitly been discussed in this mail thread yet: - To further reduce the complexity of XEP-0060, but also to improve the consistency of the separation between XEP-0060 and XEP-0248, most collection-specific references, such as related Registrar considerations) are migrated from XEP-0060 to XEP-0248. Many of these already exist in the latter, in which case the duplicate in the former should be removed. - Another desirable change is to have the specification of changes to the node type be centralized in one XEP. Currently, XEP-0060 describes changing a leaf to a collection, while XEP-0248 describes changing a collection to a leaf (but uses generic language that is easily interpreted as if node type changes are not allowable at all). By having both processes be specified in XEP-0248, there is a lot less room for ambiguity (while it also further reduces complexity in XEP-0060). - XEP-0060 should no longer reference to XEP-0248 for a 'process to retrieve the default subscription configuration options for collection nodes'. Such process is not explicitly defined in XEP-0248 (meaning that the process is equal to that in XEP-0060), meaning that the reference is more likely to cause confusion than clarity. Although additional configuration options (but not a new process) are provided in XEP-0248, it is perfectly reasonable for readers to expect that type-specific configuration is to be found in type-specific XEPs. - XEP-0060 defines a MUST for a collection nodes to support 'pubsub#notify_config' (support is a SHOULD for leaf nodes). Such a strict requirement for collection nodes should be defined in the XEP-0248 instead of in XEP-0060. I don't believe that these changes are contentious, but please correct me if you feel different. With all of these changes, I believe that the split off of 'collections' from the original specification is now improved. That serves my original purpose, which was to be able to write integration tests to cover XEP-0060 without having to deal with hierarchy / collection functionality. There is one remaining gripe that I have with the XEPs, which is the usage of a 'root' collection in XEP-0060, even though it's defined in XEP-0248. That doesn't sit quite right with me, but I'm not seeing easy ways to improve on that. Something something not calling the root a 'collection', and moving the corresponding definition back from XEP-0248 to XEP-0060, but that feels like stretching things. For now, at least for the purpose of this set of changes, I think I'll leave it as-is. Better, not perfect. I have somewhat cheekily already opened the PR even though not all changes have been discussed here. If you have concerns, please raise them on this mailinglist. I'll change the PR to draft if significant concerns are raised, to avoid wasting time of the processing entities. Kind regards, Guus On Fri, Sep 5, 2025 at 12:28 PM Goffi &lt;goffi(a)goffi.org&gt; wrote: