Opera wrote:

There are issues with ADC that I personally consider should be changed
or looked more deeply into.

First of all it's the message delimiter \r\n that should be changed to
\n. There is no reason to favor the current win32 implementation of
new-lines here, it only adds bug-sources to code. Splitting messages
with only one 'char' is better in every possible way I think. And this
isn't http anyway ;)

The question is not really about dos newlines or not, a CRLF pair is just more rare in normal messages and it's commonly used in protocols (dont ask me why).
It's easier to split messages by 1 char, but I dont think that todays machines have any problems doing it, nor the coders.
And besides (as you mentioned dos newlines) the CRLF pair will not be used as a newline, it will be used as a command delimiter (as you said).
Newlines (in chat messages) would be simplest to use a single \n as it's shorter than a CRLF pair and is more frequent in (chat) messages.
Also, as discussed in previous mails, this adds for easier debugging via a telnet session.
Besides, what's the big fuzz?

Numbers should be at least double? "double" is implementation-specific
so I guess you mean 64-bit? And then, why? This must be, just like
integers being 64-bit, state dependant. Not all kinds of data needs such
large numbers, I'd say that's a specification that should be removed
from the protocol.

As it is a not a binary protocol this does not matter. If a client has stored his/hers share size in a 64-bit double and would print it into a text command would still be something like "21335535.2355".
What I belive what has been said is that the numbers used (large ones) should be a decimal one.

In the ERR message there are params and description. Since this protocol
says that message parts are delimited with space, and descriptions can
include space, how will I know what is a parameter to ERR and what is
the description? Maybe "ERR Code:Descr: param1 param2..." is a better
way, and force description not to include ':'.. It's ugly yes, but just
a note.

Why not reply codes? Like most of the protocols used anyway?
"<code> <description> [<param1>[ <param2>]"
like in:
`301 "Erroneous Nickname" This}Nick$NameContains%Illegal#chars'

Oh, and about the error codes. Really need a a range of 100 codes per category? I think a range of 5-10 would do, really.

In INF I couldn't see an ip port for TCP. How will client A be able to
connect to client B without knowing the TCP port? Maybe I missed
something..
And when speaking of INF, "HI"? Can an arbitrary user send that info to
become invisible? I think it should be used only for special occasions
of some kind of bots. And then it's prolly up to the hub anyway to "make
it hidden", so, I really don't see the use of this.

U4,U6 ?

I would like a "mode" where file sharing is disabled, a kind of "chat
only mode". That should be represented in the INF as well with HC or
something like that..

Should be set serverside, otherwise there would be ppl/clients choosing not to share - only download. Mean, either everyone shares, or noone at all.

If I send a MSG how will end-lines be escaped? The regular \n (or if
\r\n for some very weird reason is preferred) will cause the next line
to be interpreted as another message/command, right?

Like I said in the discussion before with the CRLF delimiter. Use CRLF for ending commands. LF for chat message newlines. Simple.

/Carl-Adam