[Standards] groupchat and error message routing

Waqas Hussain waqas20 at gmail.com
Thu Feb 12 14:22:38 UTC 2009


On Thu, Feb 12, 2009 at 3:57 PM, Dave Cridland <dave at cridland.net> wrote:
> On Wed Feb 11 18:27:03 2009, Jiří Zárevúcký wrote:
>>
>> I'm not entirely sure, but I think that nobody is ever supposed to
>> send an error message to a bare JID.
>
> Not true - PEP nodes send from a bare jid, if these bounce they end up back
> at a connected resource, much to the client's bewilderment, especially if
> the server is reusing the client's id for publishing.
>
> However, Waqas is saying that errors sent to non-existent resources are also
> sent to any conveniently connected client, too.
>
>>  Errors are sent in a response to
>> an invalid stanza, which always originates from a resource. As for the
>> "groupchat", I would suggest taking a look at the relevant XEP.
>>
>>
> The "relevant XEP" is RFC 3921.
>
> FWIW, I think groupchat to non-existent resources or bare jids should be
> bounced, and errors to bare jids MAY be handled by the server, and MUST NOT
> be sent to any resource except the original addressee.

That's exactly what I had in mind. And note that that's similar to how
offline storage works when there are no resources.

As for the current behavior, I can't think of any cases where it would
actually be useful. And it can cause problems: If we have two
resources (same bare JID) in the same MUC room, and one disconnects
just as the MUC server is sending a groupchat message. The second
would receive and display duplicate messages. If the unavailable
presence of the first one to the MUC server is lost, the second would
continue to display duplicate messages, for as long as the first one
isn't kicked by a presence error.

>
> Dave.
> --
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>

--
Waqas Hussain



More information about the Standards mailing list