[Standards] XEP-0280: Message Carbons
Matthew A. Miller
linuxwolf at outer-planes.net
Mon Oct 31 15:50:41 UTC 2011
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:
>>>> 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?
>> 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.
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 § 220.127.116.11, 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2238 bytes
Desc: not available
More information about the Standards