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.
