On 7/7/11 11:37 AM, Peter Saint-Andre wrote: > 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.
My apologies for the delay. I propose that we add the following paragraph at the end of Section 5.2: As a general rule, stream feature elements containing child elements that advertise particular sub-features are not encouraged. The format shown above is used for the sake of backward compatiblity with existing implementations and deployments. Peter -- Peter Saint-Andre https://stpeter.im/
