[dcc2] Multi headers + metadata

[Mark Cilia-Vincenti]

I don't think this will be a problem in the long term. mIRC will one day
come along and support DCC2 and maybe support some
encryption/compression. Already you have the majority of IRC users that
have a certain type of encryption/compression. It would be wise for
other clients to follow suit and support the standards that mIRC comes
up with even though I'm sure most of you hate it :) Because, like it or
not, it would be mIRC that ultimately decides.

-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf Of
Phoenix Fyrestar
Sent: 29 April 2004 08:11
To: DCC2 Working Group List
Subject: Re: [dcc2] Multi headers + metadata

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

_______________________________________________
dcc2 mailing list
dcc2 at dcc2.org
http://six.pairlist.net/mailman/listinfo/dcc2