On Wed May 18 16:26:39 2011, Peter Saint-Andre wrote:
So here is what I proposed during the XMPP Council meeting:
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'/>
</stream:features>
http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110518/#15:05:44
That would mean "I support updated dialback with the fancy dialback
errors stuff", because we advertise support for traditional
dialback via
namespace declaration on the stream header.
Thus we get rid of the <errors/> child element because we seem to
have
consensus that it's Just Wrong [tm].
I'm slightly concerned that there may exist implementations that
treat this as being equivalent to the (old-skool) dialback namespace
declaration. I'll investigate our own.
This said, my primary objection to the original change is rooted in a
basic objection to allowing changes to implemented and deployed
protocols on purely aesthetic grounds. This seems like a very small
wart, as warts go - even if one assumes it *is* a wart, and that's
not clear to me. Whichever it doesn't seem worth breaking things to
fix.
As an SDO, we do, of course, have a duty to design "good" protocols.
But we also have a duty to interoperability, and a duty to security.
These are in roughly increasing order; I'm willing - if there's no
option - to break interoperability for the sake of security. (The
introduction of dialback is one such case, well before my time with
XMPP).
Security does not entirely trump interop, mind, because a
non-interoperable protocol is worthless - but it may be a reason for
a breaking change to parts of the protocol at times - and hopefully
very early in deployment.
Aesthetics of a protocol - up to and including the stability of XML
schemas, in my view, though I accept that's not a universal opinion -
should always be outweighed by interoperability of deployed code. I'm
very wary of arguments based on the "importance" of such deployment,
too - absent evidence to the contrary, it should be assumed that such
deployment is now in the wild.
So while I'm not particularly bothered about whether future dialback
options should be signalled as individual stream features or
sub-elements of the existing dialback feature, I see no value in
changing the errors sub-element now that there exist deployed
implementations using it for signalling.
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
