4 Sep
2025
4 Sep
'25
9:53 p.m.
Le jeudi 4 septembre 2025, 19:34:49 heure d’été d’Europe centrale Guus der
Kinderen a écrit :
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)?
Disco#items to the pubsub service without node specified (what is called the
"root" node there) is certainly the most important one, that is example 9 and
10.
Example 11 (with node specified) can be used to retrieve items of a node
(without getting the whole payload as with a normal pubsub get). I know that
at some point at least Movim was using it, I don't know if it's still the
case.
This is probably one that can be discussed (similar result can be achieved
with pubsub get, at the price of being far less efficient if we want only item
names), but as the XEP is stable, I think that this should stay.
I don't think that this is particularly difficult to implement, it's a very
similar request to a pubsub get.
Example 12 is definitely the one that can be moved to XEP-0248.
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 explained above, I think that only example 12 can be moved.
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.
We do have hierarchy with the new XEP-0496 (Pubsub Relationships) that I've
authored. But those use another optional mechanism to discover the hierarchy,
namely XEP-0499 (Pubsub Extended Discovery), so it's not a problem here.
Note that I think that XEP-0248 should be deprecated at some point: there are
very few implementations, it has issues that have been discussed during summit
and on standard@ and xsf@, and XEP-0496 and related XEP should cover all the
use cases.
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.
I think that a rewording and move of Ex. 12 is the way to go.
We would have 2 use case:
- request on pubsub service without node specified, to have list of nodes (in
flat case)
- request with node specified, to have names of items of the node.
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?
I would love to have a MUST here too. This can maybe be discussed with
council, but I suspect that it would be hard to change at this stage. I'm
curious to hear what others say on that.
Best,
Goffi