On Jul 11, 2011, at 04:15 , Kevin Smith wrote: > On Sun, Jul 10, 2011 at 9:15 PM, XMPP Extensions Editor <[email protected]> > 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.
- m&m
smime.p7s
Description: S/MIME cryptographic signature
