On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre <stpe...@stpeter.im> wrote: >>> 1. Child elements as in 0.9: >>> >>> <stream:features> >>> <dialback xmlns='urn:xmpp:features:dialback'> >>> <errors/> >>> </dialback> >>> </stream:features> >> >> I'm not opposed to this, I think. It has the advantage of not breaking >> the existing implementations. > > The concern is, what happens when someone adds new sub-features in the > future?
Hopefully we wouldn't spec new features without versioning and start seeing interoperable implementations prior to realising in the future :) >>> 3. More features: >>> >>> <stream:features> >>> <dialback-errors xmlns='urn:xmpp:features:dialback:errors'/> >>> </stream:features> >> >> This one breaks existing dialback error implementations, but not >> general dialback implementations. This one doesn't seem particularly >> harmful, compared to (2), and I'll go along with the majority if it's >> what's deemed sensible. > > #3 is more consistent with what we do in service discovery. IMHO that's > a good thing. Yes, #3 is what we have previously agreed is the Right Thing to do with features. In this case we didn't, and implementations sprouted up and were deployed before we noticed, so it's a question now of whether the pragmatic thing is to use what we have, or to break implementations and maintain spec-hygiene. /K
