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

Peter Saint-Andre stpeter at stpeter.im
Mon Sep 19 17:03:44 UTC 2011

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.


Peter Saint-Andre

More information about the Standards mailing list