[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?

<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='francisco at denmark.lit/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/



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