[Standards] Comment to rfc3921 pt 11.1 : handling of messages to ressources with identical priorities

Peter Saint-Andre stpeter at stpeter.im
Mon Aug 27 17:22:56 UTC 2007

Tomasz Sterna wrote:
> Dnia 27-08-2007, Pn o godzinie 10:03 -0600, Peter Saint-Andre
> napisał(a):
>>> Sally: Help.  [multicasted to all 3]
>> <message from='sally at example.org/foo'
>>          to='contact at example.com'
>>          type='chat'>
>>   <body>Help.</body>
>> </message>
>> NOTE: This is directed to the bare JID because Sally doesn't have any
>> context about which resource will reply. In this case, yes it is
>> encouraged to send to the bare JID, not the full JID. And yes, the
>> message is multicasted to all 3 of the contact team's resources.
>>> Joe: Please describe your problem.  [to Sally]
>> <message from='contact at example.com/joe'
>>          to='sally at example.org/foo'
>>          type='chat'>
>>   <body>Please describe your problem.</body>
>> </message>
>> NOTE: Joe sends from his full JID (stamped by his server) to Sally's
>> full JID (previously stamped by Sally's server). Now they are in a "chat
>> session" and will send to/from full JIDs the whole time. So this message
>> is NOT multicasted to all 3 of Sally's resources -- it is delivered ONLY
>> to her "foo" resource.
> IIRC exactly _this_ chatwindow to resource binding was discouraged.
> Could clients developers take voice here? I do remember snoring, that
> they would need to ditch the resource to window binding code.

It is recommended to send the first message to the bare JID, then after
you receive a reply from a full JID to send to that full JID. What that
means for chat *windows* is an implementation detail.

See also:


But you're a server developer so you don't have to worry about all that.

>>> Sally: I cannot do XXX.  [multicasted to all 3]
>> <message from='sally at example.org/foo'
>>          to='contact at example.com/joe'
>>          type='chat'>
>>   <body>I cannot do XXX.</body>
>> </message>
>> NOTE: This is NOT multicasted to all 3 of the contact team's resources,
>> instead it is delivered ONLY to Joe (the "joe" resource).

However, on the model you describe, the initial message would in fact be
sent to all three resources, so the following is possible:

>>> Jeff: Hi Sally. Please describe your problem.  [to Sally]
> And this? OK. It comes from /jeff resource. But shows where?

Sorry, I missed the names.

So yes, Jeff could reply to the initial message and he wouldn't know
that Joe already replied. The result is confusion.

Therefore, I would encourage people to use XEP-0142 (smarter handling on
the receiver side) or XEP-0155 for this kind of functionality.
Overloading account at domain.tld with extra meaning and having that
account controlled by multiple entities introduces the possibility for

> In the window labeled "contact at example.com" (or any petname Sally had
> given to this rosteritem) opened for Joe? These will be mixed with /joe
> messages?

No, IMHO that would probably be a separate window -- they are two
different chats. See XEP-0201 for more.

> In a separate window? How should it be named? Two windows of
> "contact at example.com"?

Probably. See above on the strong possibility for confusion here.

> And if so, this would break functionality for normal users changing
> resources. Every time I would switch /work to /mobile, the conversation
> that is going with me to /mobile would appear in a separate window at my
> contacts PC. Not nice.

There is no "chat handover" protocol. Usually this is handled socially
right now ("switching to my mobile, will chat with you from there").


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070827/b4c5b4a7/attachment.bin>

More information about the Standards mailing list