Re: [Standards] XEP-0280: Message Carbons

[Matthew A. Miller]

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  send me  a chat 
>> message
>> 2) the chat message is received by your server  and forwarded to 
>> 
>> 3) the chat message is received by my server , and is 
>> routed to my most-available resource  
>> (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 
>> " and carbons meant that 
>>  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 ", 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




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] XEP-0280: Message Carbons

[Kim Alvefur]

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  send me  a chat 
> message
> 2) the chat message is received by your server  and forwarded to 
> 
> 3) the chat message is received by my server , and is 
> routed to my most-available resource  
> (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 
> " and carbons meant that 
>  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 ", 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 

Re: [Standards] XEP-0280: Message Carbons

[Matthew A. Miller]

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  send me  a chat 
message
2) the chat message is received by your server  and forwarded to 

3) the chat message is received by my server , and is routed 
to my most-available resource  (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 
" and carbons meant that 
 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 
", 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




smime.p7s
Description: S/MIME cryptographic signature

[Standards] XEP-0280: Message Carbons

[Kim Alvefur]

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

-- 
Kim Alvefur