[Standards] Proposed XMPP Extension: Message Carbons

Tory Patnoe tpatnoe at cisco.com
Mon May 3 23:42:11 UTC 2010

On 05/03/2010 04:37 PM, Joe Hildebrand wrote:
> 2) On your forked inbound messages, where another resource is processing
> this thread.  For this one, we also have enough information as long as the
> sending client is doing resource locking.  When the to address is a full JID
> where the resource is different from this one, the client doesn't beep.  If
> the sending client is always sending to the bare JID, then we either have to
> rely on mining or typing indicators for a hint that another resource is the
> primary target.


My point on this one was the "timed approach". If the contact's client is
just sending to the bare-jid, and your phone sees that you are responding
from another resource, start a timer and reset whenever your other
resource responds. If another message arrives from the contact's contact
within that time, don't beep.


More information about the Standards mailing list