4 Sep
2025
4 Sep
'25
1:52 p.m.
Hello!
Section 5.2 of XEP-0060 'Publish-Subscribe' describes how disco#items is
used to discover nodes. Most of that section describes node discovery in
node hierarchies and collection nodes.
In version 1.12 of XEP-0060 text about collections was moved to XEP-0248
'PubSub Collection Nodes'. This specification contains a smaller paragraph
on node discovery (which is also numbered 5.2).
I would like to see the complexity of XEP-0060 be reduced. I believe that
most, if not all of its section 5.2 should be moved to XEP-0248 and removed
from XEP-0060.
The suggested change should not affect backwards compatibility, as it
doesn't result in a change of behavior: as far as I can see, the text only
applies to hierarchies and collection nodes. The change therefore is
permissible even considering XEP-0060 is Stable.
Is there any objection to this? What would relevant Node Discovery content
for XEP-0060 be (other than a reference to XEP-0248)?
Kind regards,
Guus
4 Sep
4 Sep
4:17 p.m.
Le jeudi 4 septembre 2025, 15:52:25 heure d’été d’Europe centrale Guus der
Kinderen a écrit :
Hello!
Section 5.2 of XEP-0060 'Publish-Subscribe' describes how disco#items is
used to discover nodes. Most of that section describes node discovery in
node hierarchies and collection nodes.
In version 1.12 of XEP-0060 text about collections was moved to XEP-0248
'PubSub Collection Nodes'. This specification contains a smaller paragraph
on node discovery (which is also numbered 5.2).
I would like to see the complexity of XEP-0060 be reduced. I believe that
most, if not all of its section 5.2 should be moved to XEP-0248 and removed
from XEP-0060.
The suggested change should not affect backwards compatibility, as it
doesn't result in a change of behavior: as far as I can see, the text only
applies to hierarchies and collection nodes. The change therefore is
permissible even considering XEP-0060 is Stable.
Is there any objection to this? What would relevant Node Discovery content
for XEP-0060 be (other than a reference to XEP-0248)?
Kind regards,
Guus
Hi Guus,
While I agree that the reference to collections, root and leaf nodes should be
removed or moved away, node discovery is certainly useful in general use-case
and should be part of XEP-0060 IMO.
The mechanism itself is a usual disco#items query, the section mostly explain
how to interpret the result, so it doesn't really complexify the protocol.
Discovering nodes is useful (and used) to discovers things such as blogs,
XEP-0346 forms and other pubsub-based features.
Best,
Goffi
5:34 p.m.
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:
Le jeudi 4 septembre 2025, 15:52:25 heure d’été
d’Europe centrale Guus der
Kinderen a écrit :
Hello!
Section 5.2 of XEP-0060 'Publish-Subscribe' describes how disco#items is
used to discover nodes. Most of that section describes node discovery in
node hierarchies and collection nodes.
In version 1.12 of XEP-0060 text about collections was moved to XEP-0248
'PubSub Collection Nodes'. This specification contains a smaller
paragraph
on node discovery (which is also numbered 5.2).
I would like to see the complexity of XEP-0060 be reduced. I believe that
most, if not all of its section 5.2 should be moved to XEP-0248 and
removed
from XEP-0060.
The suggested change should not affect backwards compatibility, as it
doesn't result in a change of behavior: as far as I can see, the text
only
applies to hierarchies and collection nodes. The
change therefore is
permissible even considering XEP-0060 is Stable.
Is there any objection to this? What would relevant Node Discovery
content
for XEP-0060 be (other than a reference to
XEP-0248)?
Kind regards,
Guus
Hi Guus,
While I agree that the reference to collections, root and leaf nodes
should be
removed or moved away, node discovery is certainly useful in general
use-case
and should be part of XEP-0060 IMO.
The mechanism itself is a usual disco#items query, the section mostly
explain
how to interpret the result, so it doesn't really complexify the protocol.
Discovering nodes is useful (and used) to discovers things such as blogs,
XEP-0346 forms and other pubsub-based features.
Best,
Goffi_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
7: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
5 Sep
5 Sep
8: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
8:31 a.m.
Hi Guus,
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).
You're right, items discovery is only mentioned at the end of §5.2, and §5.5
describes it. So example 11 can be removed too.
Regarding hierarchy, XEP-0496 and XEP-0499 are explicitly backward compatible,
meaning that all nodes are returned if extended discovery is not used. So we
can remove the notion of "first-level nodes" from the description of example 10
(except if we want to keep it due to XEP-0248).
Will you make a PR for those changes? For a stable XEP it will have to go
through council, and authors input would be good to have too.
Best,
Goffi
9 a.m.
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='francisco(a)denmark.lit/barracks'
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 <goffi(a)goffi.org> wrote:
Hi Guus,
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).
You're right, items discovery is only mentioned at the end of §5.2, and
§5.5
describes it. So example 11 can be removed too.
Regarding hierarchy, XEP-0496 and XEP-0499 are explicitly backward
compatible,
meaning that all nodes are returned if extended discovery is not used. So
we
can remove the notion of "first-level nodes" from the description of
example 10
(except if we want to keep it due to XEP-0248).
Will you make a PR for those changes? For a stable XEP it will have to go
through council, and authors input would be good to have too.
Best,
Goffi_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
10:28 a.m.
Hi again Guus,
Le vendredi 5 septembre 2025, 11:00:48 heure d’été d’Europe centrale Guus der
Kinderen a écrit :
[SNIP]
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?
As I'm always working with node attribute, I was not even aware that using the
resource for node ID was possible! I wonder which implementation do support
that.
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='francisco(a)denmark.lit/barracks'
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.
If that were indeed possible, I guess that using the resource for node in the
answer, would here be equivalent to have the "node" attribute. But this is for
sure a great source of confusion and bugs.
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)?
I agree that this could be explicitly stated. Actually, I would be really
happy to get completely rid of using the resource for the node ID as stated in
§4.6.1, we have already enough troubles by using resources for MUCs, no need
to do the same with Pubsub.
I wonder if this is used by anybody in the wild.
Thank you for catching that and your effort on improving pubsub Guus.
Best,
Gofffi
10 Sep
10 Sep
5:21 p.m.
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 <goffi(a)goffi.org> wrote:
Hi again Guus,
Le vendredi 5 septembre 2025, 11:00:48 heure d’été d’Europe centrale Guus
der
Kinderen a écrit :
[SNIP]
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?
As I'm always working with node attribute, I was not even aware that using
the
resource for node ID was possible! I wonder which implementation do
support
that.
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='francisco(a)denmark.lit/barracks'
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.
If that were indeed possible, I guess that using the resource for node in
the
answer, would here be equivalent to have the "node" attribute. But this is
for
sure a great source of confusion and bugs.
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)?
I agree that this could be explicitly stated. Actually, I would be really
happy to get completely rid of using the resource for the node ID as
stated in
§4.6.1, we have already enough troubles by using resources for MUCs, no
need
to do the same with Pubsub.
I wonder if this is used by anybody in the wild.
Thank you for catching that and your effort on improving pubsub Guus.
Best,
Gofffi_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
30 Sep
30 Sep
6:54 p.m.
Hi Guus,
I'm writing to give explanation of my today vote at Council.
I've voted -1 to block the submission because we were at the end of the 2
weeks time-frame, and the PR would be automatically accepted otherwise. The
veto was just to block the current one for a re-submission with the requested
change.
So to be clear, I'm all in favor of this PR and thankful to your work, I'm
just blocking it as discussed on the ticket itself because I'm worrying that
the PR wording is changing the meaning of XEP-0060 regarding node discovery
with disco#items.
I'm repeating here for archive (and possibly discussion):
XEP-0060 originally says:
If a service implements a hierarchy of nodes (by means
of <link
url='#collections'>Collection Nodes</link>), it MUST also enable
entities
to discover the nodes in that hierarchy by means of the <strong>Service
Discovery</strong> protocol
The "MUST" here is only "If a service implements a hierarchy of
nodes".
Your PR in its current state changes it for:
A service MUST enable entities to discover the nodes
by means of the
<strong>Service Discovery</strong> protocol, subject to the
recommendations in &xep0030; regarding large result sets (for which
&xep0055; or some other protocol SHOULD be used).
There is no longer a requirement for a service implementing a hierarchy of
nodes, so there's an unconditional "MUST" here.
That changes the specification and may make existing implementations invalid,
which shouldn't happen with a stable XEP.
Therefore, the PR should use "SHOULD" instead of "MUST" here, and it
would
also be beneficial to add text explicitly stating that different entities may
have different nodes listed, and the list may even be empty for some entities.
This is important socially because people may want to hide some nodes (e.g., a
private or invite-only blog).
It's also important technically because it must be clear that the list of
nodes cannot be cached globally (at least without further negotiation), and is
valid only per entity.
The council discussed that a "MUST" with explanation could be acceptable, but
after further consideration, and given that the original state had no "MUST"
for non-hierarchical nodes, I really think a "SHOULD" is needed here.
I hope my explanation is clear. Please update this small detail; I'll
definitely be +1 on the next round.
Best,
Goffi
1 Oct
1 Oct
7:17 a.m.
Hi Goffi,
Thanks for the feedback. We already were in general agreement that this
change was needed, I think, but were waiting for other Council members to
weigh in.
I have now applied the requested changes in
https://github.com/xsf/xeps/pull/1455/commits/f048f8ef08a129f1a2e5a5efd1635…
Kind regards,
Guus
On Tue, Sep 30, 2025 at 8:54 PM Goffi <goffi(a)goffi.org> wrote:
Hi Guus,
I'm writing to give explanation of my today vote at Council.
I've voted -1 to block the submission because we were at the end of the 2
weeks time-frame, and the PR would be automatically accepted otherwise.
The
veto was just to block the current one for a re-submission with the
requested
change.
So to be clear, I'm all in favor of this PR and thankful to your work, I'm
just blocking it as discussed on the ticket itself because I'm worrying
that
the PR wording is changing the meaning of XEP-0060 regarding node
discovery
with disco#items.
I'm repeating here for archive (and possibly discussion):
XEP-0060 originally says:
If a service implements a hierarchy of nodes (by
means of <link
url='#collections'>Collection Nodes</link>), it MUST also enable
entities
to discover the nodes in that hierarchy by means of the <strong>Service
Discovery</strong> protocol
The "MUST" here is only "If a service implements a hierarchy of
nodes".
Your PR in its current state changes it for:
A service MUST enable entities to discover the
nodes by means of the
<strong>Service Discovery</strong> protocol, subject to the
recommendations in &xep0030; regarding large result sets (for which
&xep0055; or some other protocol SHOULD be used).
There is no longer a requirement for a service implementing a hierarchy of
nodes, so there's an unconditional "MUST" here.
That changes the specification and may make existing implementations
invalid,
which shouldn't happen with a stable XEP.
Therefore, the PR should use "SHOULD" instead of "MUST" here, and it
would
also be beneficial to add text explicitly stating that different entities
may
have different nodes listed, and the list may even be empty for some
entities.
This is important socially because people may want to hide some nodes
(e.g., a
private or invite-only blog).
It's also important technically because it must be clear that the list of
nodes cannot be cached globally (at least without further negotiation),
and is
valid only per entity.
The council discussed that a "MUST" with explanation could be acceptable,
but
after further consideration, and given that the original state had no
"MUST"
for non-hierarchical nodes, I really think a "SHOULD" is needed here.
I hope my explanation is clear. Please update this small detail; I'll
definitely be +1 on the next round.
Best,
Goffi_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
10:59 a.m.
Le mercredi 1 octobre 2025, 09:17:42 heure d’été d’Europe centrale Guus der Kinderen a
écrit :
Hi Goffi,
Thanks for the feedback. We already were in general agreement that this
change was needed, I think, but were waiting for other Council members to
weigh in.
I have now applied the requested changes in
https://github.com/xsf/xeps/pull/1455/commits/f048f8ef08a129f1a2e5a5efd1635…
Kind regards,
Guus
Hi Guus,
thanks! It's fine by me now.
Best,
Goffi
93
days inactive
120
days old
11 comments
2 participants
participants (2)
-
Goffi -
Guus der Kinderen