5 Sep
2025
5 Sep
'25
12:28 p.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