On 1 Apr 2015, at 17:37, Dave Cridland <[email protected]> wrote: > > Folks, > > Matthew Miller and Joe Hildebrand's Carbons XEP has been unchanged for 18 > months, and represents a useful and well-deployed protocol, implemented in > most (if not all) of the mainstream servers. > > Mobile and Desktop clients alike appear to implement this widely. > > I appreciate that the last Summit raised suggestions that it needed to do > more, but it is not clear to me that the "more" cannot be phrased as a new > XEP, and moreover that breaking compatibility given the deployment status is > warranted. > > It is also not clear to me what, exactly, the "more" consists of. I have > heard: > > - Reflection of messages to the source. > - Addition of MAM identifiers. > - Other types beyond 'chat’.
I think these are about what was discussed at the Summit, yes. > Therefore I would like to suggest that this specification be advanced to > match its de-facto state of Draft. I think this is premature. Carbons, or something like it, is core to the multi-client case that we’re desperately close to having a coherent story for. We got pretty close to working this out at the Summit, and the almost unanimous verdict (I think I was the only opposing voice) was that Carbons needed changes for this so I think it’s worth leaving Carbons in its current Experimental state where we’re free to make changes if needed. It would be a crying shame for us to push Carbons to Draft, and be unable to make some change we need to sort out our multi-client story. I appreciate the argument that it’s widely deployed in its Experimental state, but there are several versions out there already that are supported, and adding another one (if it turns out that we need it, which is what seems to be the current consensus) wouldn’t change that. I think the need for us to solve the multi-client story such that clients can implement things as cleanly as the silos currently do is more important than the need for us to push Carbons to Draft at this point. /K
