5 Sep
2025
5 Sep
'25
10:04 a.m.
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:
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_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org