[Standards] XEP-0280: Message Carbons
zash at zash.se
Mon Oct 31 15:43:11 UTC 2011
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 at 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-126.96.36.199
> 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 <zash at zash.se/desktop> send me <linuxwolf at outer-planes.net> 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 <linuxwolf at outer-planes.net/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 <linuxwolf at outer-planes.net/sylvania>" and carbons meant that <linuxwolf at outer-planes.net/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 <linuxwolf at outer-planes.net>", 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.
> There are still edges here, but I think this protocol helps eliminate at least one (big one).
Kim Alvefur <zash at zash.se>
More information about the Standards