[dcc2] Multi file sends

Tue Apr 27 17:55:31 EDT 2004

Jeremy Iverson <jeremy at algenta.com> said:

> 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.
I support adding zlib, but not as a standard. I mean, you have the stuff to 
implement SSL, so why not a token like Compression=mechanism

So if you have the token, Compression=zlib
then you know it's compressed using zlib. If you want to speed up file 
transfers, compression is the way to do it.

-- codemastr
>  
> 
> -----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
> 

-- 