[dcc2] few thoughts

[Timo Sirainen]

I don't really like the idea of using XML. IRC clients haven't been
required to parse XML so far, so it seems pretty unnecessary
complication (and possibly extra library dependency).

In non-XML DCC2 SEND request you have set pretty strict restrictions on
what characters the filename can contain. What should be done then if
the filename contains other characters? Requiring to mangle some
filenames doesn't sound very good.

The drafts need to say something about character sets in filenames. In
XML they'd pretty much have to be converted to UTF-8 (or the whole XML
encoding be changed). Only problem is that with most operating systems
you don't know what charset is being used. If you just put the filename
in the XML as-is and the filename contains non-UTF8 data, parsing the
whole document might fail. Solutions that I can think of are:

a) require user giving filesystem character set
b) mangle filenames until they are fully UTF8
c) drop XML, or use "invalid XML" that allows encoding="unknown"

I don't think users would like a) or b) very much. Also different files
might have different charsets (I have many UTF8 and ISO-8859-1 files).
And the file description might want to be given with different charset
than the filename.

Maybe replace CRC32 checksums with MD5 or SHA1? Or at least support
them.

NAT traversal chapter in the draft doesn't seem to have anything to do
with NAT traversal? And how would client know if it's behind NAT to
advertise the NAT token? Requiring user to tell that doesn't really help
making DCC user-friendly. Checking local IP against what IRC server
tells might work pretty well, assuming the user isn't behind a two-way
address mapping NAT (or whatever it was really called) which wouldn't
need the NAT-token. Did all IRC servers even tell user his address?

And a feature request: Adding support for optionally transfering some
metadata for files would be nice. File permissions, owner and group info
at first. Later when OSes actually start supporting and using
user-attachable metadata those could even be transferred by default. PGP
signature for the file with automatic checking would be one such thing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://six.pairlist.net/pipermail/dcc2/attachments/20040426/f051f589/PGP.bin