On 9/19/11 11:03 AM, Peter Saint-Andre wrote: > 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.
Sorry, I think that belongs in Section 2.4.2. Peter -- Peter Saint-Andre https://stpeter.im/
