[Standards] dialback feature

Dave Cridland dave at cridland.net
Wed May 18 16:14:50 UTC 2011

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  

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  

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