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='[email protected]/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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
