[Standards] UPDATED: XEP-0220 (Server Dialback)
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,
> >> removing the need for an <errors/> child element; clarified a few
> >> points in the text. (psa)
> > Interoperable implementations of dialback using <errors/> child
> > to indicate this capability exist; is there any reason to change
> > 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
> such as:
> <dialback xmlns='urn:xmpp:features:dialback'>
> That seems like a bad path to go down. Much better, I think, to use
> mechanism we already have: protocol versioning, such as the
> for old-style RFC3920 dialback (mythically version zero of the
> but we use stream headers instead), dialback-with-errors, some
> 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
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:
This seems opaque, in the extreme. A less obfuscated way would be:
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:
... 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:
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
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards