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

Peter Saint-Andre stpeter at stpeter.im
Tue May 17 20:20:58 UTC 2011

On 5/17/11 2:07 PM, Kevin Smith wrote:
> On Tue, May 17, 2011 at 9:00 PM, Peter Saint-Andre <stpeter at stpeter.im> 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?

  <dialback xmlns='urn:xmpp:features:dialback'>

Envision what that would be like for something like XEP-0060:

<iq type='result'
    to='francisco at denmark.lit/barracks'
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='pubsub' type='service'/>
    <feature var='http://jabber.org/protocol/pubsub'>

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:

  <dialback xmlns='urn:xmpp:features:dialback:1'/>

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 Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110517/a13833c5/attachment.bin>

More information about the Standards mailing list