Subject: [xmpp] stanzas to full JID when there is no matching connected resource

From: Philipp Hancke <[email-masked]>
Date: Tue, 08 Jun 2010 16:15:43 +0200

In 10.2.3.3 there is the claim that:
If the JID contained in the 'to' attribute is of the form 
<localpart@domain/resource> and there is no connected resource that 
exactly matches the full JID, the stanza is processed as if the JID were 
of the form <localpart@domain>.

For message stanzas, this would usually mean that they are stored in 
offline storage. But in that case I expect them to be stored with the 
full JID and only to be delivered a connecting client that requests the 
resource "resource". This might be a problem if the resource identifier 
is not a constant string. Is the message ever get delivered?

A similar argument applies to iq stanzas. If I send a jabber:iq:version 
to localpart@domain/resource, I expect a reply from the client. If the 
request is processed as if it was directed to localpart@domain, the 
server might return the server version or the c2s implementation 
version. This might break entity capabilities, too.

This might break MUC, too. Suppose a user is no longer available at 
/resource (and the unavailable to the MUC room was lost for some 
reason). Now the MUC room is sending the join notification for another 
user. The proposed behaviour would have the stanza silently discarded, 
the current behaviour is to send an error, which in turn tells the MUC 
room that the user is a zombie and should be removed.

The old behaviour - returning <service-unavailable/> seems more 
appropriate - at least to me.

philipp

---

From: Matthew Wild <[email-masked]>
Date: Tue, 8 Jun 2010 15:42:30 +0100

> In 10.2.3.3 there is the claim that:

Congratulations, we're on the same section :)

> <localpart@domain/resource> and there is no connected resource that exactly
> matches the full JID, the stanza is processed as if the JID were of the form
> <localpart@domain>.
>

I think this is correct.

> For message stanzas, this would usually mean that they are stored in offline
> storage. But in that case I expect them to be stored with the full JID and
> only to be delivered a connecting client that requests the resource
> "resource". This might be a problem if the resource identifier is not a
> constant string. Is the message ever get delivered?
>

I don't think they should be stored with a full JID. It says handle
them as if they have a bare JID. I'd say that includes saving them
with a bare JID :)

> A similar argument applies to iq stanzas. If I send a jabber:iq:version to
> localpart@domain/resource, I expect a reply from the client. If the request
> is processed as if it was directed to localpart@domain, the server might
> return the server version or the c2s implementation version. This might
> break entity capabilities, too.
>

This rule should almost certainly only apply to <message> stanzas. In
fact it does, according to 3921bis:
http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-06#section-8.2.2

> /resource (and the unavailable to the MUC room was lost for some reason).
> Now the MUC room is sending the join notification for another user. The
> proposed behaviour would have the stanza silently discarded, the current
> behaviour is to send an error, which in turn tells the MUC room that the
> user is a zombie and should be removed.
>

3921bis also accounts for this (in fact 3921 didn't special-case
groupchat, and so they were to be routed to the bare JID, causing ugly
duplicated messages in groupchats...).

> The old behaviour - returning <service-unavailable/> seems more appropriate
> - at least to me.

In 3920bis it seems this would make sense, it looks like it currently
has too much logic that should be left to 3921bis.

Matthew

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 08 Jun 2010 18:12:36 +0200

mattj wrote:
> On 8 June 2010 15:15, Philipp Hancke<[email-masked]>  wrote:

3921bis tells you not to modify 'to', but we can discuss that during the 
3921bis WGLC (-:

> This rule should almost certainly only apply to<message>  stanzas. In

Well, it seems that what I considered 'current behaviour' was not 3921 
behaviour.
Anyway: the _presence_ stanzas sent by the MUC room to the (departed) 
full jid should be bounced to improve ghost detection, but that is  a 
detail for 3921bis and not relevant now.

>> The old behaviour - returning<service-unavailable/>  seems more appropriate
>> - at least to me.
>

Indeed.

philipp