10 Sep
2025
10 Sep
'25
7: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