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.
Peter
--
Peter Saint-Andre
https://stpeter.im/
