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/f048f8ef08a129f1a2e5a5efd16350d4c13cac03

Kind regards,

  Guus

On Tue, Sep 30, 2025 at 8:54 PM Goffi <goffi@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@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org