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:
- Replace XEP-0248 Section 5.2 with much of the content that is now in XEP-0060 Section 5.2.
- Reduce XEP-0060 Section 5.2 to an example that does not include hierarchy / Collection Nodes.
- 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