[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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 8/28/14, 3:03 AM, Philipp Hancke wrote:
> I want to use the "forking" of <message/> stanzas as described in
http://tools.ietf.org/html/rfc6121#section-8.5.2.1.1
> 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:
http://logs.xmpp.org/xsf/2014-08-28#08:29:58
>
> 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 >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJT/083AAoJEOz0ck4QngW7AvkH/3JcTbkqSWBT7sePPu/EqsKg
ab2f5nqMDpGFFtnbeBpbOdszHWBIJphuEO+DnAB2R/iDwaldJMdNOReG4sO0TAA3
lCik/s3LCZvg02hQVWDvZ20/p4XU/sHT+xsFTMlf5gsqF+dELC1//xqDIC2kSDUk
NXv8appHjEXyigVyNmnLyhyFy3IBIwNrZMZLXwShuNDgCAsMWnWEyCL/mGdszP1B
U2HaMyk0PAVvHdFJqsacvrmql9oPGVpv543LoYUG8kmY4p0y6R9U9kzFLzl9AA8q
NG977Eh9Mx3Kn2tyl4pgJDEQmchuBSvp/No0q5z3n/qxuhxvV4Bou4+Va3+3r6M=
=+CjN
-----END PGP SIGNATURE-----





More information about the Standards mailing list