Subject: [xmpp] DNA prooftypes: advertising support and preference order?

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 Jan 2013 10:46:10 -0700

Currently in DNA (draft-saintandre-xmpp-dna, recently expired but soon
to be updated), there is no way for the receiving server or the
connecting client / peer server to advertise the prooftypes it
supports, or its preference order for prooftypes. This means it is
possible that:

(1) the set of mutually supported prooftypes might be null (in which
case a connection attempt might be futile, depending on local security
policies)

(2) "expensive" prooftypes might be tried too early in the process (in
which case the connecting client / peer server might spend time more
trying to connect than necessary).

My co-author and I chatted about this last week. Our rough sense is
that we won't have enough prooftypes for this to be a significant
concern, that the cost of adding and supporting more protocol (e.g.,
stream features) here isn't worth the potential benefit, that
conventions regarding the prooftypes that need to be supported will
emerge naturally in the relatively small market of XMPP systems
needing DNA (mostly, large hosting providers), and that initiating
entities can support an algorithm similar to "happy eyeballs" (RFC
6555) in order to speed up the connection process.

If you disagree with our conclusions, do feel free to say so on the
list. :)

We *might* add some text about several of these topics in the next
version of the spec, but most likely such text would be relegated to
implementation and deployment notes or an informational appendix.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/