[dcc2] Multi headers + metadata

[codemstr at ptdprolog.net]

Phoenix Fyrestar <miyako_houou at comcast.net> said:

> You make a number of convincing arguments.
> 
> As far as the problem with having to send the key over the network, thereby 
> eliminating the benefit of encryption, what about the possibility of 
> sending a key over ssl?  My knowledge of cryptography is rather limited, so 
> I'm just throwing a few ideas out there.
Yes, you could do that... but then why use blowfish at all? Why implement SSL 
and Blowfish in order to get the same effect as SSL? Seems like just using 
SSL is best. 
> 
> The problems with the legal difficult of distrubuting a cryptography 
enabled 
> program from within the us is a more difficult one, but I think that we 
> should not omit it from the protocol just because an opressive regime in 
> the US is stifeling it's citizens privacy.  If a client chooses not to 
> support encryption for whatever reason, then that client will simply choose 
> to talk only in an unencrypted manner.

Without getting into a political debate, the US laws have no affect on "its 
citizen's privacy." US citizens are free to use any/all encryption 
technology, the limitation lies in the exportation of the technology. I never 
said encryption should be removed because of this, just that it should be 
optional. Which, as the below comments indicate, was a result of my 
misunderstanding of your usage of the word "necessary."

> What I was referring to when I said that I saw encryption as a neccesity is 
> that I think it is something that should be defined in the protocol for 
> sure, and should be able to be either included or not included by the 
> client authors.  There should be a way of handling this, perhaps sending a 
> request for an encrypted chat that the client can either accept or decline.

Sorry, I was thinking differently. Meaning, "necessary" indicates a 
requirement. I definately think encryption should be an option for everyone.

> With regards to the question of a compression mechanism, I agree that there 
> should be room to add another compression method later, but we should still 
> dictate a universal bottom line I think.  Something to say that all 
> compression enabled clients will support at least compression algorithm foo.

Well I disagree. Consider this. We say "everything must support foo." Six 
months from now, foo's developers/copyright holders decide, "You know what? 
We could make some real money if we make our code proprietary!" And so they 
do. Now, according to the DCC2 spec, all implementers are required to support 
a proprietary protocol. Or, a year from now, people decide foo is just plain 
garbage compared to the newer, better, compression protocols. And so they 
decide to stop developing it. Then, a month later, a guy discovers an exploit 
in the algorithm that allows arbitrary code execution. Since the project is 
dead, it might never be fixed. Therefore, the DCC2 spec now requires 
implementers to support an exploitable protocol. Also, lets consider 
programming language foobar. Foobar is a brand new language with many 
advanced features. However, not many people like it and so few people develop 
for it. And, even worse, the interface it uses leaves it incompatible with 
C/C++ (and other common languages) libraries. The DCC2 spec says "you must 
support foo and you may support bar for compression." Well, this particular 
language only has a library for bar, not foo! So, the way the spec is worded, 
any client written in foobar cannot implement bar compression because it 
would then be breaking the DCC2 spec simply because the language does not 
have a library for foo compression. However, since bar is better than foo, if 
you had a choice, you'd use bar anyway. So why should not having foo disallow 
you from using bar? (Hope that wasn't too confusing ;)

Would any of that happen with something like gzip? Probably not in the near 
future. But IRC isn't a protocol that has the spec updated every day, RFC1459 
was written 11 years ago. Who knows what programming will be like 11 years 
from now. Maybe, 11 years from now, gzip will be considered to be a laughable 
display of a compression algorithm that your average monkey could create. 
Basically, I'm just saying don't lock yourself into requiring support for 
something that may eventually be obsolete. Compression should, without a 
doubt, in my mind, be available. Just, compression, and the particular type 
of compression it uses, should be optional. 

> The client either chooses by default or allows the user to choose a maximum 
> compression level.  In the file send meta-file there would be a line that 
> gose something like:
> 	maxcompression="6"
> or whatever.  That way the receiving client would know what the maximum 
> requestable compression level is, it could then either by default, by a 
> stored value, or by asking the user, send in it's reply the requested 
> compression level.

Yeah, I guess this could be a good idea. Just would need to be setup in some 
way so as to indicate that it only applies to gzip and not to all compression 
mechanisms. One thing though, with the meta-file comment, does this mean that 
you're suggesting compression should only be implemented for multi-file 
sends? Because I'd like to see it for single file sends as well. If I'm 
sending a 5MB jpg file, I'd like that to be compressed, even though it is 
only a single file.

-- codemastr