[Standards] XEP-0280: carbons + <message/> stanzas of type normal

Matthew A. Miller linuxwolf at outer-planes.net
Thu Aug 28 15:48:08 UTC 2014

Hash: SHA512

On 8/28/14, 3:03 AM, Philipp Hancke wrote:
> I want to use the "forking" of <message/> stanzas as described in
> in order to "fork" Jingle calls in a way that allows the receiver to
pick the device which accepts the call.
> In order to use this forking, my resource needs to have a non-negative
though, which means it would also receive messages of type=chat. Since I
want to use this for clients that don't provide a chat interface I do
not want to receive chats if possible.
> Matthew Wild pointed out to me that carbons works around the RFC here:
> That way, I can keep a negative priority (which hopefully doesn't show
the client as something-you-can-chat-with in other clients)
> However, http://xmpp.org/extensions/xep-0280.html#inbound-bare only
talks about messages of type chat.
> 1) can we change 0280 to also allow this type of processing for
messages of type normal? prosodys mod_carbons seems to do this anyway.
I think that's reasonable, but I would still argue against any other
<message/> types.

> 2) is there a chance of extending carbons in a way such that a resource might selectively
enable carbons just for normal messages? E.g. by including children in
the <enable/> element that specify the desired types?
I am hesitant to add more than a simple on/off switch here.  You could
pretty easily ignore <message type='chat'/>, but I am cognizant that
traffic is still delivered; for a mobile device, that often means
powering up the second most power-hungry component just to receive
something unwanted.

My initial thought is turning off "chat" seems like a more global thing
to do, instead of spreading the logic around in a "bunch" of other
protocols.  It seems like this fits better in [SIFT] -- it doesn't
today, but maybe it ought to.

- -- 
- - m&m

Matthew A. Miller
< http://goo.gl/LK55L >
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org


More information about the Standards mailing list