On 7/7/11 2:51 AM, Kevin Smith wrote: > On Wed, Jul 6, 2011 at 5:59 PM, Peter Saint-Andre <[email protected]> wrote: >> On 5/17/11 2:26 PM, Kevin Smith wrote: >>> On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre <[email protected]> >>> 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.
I'll work up some text along those lines for review on the list. Peter -- Peter Saint-Andre https://stpeter.im/
