On 5/17/11 2:07 PM, Kevin Smith wrote: > On Tue, May 17, 2011 at 9:00 PM, Peter Saint-Andre <[email protected]> wrote: >> So let's talk about solutions. >> >> 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? Do we really want something like the following?
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
<errors/>
<dna/>
<advanced-piggypacking/>
</dialback>
</stream:features>
Envision what that would be like for something like XEP-0060:
<iq type='result'
from='pubsub.shakespeare.lit'
to='[email protected]/barracks'
id='feature1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='pubsub' type='service'/>
<feature var='http://jabber.org/protocol/pubsub'>
<auto-create/>
<collections/>
<create-and-configure/>
<filtered-notifications/>
<und-so-weiter/>
</feature>
</query>
</iq>
It seems preferable to take the same approach for stream features that
we take for normal features (disco), which is why I proposed versioning
of stream feature namespaces. But Dave has me mostly convinced that
there is a better way.
>> 2. Versioning:
>>
>> <stream:features>
>> <dialback xmlns='urn:xmpp:features:dialback:1'>
>> <errors/>
>> </dialback>
>> </stream:features>
>
> This one *does* break all existing implementations of dialback, which
> seems to me like a bad thing.
Bad copy and paste, should be:
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback:1'/>
</stream:features>
But no one likes that one anyway.
>> 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.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
