[Standards] Move Carbons to Last Call ("Proposed")

Ralph Meijer ralphm at ik.nu
Wed Aug 12 15:14:07 UTC 2015


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
>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?

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?


-- 
ralphm



More information about the Standards mailing list