On Jan 5, 2012, at 08:24, Mike Wacker wrote:
> Let me suggest a bolder idea. Why do we need to wrap the carbons using > Message Forwarding at all instead of just delivering the message stanzas as > is? You will only receive these additional message carbons if your client > supports carbons and enables carbons. Thus, if a client has carbons enabled, > if it receives a message not sent to its bare JID or full JID (either a > message from one of its other resources to a buddy or from a buddy to one of > its other resources), it can reasonably infer that the message is a carbon. > > The standard use cases for message carbons is to ensure that a given device > will receive both sides of all conversations, and that use case is covered > regardless of whether we wrap carbons or not. I can't think of any use case > for the special wrapping logic, though. > > This would greatly simplify the XEP (as well as eliminate a dependency on an > experimental XEP more complex than message carbons itself), as servers would > only have to route the messages and not modify them, and clients won't need > special parsing logic for carbons. > The original version of XEP-0280 did just that. However, while it appears to simplify the XEP, it complicated implementations. It required routing a <message/> to a client that did not match the 'to', which raised a number of concerns among client and server implementers. And I disagree that XEP-0297 is more complex than carbons. - m&m <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
