On Oct 29, 2011, at 14:14, Kim Alvefur wrote: > http://xmpp.org/extensions/xep-0280.html#inbound >> Messages of type chat that are addressed to the bare JID >> (localpart@domain) MUST be copied by the receiving server to all of >> the resources for that user that have non-negative presence priority >> and have not filtered messages through some other means. The process >> of making copies is known as "forking." > > This seems weird. What's the reason for mandating this specific behavior > instead of just referencing what XMPP-IM says? > > http://tools.ietf.org/html/rfc6121#section-8.5.2.1 >
We've decided on this behavior for carbons to prevent favoring one endpoint over another. It would allow for endpoints to determine if the conversation ought to be picked up by it or left to another. While presence priorities can help here, they leave a considerable focus gap. For example: 1) you <[email protected]/desktop> send me <[email protected]> a chat message 2) the chat message is received by your server <zash.se> and forwarded to <outer-planes.net> 3) the chat message is received by my server <outer-planes.net>, and is routed to my most-available resource <[email protected]/sylvania> (my desktop) 4) I walk away from "sylvania", sending a presence that lowers its priority below my other resource, "mimir" (my phone) If step #5 were "the chat message is sent to <[email protected]/sylvania>" and carbons meant that <[email protected]/mimir> got a copy, "mimir" may not alert me to your chat. Or it might alert me on every received carbon, making it very very disruptive. Instead if step #5 were "the chat message is sent to all available resource for <[email protected]>", then both "sylvania" and "mimir" can treat this as an initial message and alert me appropriately. There are still edges here, but I think this protocol helps eliminate at least one (big one). - m&m <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
