[dcc2] Multi headers + metadata

[Mark Cilia-Vincenti]

I agree... standards shouldn't be enforced as regarding encryption and
compression... first off, it discourages developers from building DCC2
clients because there would be too much work involved, secondly because
there is no means to know whether the agreed-upon technologies would be
obsolete in a few years' time, and thirdly because a protocol isn't
meant to be bloated.

-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf Of
codemstr at ptdprolog.net
Sent: 29 April 2004 04:37
To: DCC2 Working Group List
Subject: Re: [dcc2] Multi headers + metadata

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
_______________________________________________
dcc2 mailing list
dcc2 at dcc2.org
http://six.pairlist.net/mailman/listinfo/dcc2