On Oct 31, 2011, at 09:43, Kim Alvefur wrote: > On Mon, 2011-10-31 at 08:58 -0600, Matthew A. Miller wrote: >> 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. > > I think it would be reasonable to say, do what XMPP-IM says, but also > send to any carbon enabled clients. Possibly recommending sending to > all available resources, I think that MUST is too harsh. > > My implementation currently sends carbons to anyone who has enabled > carbons that wouldn't already receive the message. So if your phone had > enabled carbons, it would have gotten the entire conversation regardless > of how available the server thinks it is. >
Ah, ok. This is something I thought I had changed to be as you describe; MUST send to all carbons-enabled resources, SHOULD otherwise follow RFC 6121 ยง 8.5.2.1, MAY send to others as the implementation deems appropriate. I'm currently working on an update to talk about "carbons vs. filtering", but I'll add this change to my set. - m&m <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
