[dcc2] Multi headers + metadata

[codemstr at ptdprolog.net]

> I think the kind of device he is referring to is the kind that would be 
> hard-pressed to spare 50Kb for an XML parser.  Your Pocket PC (which, I'll 
> point out, is really a small PC) can easily spare the space for an XML 
> parser.

You don't seem to know what you're talking about here. An HP iPaq is *not* a 
small PC. It doesn't even have a hard drive! It has 32MB of storage space. 
It's a PDA, not a PC. On my PDA, no I don't have 50Kb to spare for XML. 

> First of all, getting the certificate is not the only problem.  A "Freemail 
> certificate" is worth nothing in terms of verifying the authenticity of the 
> information the certificate represents.  In the certificate world, freemail 
> certificates are little more 
than a technical hack to get around having a 
> self-signed certificate.
So because some people can't afford an SSL cert, no one should be allowed to 
use SSL? In that case, perhaps we should go launch a protest at BMW's 
headquarters. If everyone can't afford it, clearly no one should have it. 
That's the argument being made here. I could go even further to say it would 
be hypocritical of us to even consider this draft since not everyone can 
afford Internet access, or even a computer for that matter. I can afford an 
SSL cert, I have an SSL cert. Why shouldn't I be allowed to use it? If you 
can't afford an SSL cert, then you don't use SSL! I never said don't support 
Blowfish, I was saying don't replace SSL with Blowfish, you can certainly 
support both. If you want top notch security and authentication, it should be 
available to you. Just because some people don't have it, doesn't mean no one 
should have it. 

> Aside from that, if you have SSL you also need to have a library of 
> certificates that belong to the certificate authorities.  This is easily 
> more than 50Kb.  On my system, the certificates add up to 120Kb.

Again, do a little homework. First, some clients already include a trusted CA 
file (x-chat for example), so they would see no file size increase. Secondly, 
every major web browser already includes a pretty robust CA file. Why can't 
the IRC client simply tap into that? On Windows at least, it would be very 
easy to look up where the file is stored and read it from the IE/Netscape 
directory. Also, on a PocketPC based PDA, the IE included has the CA certs, 
so again you're good on small devices. And, again, I have 120KB to spare. 
Because you don't means I can't use SSL? No, it means you can't use SSL. You 
don't hold back everyone because of a few. You make it compatible with the 
minority, but you tailor it to the majority. SSL is optional, if you don't 
have the 120KB, then don't use it! 

Say, for example, I run an OS that doesn't support >2GB files. So does that 
mean DCC2 should limit file size to 32bits? Of course not! You make it 
compatible with OSes that only support 32bit addressing, but you don't hold 
everyone back because of it! 

Btw, large files (64bit addressing) is something the spec doesn't seem to 
address at all? And it probably should. There needs to be some way to 
determine if the Size= is 32bit or 64bit so that the receiver knows how to 
interpret it. And, if it is 64bit and the receiver can't support 64bit, it 
needs to know this so that it can reject it rather than receiving 2GB then 
corrupting the file because the counter wraps around. 

Also, let me point out something about XML. The SSL issue is different than 
XML because SSL is completely optional. If someone wants, they can add 
Blowfish, or even go so far as to use a Caesar cipher. You can do whatever 
you want. With XML, there was no way to specify an alternative. It wasn't 
that some people could use XML, some INI, some binary, some plaintext; it was 
either use XML or no multi transfers. The encryption mechanism in the draft 
allows you to basically specify whatever encryption you want, so long as both 
the sender and receiver support it. So they are two completely different 
situations.

-- codemastr