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

Kevin Smith kevin.smith at isode.com
Wed Aug 12 14:56:56 UTC 2015


> On 12 Aug 2015, at 15:45, Sam Whited <sam at samwhited.com> wrote:
> 
> On Wed, Aug 12, 2015 at 8:07 AM, Kevin Smith <kevin.smith at isode.com> wrote:
>> 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.
> 
> I'm skeptical that this will happen in the (hopefully near) future. We
> should not hold back a spec from advancing IMO because of some vague
> idea that it might need to be changed later. If we stopped advancing
> all XEPs that might need changes to make them comptaible with some
> as-yet-undefined future spec, no XEP would ever be able to move
> forwards.
> 
> This isn't a personal dig at Kevin, but a general observation of the
> many times I've seen statements like this used in standards bodies, or
> privately for architecture decisions and the like at places I've
> worked: It's just a stalling tactic used to halt a discussion without
> requiring any actual citation or reference material (an actual spec,
> or even work on an actual spec, for which carbons needs to be
> changed). Put a document on the table, and then I'll probably agree
> with the above.
> 

“This isn’t a personal dig at Kevin, but … It’s just a stalling tactic to halt discussion” is both disingenuous and insulting.

I don’t want to halt this discussion - far from it, I’ve been trying to have it for months (indeed, those who’ve been around long enough might remember my multi-device protoXEP from several years ago). I simply don’t think that it’s consistent with XEP1’s instruction ~="avoid backwards-incompatible changes to Draft XEPs" to push a XEP to Draft when it’s had wide agreement (Citation: Summit) that it needs changes.

/K


More information about the Standards mailing list