XMPP and Jabber clients

There was a need to use one Jabber account for multiple users. After reading the RFC I stumbled upon the priorities for resources in XMPP. That's what I need! In practice, not everything turned out to be so rosy. In my opinion, many popular customers do not properly support the protocol.

The idea was that clients connect to the Jabber server from the same account but from different resources and with negative priority.
The behavior of the server in this case is described in the XMPP IM RFC :

11.1. Inbound Stanzas 1.4.1:
For message stanzas, the server SHOULD deliver the stanza to the highest-priority available resource (if the resource did not provide a value for the <priority/> element, the server SHOULD consider it to have provided a value of zero). If two or more available resources have the same priority, the server MAY use some other rule (eg, most recent connect time, most recent activity time, or highest availability as determined by some hierarchy of <show/> values) to choose between them or MAY deliver the message to all such resources. However, the server MUST NOT deliver the stanza to an available resource with a negative priority; if the only available resource has a negative priority, the server SHOULD handle the message as if there were no available resources (defined below). In addition, the server MUST NOT rewrite the 'to' attribute (ie, it MUST leave it as <user@domain> rather than change it to <user@domain/resource>).


That is, the message will be delivered to client@example.com/resource1 or to any other resource with the highest non-negative priority. So far everything was fine with me and only pleased.

Then in the same XMPP IM RFC I read about how Jabber clients with resources should behave:

4.1. Specifying an Intended Recipient
An instant messaging client SHOULD specify an intended recipient for a message by providing the JID of an entity other than the sender in the 'to' attribute of the <message/> stanza. If the message is being sent in reply to a message previously received from an address of the form <user@domain/resource> (eg, within the context of a chat session), the value of the 'to' address SHOULD be of the form <user@domain/resource> rather than of the form <user@domain> unless the sender has knowledge (via presence) that the intended recipient's resource is no longer available. If the message is being sent outside the context of any existing chat session or received message, the value of the 'to' address SHOULD be of the form <user@domain> rather than of the form <user@domain/resource>.

As I understand it, if the chat is not started by this client, then he should send a response to the full JID (with the resource) in all cases except when the chat initializer through presence reported that this resource is unavailable.
')
In practice, this is the case if both clients see each other. In the case of unauthorized clients, the behavior is somewhat different ... Let's look at communication through Miranda between unauthorized users:

I created a new user (client1@example.com) on my server and connected to it from Miranda:


After that, I sent this user (client1@example.com) 2 messages from client@example.com/resource1 and client@example.com/resource2 and was very surprised at their communication ...
This is how Miranda showed me these messages:

And after scanning their communication, I saw the following:

< message type = 'chat' from ='client@example.com/resource1 ' to ='client1@example.com' id = 'uid12' >
< body > message with resource1 </ body >
< thread > uid11 </ thread >
< x xmlns = 'jabber: x: event' >
< offline />
< delivered />
< displayed />
< composing />
</ x >
< active xmlns = 'http: //jabber.org/protocol/chatstates' />
</ message >

< message type = 'chat' from ='client@example.com/resource2 ' to ='client1@example.com' id = 'uid6' >
< body > message from resource2 </ body >
< thread > uid5 </ thread >
< x xmlns = 'jabber: x: event' >
< offline />
< delivered />
< displayed />
< composing />
</ x >
< active xmlns = 'http: //jabber.org/protocol/chatstates' />
</ message >

And Miranda sent the answer like this:

< message from ='client1@example.com/Miranda ' to ='client@example.com' xml: lang = 'en' type = 'chat' id = 'mir_12' >
< body > answer from miranda </ body >
</ message >

None of the clients sent a presence tag to Miranda, and they shouldn’t because they are not authorized and do not inform each other about their presence. From all this, I concluded that Miranda does not comply with the RFC. If I am somewhere that is not right please inform.

I also tested other clients:

• Miranda-im v0.7.8 - discards messages in one window and responds to JID without rusurs.
• Pidgin 2.4.3 - the message drops in one window and responds to the JID without Rusource.
• Gajim 0.11.4 - the message drops in one window and responds to the JID without Rusurs.
• mcabber 0.9.5-1 - the message throws off in one window and responds to JID without rusurs.
• Pandion 2.5 - the message drops in one window but responds to the Russes from which the last message was sent.
• Exodus 0.10.0.0 - opens a new window for a new resource but the message puts in the first open window :) after 10 messages it goes crazy :)
• psi 0.12 - Opens a new window for different resources. Answers full JID!

Since Psi is cross-platform, I can dwell on the use of this client, but I would like to figure out who actually is a bug?