[dcc2] Multi file sends

Tue Apr 27 12:52:28 EDT 2004

But it could be done in a similar way as to how HTTP compression is done
in the sense that the client sends info to the server, and the server
would know if the client accepts compression. Thus, with this way, if
both users would have a certain type of compression, it would be used.
If not, the file is sent without compression.

Compression is also good because the files wouldn't be sent in a raw
format, and some users might be passing on sensitive information in raw
text.

-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf Of
Jeremy Iverson
Sent: 27 April 2004 05:50
To: 'DCC2 Working Group List'
Subject: RE: Re: [dcc2] Multi file sends

I think if we agree not to make clients require an extra library in
one area (XML), we shouldn't require a different library in another
area (zlib). That doesn't make much sense to me.

-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf
Of Craig Edwards
Sent: Tuesday, April 27, 2004 10:42 AM
To: DCC2 Working Group List
Subject: Re: Re: [dcc2] Multi file sends

i'll second this, im very anti-xml, and xml libraries are bloated,
slow, and not easy to develop things for especially when the format
only needs to be simple.

As for 'using compression programs that preserve path information' why
cant we use zlib or something to gzip up the whole thing into some
form of zip or tarball, and send that as a data stream, with a header
appended?

Thanks,

Craig

>Tom McAlee <tom at klient.com> said:
>
>> I'm not a fan of XMLifying everything, although this does seem to
be 
>> an appropriate use of it.  Like others have said, even without XML 
>> libraries it wouldn't be much more effort than parsing a tokenized 
>> string.  For those who have and/or already use XML libraries, it
will fit right in.
>
>Would parsing XML be trivial? Sure. Well, at least parsing valid XML.

>But lets face it, not everyone is nice and plays by the rules. You
are 
>going to have people who will develop specifically crafted XML
headers 
>to try and cause crashes and exploits. Anytime you build a parser,
you 
>run the risk of these kinds of things. What happens if someone 
>specifies an invalid tag? What happens if they leave out an ending
tag? 
>For get a quote? Specify multiple angle brackets? There could be 
>hundreds of potential areas of issue with XML because it is rather 
>complex. However, with a simple text format, you don't need much more

>than a modified strtok() [to support quoted strings] in order to do 
>your parsing. We've all seen the havoc that DCC bugs can cause
(mIRC), 
>and those bugs occurred while parsing the incredibly simplistic
format 
>DCC uses today. Using XML makes the format more complex and therefore

>more bugprone. For example, one thing I'm thinking of right off the
top 
>of my head. HTML-style encoding. What if I want my meta data to
include 
><test>hey</test>? Or even in the file description. To do that, I'm 
>going to need to &lt; and &gt; That means the parser is going to need
to decode HTML- style character codes. That is already making it a
great deal more complex.
>With a simple text format, the only kind of escaping you need is one
for " 
>(\"). That's much easier than adding support for HTML character
codes. 
>
>If you use libxml/expat, you likely will not have problems (they are 
>fairly well tested), but for those suggesting you can simply write
your 
>own basic parser, you're opening up a can of worms. If you do some 
>Googling for "libxml exploit," you'll see that XML is no stranger to
exploits and parsing bugs.
>Why introduce these problems into IRC? 
>
>Also another security and general issue associated with multi-sends.
I 
>don't see anywhere the draft mentioning how paths should be handled.
In 
>the samples, they all use "/path" notation. Well that's fine for the 
>*nix world, but on Windows that's no good. But lets look at the 
>opposite. If I do <name>C:\dir\file.txt</name> How should a linux 
>client deal with that? But, lets consider the dangers of allowing 
>paths. <name>C:\windows\system32 \my.dll</name>. Something like that 
>would apparently be allowed using the multi file send system. That 
>seems horribly dangerous to me. Personally, I again don't see the
need 
>to specify path information. As someone else said, if that's what you

>want, there are tons of compression programs out there that can
maintain path information.
>
>> Somebody else brought up the possibility of writing binary data at 
>> the beginning of the file.  I'm not so sure about that idea.  Given

>> the skepticism thats already out there concerning DCC2's security,
an 
>> open XML format that is easily readable by anyone is probably 
>> preferable.  People are more comfortable with something when it is
not obscured.
>
>I still say a basic text format is best. Someone said my suggestion
was 
>no good because it doesn't allow meta data, so? Expand it so it can!
>FILE <ID> "<FILE.EXT>" "<DESC>" <SIZE> <CRC> "<META DATA>"
>FILE 1 "file.txt" "My fun file" 123 12341234 "Permissions=700 
>Createtime=1234567890 Owner=joe"
>
>That to me is much easier to parse than an XML file.
>
>-- codemastr
>
>> ----- Original Message -----
>> From: "Phoenix Fyrestar" <miyako_houou at comcast.net>
>> To: "DCC2 Working Group List" <dcc2 at dcc2.org>
>> Sent: Monday, April 26, 2004 7:23 PM
>> Subject: Re: [dcc2] Multi file sends
>> 
>> 
>> > Yeah, that was the point I was trying to make, though I think you

>> > made it better than I did.
>> > At the end of the day, XML is not signifigantly more difficult to

>> > parse
>> than
>> > any other effective scheme, and we get the benefit of having an 
>> > open and human-readable standard that is well understdood by many

>> > applications with much library support.
>> > While it is always a good idea to consider alternate
possiblities, 
>> > I think that spending too much time on comming up with another
way 
>> > may lead to re-inventing the wheel so to speak.
>> >
>> > On Monday 26 April 2004 05:55 pm, Riley White wrote:
>> > > On Apr 26, 2004, at 3:44 PM, Phoenix Fyrestar wrote:
>> > > > I personally think that using XML is one of the better
possible 
>> > > > solutions.
>> > > > While I understand the reluctance to do this because it would

>> > > > require an XML parser, I think that any good solution would
end 
>> > > > up comming back to something XML-like anyway.
>> > >
>> > > I honestly don't understand why XML could be considered a bad 
>> > > thing here. Some sort of format is going to have to be defined,

>> > > and why not XML? For those of us that don't want to link to XML

>> > > libraries, we're really only dealing with one specific format
of 
>> > > data so it can be manually parsed just like any other solution 
>> > > will have to be. For those of us that don't mind using XML 
>> > > libraries, we have that choice. Manual parsing of XML
conforming 
>> > > to a known schema may be a little more difficult than
whitespace 
>> > > delimited strings, but, speaking as somebody whose had to do it
on a couple of occasions, it's not too bad.
>> > >
>> > > --Riley
>> > >
>> > > _______________________________________________
>> > > 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
>> >
>> 
>> _______________________________________________
>> 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

_______________________________________________
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