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

Jacek Konieczny jajcus at jajcus.net
Thu May 19 07:24:43 UTC 2011

On Tue, May 17, 2011 at 02:20:58PM -0600, Peter Saint-Andre wrote:
> Bad copy and paste, should be:
> <stream:features>
>   <dialback xmlns='urn:xmpp:features:dialback:1'/>
> </stream:features>
> But no one likes that one anyway.

Yes. It is wrong before <dialback xmlns='urn:xmpp:features:dialback:1'/>
is a totally different element than <dialback xmlns='urn:xmpp:features:dialback' />.
It is not a new version, it is a new protocol. And a new namespace. Why
would we want that?

That is the always returning problem with XMPP protocols – treating the
namespace like an attribute. It is not an attribute, it is a part of
element name.  '<a xmlns="a"/>' is different from '<a xmlns="b"/>' the
same way '<a/>' is different from '<b/>'. Namespaces give us
availability to use e.g. '<error/>' element in different protocols in a
different way, for a different purpose. They should not be used to give
extra meaning to an existing element.

We already have enough of the legacy of 'jabber:client' and
'jabber:server' namespaces used for the same element just in different
contexts, which makes stanza handling complicated (I am just in the pain
of trying to handle that properly in pyxmpp2)…

I guess single XEP should never be allowed to define more than one XML
namespace. Namespaces are meant to help avoid name conflicts. Why would
one specification conflict with itself? Versioned namespaces make sense
only when we throw the old specification away and create a new one when
the same elements have different meaning or schema.

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

I like this too. In addition to the regular diallback feature
announcement. In fact it could be a new element in the old dialback
namespace. No need for another namespace for use with the same

IMHO this would make sense:

    <dialback xmlns='urn:xmpp:features:dialback'/>
    <dialback-errors  xmlns='urn:xmpp:features:dialback'/>

(two features announced)

or this:

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

(one feature with an extra option announced),

but not adding a new element in a new namespace instead of the already
known element.


More information about the Standards mailing list