On Jan 5, 2012, at 08:41, Mike Wacker wrote: > On 1/5/2012 7:31 AM, Matthew Miller wrote: >> 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> >> > Could you elaborate on those concerns? A client would only receive a message > that did not match the 'to' if it had message carbons enabled. Thus, it would > be reasonable that these clients would have special logic to handle such > messages if it supported carbons and if it had them enabled. Clients not > supporting message carbons do not need to make any changes.
The problem is not just with the clients; it's also with servers. The server must route that message, and not every server implementation is readily prepared to deal with that radical of a departure for standard XMPP routing rules. - m&m <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
