[dcc2] Multi headers + metadata

[Phoenix Fyrestar]

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.

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.

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.

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.

The compression levels I reffered to were there only as an idea if we accepted 
a supporting compression algorithm, and as a means to show one possible 
benefit of choosing gzip.

I think I can better explain the idea I had about choosing a compression level 
though.

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.

Of course it is possible that some rouge client may send higher or lower level 
compression than is asked for,  but I do not see that as a protocol problem 
so much as a social one.  The same senario could be said for anything.  What 
if the user wants to engage in an encrypted chat and tells the reciever that 
the key is "12345" when it is really "54321", the person on the reciving end 
will just not deal with that person anymore.