[Standards] UPDATED: XEP-0280 (Message Carbons)

Kevin Smith kevin at kismith.co.uk
Mon Jul 11 14:22:53 UTC 2011

On Mon, Jul 11, 2011 at 3:18 PM, Matthew A. Miller
<linuxwolf at outer-planes.net> wrote:
> On Jul 11, 2011, at 04:15 , Kevin Smith wrote:
>> On Sun, Jul 10, 2011 at 9:15 PM, XMPP Extensions Editor <editor at xmpp.org> wrote:
>>> Version 0.2 of XEP-0280 (Message Carbons) has been released.
>>> Abstract: In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources.
>>> Changelog: Changed enabling and disabling to use separate elements rather than attributes; ensured all elements in the examples have their namespaces more explicitly defined; used message forwarding for carbon copies. (mm)
>>> Diff: http://xmpp.org/extensions/diff/api/xep/0280/diff/0.1/vs/0.2
>>> URL: http://xmpp.org/extensions/xep-0280.html
>> I think:
>> "The wrapping message SHOULD maintain the same 'type', 'from', and
>> 'id' attribute values (if any), while the 'to' attribute SHOULD be the
>> full JID of the resource receiving the copy."
>> isn't right. The encapsulated message already has these data available
>> - the encapsulating message should have attributes that reflect who is
>> really sending/receiving the stanza (i.e. to=the client receiving the
>> carbon, from=the server or the bare JID, unique id).
> I don't quite agree with you; I think there should be some corroborating information between the wrapped and wrapping message, especially with one of the addresses ('from' seems the least routing-intesive here).  The id can be relaxed, although I think keeping the type is worthwhile ("normal" and "headline" don't seem right here).
> I may be paranoia on my part, but I don't want to implicitly trust any <forwarded/> that I get.  Granted, nothing is guaranteed here without digitally signing, but correlating at least one address seems better than nothing at all.

I don't see any possible attack that checking they match would abate.
On the other hand, I do see why knowing which entity is performing the
carbonating is safer. Can you provide an example of something that's
better with faking the from than stamping it with the server/bare JID
(which I think are equivalent for the purposes of this and we can
safely pick either)?


More information about the Standards mailing list