[Standards] UPDATED: XEP-0220 (Server Dialback)

Peter Saint-Andre stpeter at stpeter.im
Mon Sep 19 17:08:36 UTC 2011

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 <stpeter at 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 <stpeter at 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.
>> 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 Saint-Andre

More information about the Standards mailing list