I see no reason to mandate that new hubs support both the new and old
encodings, and certainly not indefinitely. DC client turnover is quick
enough that I'd be comfortable in a few months with dropping support for
the old encoding, for example, in any hubs I'm involved with.

I think even few weeks is reasonnable. Moreover, IMHO, this is mainly a hub problem, client should only use one protocol version, if someone wants to use both protocol, he justs as to install an old version of its client and the new one.

CR should not be a separator; I find multiline message support valuable,
for example, for ensuring pasted source code is nicely formatted.

sure.

XML, of course, avoids the problem with the proposed CR-delimited message
format, and I find it preferable. Further, the suggestion to use lzo (or
even zlib, depending on overhead; I know lzo has significantly less, but
zlib's improved compression may be worth it. Something to consider),
renders XML quite bandwidth-friendly. It has the additional benefit of
encoding commonly used nicks and command and such concisely after it's
built up a dictionary, beyond just the XML tags.

However, I'd prefer an a binary encoding to either of those, as a means of
resolving the currently extant divide between a socket mode for
transferring files and one for transferring commands. This may be an
aesthetic point, but I find that quite unelegant. If one is going to
homogenize the rest of the protocol encoding, leaving out the file
transfers themselves strikes me, at least, as a conspicuous omission which
should be justified. Mandating purely textual content, UTF-8 or not, would
prevent such a unification of the protocol, and as such should be avoided.
By contrast, a protocol designed to natively handle binary data would be
quite capable of dealing with file transfer data itself in a common
framework as the commands itself, and is thus an improvement over a
text-basis for a P2P file transfer protocol.

I totally agree with you, a binary protocol is better, data can be parsed/processed faster and using "chunked" commands, a client/hub can quickly discard packets it does not need/understand.

Finally, DC has many semantic, rather than syntactic, limitations, and
whilst replacing the syntax certainly aids towards fixing the broken
semantics by creating a more extensible environment in which to introduce
improved semantics, I feel that one should take the opportunity created by
breaking compatibility to introduce functionality such as: standard
GetZBlock-type download support, hash support, search ID support, and
various other flaws described at http://murdoc.extatic.org/dctng.html.

I agree at 98% with the content of this page (there is few thing that cannot be applicable (like maxu/maxd in Info)). I also think each task should have an ID (a task is a more of less big set of commands/replies between 2 entities (hub or client)), this will allow a correct handling of error codes. This is discribed in the page for Search/SR handling but it should be extended to all tasks (like the task 0: the login stage) [Note: don't think I found this in a magic box :) some other protocols use this kind of binary encoding]

Eric
DCTC/dchub