On 12 Aug 2015, at 16:31, Kevin Smith <[email protected]> wrote: > > On 12 Aug 2015, at 16:14, Ralph Meijer <[email protected]> wrote: >> >> On August 12, 2015 4:50:18 PM GMT+02:00, Kevin Smith <[email protected]> >> wrote: >>> On 12 Aug 2015, at 15:44, Ralph Meijer <[email protected]> wrote: >>>> >>>> On August 12, 2015 3:07:44 PM GMT+02:00, Kevin Smith >>> <[email protected]> wrote: >>>>> The thread is moving somewhat away from Carbons Last Calls, but this >>> is >>>>> all related so I won’t feel too guilty. I have two opinions here: >>>>> [..] >>>>> 2) Carbons will need some changes in the (hopefully near) future >>> once >>>>> the pubsub/account stuff is specced/we have deployment experience. I >>>>> believe this means that going to Draft now wouldn’t be appropriate, >>> as >>>>> knowing there will be backwards-incompatible changes is at odds with >>>>> the Draft requirement of avoiding such things where possible. >>>> >>>> * Does this mean you'd vote -1 if Carbons remains mostly as-is for >>> now? >>> >>> For Draft, yes, which is very different to saying I think it has no >>> merit, or that I don’t think an appropriate version should go to Draft. >>> Voting something to Draft when I think it’s likely to need further >>> changes seems inconsistent with xep1. >>> >>>> * How do you feel such backwards incompatible changes would work out >>> in practice? I do feel implementors take a risk in putting experimental >>> specs in production, but also see the high-profile nature of this work >>> and the bigger context with other IM systems. >>> >>> I think they’d work out as a new namespace, but I’m not sure. If we >>> could get the other pieces in place we’d be able to see the bigger >>> picture and be more confident in these things. I think that MUC2 is not >>> a prerequisite part of these other pieces for Carbons to be able to >>> advance, but defining how it interacts with Pubsub/Account seems >>> necessary. It also seems necessary to include type=normal (I think we >>> can get away from type=groupchat, thankfully, cleanly in the >>> MUC2/PubsubAccount approach). >>> >>>> * Could your envisioned changes be add-on instead? I.e. is there a >>> chance of future proofing this (now)? >>> >>> Possibly, but I don’t think we’ve got the picture firm enough yet. >> >> So the question is, do we need to make this spec to be the perfect solution, >> or is Carbons good enough for now? > > I think it’s good enough for people to use now and get benefit. Indeed, I > would suggest people go ahead and implement the current version - but that’s > because I believe future changes shouldn’t be onerous, not because I don’t > believe they’ll happen. > > Note that I’m not opposing any change to Carbons that’s been suggested (of > which I’m aware), nor am I preventing publication. So while I can see that my > position of this not being (quite) the right time to move to Draft is > annoying some people, I don’t think this is preventing practical progress, > and I believe it’s saving time later to avoid pushing to Draft prematurely. > > The point of Experimental is to get XEPs published and discussed and > implemented and experimented with so that we can move to Draft when we > believe they’re addressing the problem appropriately. I’m very keen on these > things happening. > >> We've seen a lot of hinting at improvements, and I do remember your own >> suggestions, but I wonder if we couldn't do that in a new spec instead. When >> have we waited long enough to decide this is the best we can do for now? > > Well, that was the proposal I made earlier this year, and there was wide > agreement that a new spec was the wrong approach, and waiting for Carbons was > right. I’ve even convinced myself at this point that waiting for Carbons is > probably right. > > Dave - do you have an ETA on the pubsub/Account stuff? I think that might > help matters significantly.
Thought. Would it work to have the rules-for-what-should-get-multiplexed pulled out into a new Experimental XEP, so that the Carbons core (syntax etc.) could safely go to Draft? /K
