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
incompatible.
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'/>
<dna
xmlns='urn:ietf:params:xml:elephant:doormat:xmpp:these:ietf:urns:are:very:long:dna'/>
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'>
<errors/>
<dna/>
</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'>
<dna/>
</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.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
