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

Dave Cridland dave at cridland.net
Tue May 17 17:51:36 UTC 2011

On Tue May 17 18:04:43 2011, Peter Saint-Andre wrote:
> On 5/17/11 10:30 AM, Dave Cridland wrote:
> > On Tue May 17 02:14:06 2011, XMPP Extensions Editor wrote:
> >> Changelog: Modified stream features to incorporate versioning,  
> thus
> >> removing the need for an <errors/> child element; clarified a few
> >> points in the text. (psa)
> >
> > Interoperable implementations of dialback using <errors/> child  
> element
> > to indicate this capability exist; is there any reason to change  
> the
> > namespace at this point aside from aesthetics?
> The concern that Jack Erwin raised with me is that putting child
> elements in stream features will lead people to expect more of the  
> same,
> such as:
> <stream:features>
>   <dialback xmlns='urn:xmpp:features:dialback'>
>     <errors/>
>     <dna/>
>     <advanced-piggybacking/>
>     <some-future-feature/>
>   </dialback>
> </stream:features>
> That seems like a bad path to go down. Much better, I think, to use  
> a
> mechanism we already have: protocol versioning, such as the  
> following
> for old-style RFC3920 dialback (mythically version zero of the  
> feature
> but we use stream headers instead), dialback-with-errors, some  
> future
> dialback-with-dna, etc.:
Right, thanks for the explanation, and in particular raising this on  
the list, I'd not seen this argument before.

And that in turn explains why I've not argued vociferously against it  
before, which I'll now do...

Versioning is *nearly* always the wrong thing to do.

Our namespace versioning is not versioning of the protocol in this  
sense, because that would imply that "urn:xmpp:features:dialback:0"  
is a subset of "urn:xmpp:features:dialback:1", whereas no such  
assertion exists - the two are entirely unrelated from a protocol  
standpoint, and any similarity is merely in the familial sense -  
they're likely to have both been specified in the same document at  
different times.

But - crucially - no compatibility is asserted; indeed the precisely  
opposite assertion is made: the two protocols are mutually  

As protocols develop, however, optional features do get added, and  
these should be independently signalled in most cases. Sometimes it's  
better to signal levels, but those levels need to be designed in from  
the outset. An example is IMAP's relatively recent I18NLEVEL  
capability (See RFC 5255). If we wanted to signal levels, we should  
have done so earlier, and by a distinct version or level field, and  
absolutely not by a namespace. While in general it's better to avoid  
silly-states, where a server can advertise a useless combination of  
features, this is sometimes unavoidable. In this particular case, DNA  
is likely to rely upon error handling.

So in this case, if servers signalled error handling by one feature,  
but we intended to change the namespace to signal *also* handling  
DNA, then we'd also need to signal the old namespace anyway, to avoid  
the case where older servers would cease to interoperate because the  
required feature is no longer found:

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

This seems opaque, in the extreme. A less obfuscated way would be:

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

But this is pretty ugly too, or at least not especially pretty.

So instead, we could choose to consider error handling and DNA as  
suboptions of dialback, and write:

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

... which brings us back to what we had before this change. I think  
this is fine, and I specifically do not see why this is a bad thing  
to do, or to continue to do. In particular, this would mean that  
servers written now, and looking for and advertising  
<dialback><errors/></dialback>, will continue to work, and new  
options will not change this.

Of course, this leaves the silly-state:

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

And here we need to define whether this is legal, and if it is, what  
it means. But not here, and not now.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list