> On 12 Aug 2015, at 15:45, Sam Whited <[email protected]> wrote: > > On Wed, Aug 12, 2015 at 8:07 AM, Kevin Smith <[email protected]> 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
