On Jan 5, 2012, at 09:03, Mike Wacker wrote: > On 1/5/2012 7:43 AM, Matthew Miller wrote: >> 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> >> > Perhaps an actual case could help elaborate, in theory, all you need to do is > alter the routing logic and perhaps also alter some checks/assertions for > messages which don't match the 'to' field. Neither seems prohibitively > expensive. It doesn't seem that complex on the client either. > > I'm just looking for a better rationale for it. If there's a client use case > or user experience which requires the wrapping, then we definitely need it. > If it's a task that can be offloaded from the server to the client, that is > also a valid reason. But I'm not a huge fan of altering the message just to > simplify server implementation details for a task that belongs to the server > [routing]. > > Unless there's a really compelling cost or scalability reason, I prefer that > we build the protocol around client use cases and user experiences instead of > building it around the server implementation.
I appreciate your feedback, but completely disagree with your assessment. I know there are others that disagree, because I made the change based on their feedback on this list. - m&m <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
