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 <[email protected]> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to