On 15 Jul 2015, at 19:18, Patrik Fältström wrote:
True, but if we look at the chat protocols, IETF could not agree on
which one of three different protocols should move forward. Then XMPP
came and, well, was developed elsewhere and basically "won".
I do want to point out that we ceded change control over XMPP to the
IETF, and the XMPP working group made some fundamental changes to the
protocol, including start-TLS, stringprep, SASL, a new error name
scheme, version numbering, etc.
A similar approach was used for SPDY morphing into HTTP/2.
I don't see any way that these protocol development efforts can be used
as precedent for this draft. If the TOR folks wanted to go through the
process to standardize their protocols, we could think about the
architecture we wanted for their identifiers and think about ways to
avoid a special-use name.
In the meantime, I have a specific technical objection to this draft,
section 2:
2. Application Software: Applications (including proxies) that
implement the Tor protocol MUST recognize .onion names as special
by either accessing them directly, or using a proxy (e.g., SOCKS
[RFC1928]) to do so. Applications that do not implement the Tor
protocol SHOULD generate an error upon the use of .onion, and
SHOULD NOT perform a DNS lookup.
I'm skeptical that this SHOULD NOT will have any effect on any
application other than some small number of popular web browsers. There
are a LOT of non-web-browser applications in the world that do DNS
lookups, and almost none of them will ever find out that they are
leaking information because of this SHOULD NOT.
As such, I suggest that this doc does not provide an adequate technical
or market-based mechanism that will achieve its stated goal.
--
Joe Hildebrand