XEP-0402: do not return an empty <nick /> if the nicname wasn't set when joined a conference

[stokito]

Environment

• ejabberd version: 24.07

Bug description

When opening a conference bookmark the ejaberd returns an empty <nick /> element if the nickname wasn't set before. This causes errors in the clients.

<iq xmlns="jabber:client" xml:lang="en" to="stokito@conversations.im/gajim.K4OZSDIV" from="stokito@conversations.im" type="result" id="adc7083e-b00a-45b8-98cd-bf31a8bfb2c3">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <items node="urn:xmpp:bookmarks:1">
      <item id="ru@chat.404.city">
        <conference xmlns="urn:xmpp:bookmarks:1" name="RuChat:  Чат русско-язычного XMPP" autojoin="false">
          <nick />
          <extensions />
</conference>

So here I joined a conference ru@chat.404.city from my account stokito@conversations.im from Gajim. It looks like I didn't specified my nickname and on the server it was set to empty.

The XEP-0402 says that the whole nick element is optional. This is an issue of the XEP that didn't clearly specified this and the XMPP server that mustn't return the empty nick element.
The both 404.city and conversations.im use latest ejaberd.

[badlop]

You used a client that implements XEP-0402 to store the room bookmark in the Pubsub service. The clients sends a stanza to the pubsub service, and the client later queries the pubsub service to retrieve it.

The Pubsub server, or the XMPP server, does not care what specific XEP the client may be using. In this case it's XEP-0402, but it could be any other one, even a custom protocol that you designed and developed for your specific needs. The Pubsub service only cares about the Pubsub syntax.

This is an issue of the XEP that didn't clearly specified this

Right, the XEP inadvertedly allowed a potential ambiguity, it seems Conversations and Gajim implemented in different ways, and Gajim is not compatible with Conversations one... (setting empty nick to mean no nickname preference)

and the XMPP server that mustn't return the empty nick element.

The Pubsub service just cares to implement Pubsub. And the XMPP server does not interfere with whatever the clients may want to use the Pubsub service. For that reason, ejabberd didn't reject Conversations when it stored the pubsub item: nowhere in ejabberd core or in mod_pubsub it is implemented a stanza verification against XEP-0402.

If you install an external Pubsub service and connect it to ejabberd instead of mod_pubsub, then what software did you thought should implement that "XEP-0402 client stanza verification"? ejabberd core, or the external Pubsub service?

PD: mod_private implements backward compatibility between XEP-0048 and XEP-0402, but I think that's unrelated to this case. Conversations is a recent client, and probably it implements only XEP-0402, and mod_private is unrelated here.

[stokito]

Thank you, then this is not an issue of the server but of client. The spec ideally also shoudl be clear on this. I closing the issue, thank you