[dcc2] Multi headers + metadata

Thu Apr 29 02:11:00 EDT 2004

First of all, my apologizes for sounding like a political extremist or
something, I was a little cranky at other things when I wrote that email :)

I really do understand the necessity of not locking ourselves into a single
compression algorithm, my primary concern is just to make sure that the
various clients can inter-operate without great difficulty.  If anyone can
come up with a way to do this that doesn't require either locking ourselves
into a compression scheme or requiring clients to support every possible
scheme, I would graciously throw in the towel for this argument.  I mean I
guess the least common denominator is always not supporting any compression,
but seems like there is probably a good compromise that I am just not
thinking of.

As far as running everything through SSL, I have no problem with this, I was
just under the (apparently mistaken) impression that for some reason or
another people were thinking this might not be a good idea, so I was trying
to purpose alternate solutions.

On 4/28/04 9:37 PM, "codemstr at ptdprolog.net" <codemstr at ptdprolog.net> wrote:

> 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