[dcc2] Clarification of DCC2 status

[codemastr]

> As I brought up before, is
> the "size:" header, the OFFSET token, the SIZE token, and the MULTI token,
a
> 32bit number, or a 64bit number?
>
> i think that the size used by the client for theese should be an
> implementation descision but a client MUST cleanly reject numbers too
large
> for it to handle

That's what I was thinking as well, but it's not mentioned anywhere in the
draft. So, if an implementor totally forgets about large files, that could
clearly result in an overflow. Depending on the language, that can cause
anything from a corrupt file, to a crash (e.g. Java throwing an overflow
exception).

I'm not saying no one should work on an implementation, I'm just saying such
ambiguities need to be solved beforehand. Reading over the draft, I see
several ambiguities/things that need to be addressed:

1.) The 32bit vs 64bit

2.) Do multi transfer headers have to be in a specific order (all the
examples use id, name, size, optional headers).

3.) Typo: Section 3 of negotiation draft. The text says use \001 (ASCII code
0x1) but the text shows /001. Which is it? Of course, someone familiar with
CTCP would realize it's supposed to be 0x1, but if this is your first time
writing for IRC, you might assume it is the actual character sequence /001.

4.) The NAT token, as someone pointed out, is confusing since it only deals
with some NAT issues, and it also deals with issues that are not at all NAT
related. To avoid ambiguity, this should probably be renamed. I suggest
taking a page from FTP and calling it PASV or something of that nature.

5.) Both drafts make up some ABNF rules. For example, you use "digit" and
"alpha" and "hexdig" well according to RFC2234, these should be written in
all uppercase. Therefore this can lead to confusion, are these different
than the ones RFC2234 describes? This could lead to problems. RFC2234 says
HEXDIG is 0-9/A-F. Well if someone interprets your lowercase version
differently, they may assume it includes a-f as well, which the ABNF one
does not. That leads to problems when specifying IPv6 addressses. If it is
assumed to be HEXDIG, then an IPv6 address can not have a-f, it must be
uppercase, if it is assumed to be differently, someone might believe that
using lowercase addresses is just fine.

6.) What happens if the negotiation message is too long to fit on a single
line? With current DCC, that's not much of an issue. With the new one, it
is:

PRIVMSG 32char_nickname :\001DCC2 Application=IRCFile Transport=SCTP,TCP,UDP
NAT Size=281474976710656 Offset=34359738368 Network=IPv4,IPv6
TransportSecurity=SSL3,TLS1 SID=10a/001

That's already over 160 characters. Then add if I added a ",Blowfish" a
"TransportCompression=gzip:9,compress,lzw" you can clearly see that before
even getting to the point where you need to specify a filename, you're
already approaching the 512 limit. Adding all that stuff, we're then at 239
(241 including CRLF). And again, that's without the filename, that leaves
you with a max of 271 characters for a filename (in my example). Of course,
I would not be suprised if new tokens are added before this is finalized.
One that comes to mind right away that we'll probably want to add eventually
is a "HashMethod" type token. So you'd do like
"HashMethod=SHA1,RIPEMD160,MD5,CRC32" to specify the preference of the
hashing function used. And I'm sure more will come. By the time all is said
and done, we might be limited to a rather small number of characters in the
filename.

7.) DCC Chat hasn't even been mentioned yet, other than how to establish the
connection. This may seem simple, but I can see several issues that will
arise. Will DCC2's DCC chat be like the current? Or will it also support a
"Partyline" system built right in? That makes a huge difference to an
implementer.

8.) There is never mentioned anywhere a TLS1 token (It is always shown as a
value to TransportSecurity) however, in 5.2.3.1 (1) it suddenly pops up as a
token on its own as part of the Accept message. Same thing with IPv6. The
only place IPv6 is mentioned as a token is in 4.2.2 in which it says it
requires a value. No where is TLS1 nor IPv6 mentioned as being tokens to the
Accept message. In fact, the only way to infer how to use the Accept message
is to look at examples. That will obviously lead to incompatibility!

9.) Someone already mentioned that the section about NAT traversal actually
has nothing to do with NAT traversal.

I have to tell you, if I were reading these documents as someone who was
trying to implement the protocol, I could guarantee you it would not be
compatible with anyone else's implementation. The whole thing is confusing!
I don't think anyone should even consider implementing this until all of the
issues I mentioned (and probably many I didn't mention) are addressed.

I'm not trying to tear the draft apart, I simply went through it, as if I'm
someone new to IRC development, and pointed out anything that I think would
confuse me. And I think everything I pointed out is a very valid issue.

-- codemastr