[Standards] Move Carbons to Last Call ("Proposed")
kevin.smith at isode.com
Wed Aug 12 15:37:24 UTC 2015
On 12 Aug 2015, at 16:31, Kevin Smith <kevin.smith at isode.com> wrote:
> On 12 Aug 2015, at 16:14, Ralph Meijer <ralphm at ik.nu> wrote:
>> On August 12, 2015 4:50:18 PM GMT+02:00, Kevin Smith <kevin.smith at isode.com> wrote:
>>> On 12 Aug 2015, at 15:44, Ralph Meijer <ralphm at ik.nu> wrote:
>>>> On August 12, 2015 3:07:44 PM GMT+02:00, Kevin Smith
>>> <kevin.smith at isode.com> wrote:
>>>>> The thread is moving somewhat away from Carbons Last Calls, but this
>>>>> 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
>>>>> the pubsub/account stuff is specced/we have deployment experience. I
>>>>> believe this means that going to Draft now wouldn’t be appropriate,
>>>>> 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
>>> 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?
More information about the Standards