On Wed, Jul 6, 2011 at 5:59 PM, Peter Saint-Andre <stpe...@stpeter.im> wrote: > On 5/17/11 2:26 PM, Kevin Smith wrote: >> 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. > > Kev, I've thought about this some more and I think it's OK to retain this: > > <stream:features> > <dialback xmlns='urn:xmpp:features:dialback'> > <errors/> > </dialback> > </stream:features> > > That's what we've had since version 0.5 of the spec, published on > 2010-03-18. I don't like it and I think we need to add a note that this > is not the recommended way of defining stream features so that other > specs won't emulate this approach, but the protocol hygiene is just not > important enough to me here.
I'm happy with notes saying that this is the Wrong Thing to do, and we can even give a footnote of what the Right Way is, if we want. /K
