Text 6624, 65 rader
Skriven 2013-02-19 17:04:40 av Michiel van der Vlist (2:280/5555)
     Kommentar till en text av Björn Felten (2:203/2)
Ärende: LOL!
============
Hello Björn,

On Monday February 18 2013 03:57, you wrote to mark lewis:

 ml>> in the above mentioned debate, it was finally realized that you
 ml>> could NOT apply the message body CHRS/CHARACTERSET control line

One can not have it both ways. It is either a kludge line or a control line. If
it is a control line - as mark cliams -, it is part of the header and should be
read when processing the header.

 ml>> to the header BECAUSE it was not known until /after/ the header
 ml>> was already processed...

 BF>    That makes a lot of sense to me.

Only in the context of 20 years ago when 640K was enough for everyone, clock
frequencies were measured in MHz and disk space in MBs. With todays resources,
that for the needs of Fidonet are virtually unlimited, it no longer makes
sense. Just read a bit further when harvesting the relevant information.

 BF> But how about sacrificing the last byte of the subject header (the
 BF> longest, only reducing it from 72 to 71) and there putting a byte
 BF> indicating what encoding is in the header. The preceding byte(s) must
 BF> of course be 0x00 (or we need to reserve two bytes to make sure the
 BF> archaic editors will always see a terminating 0x00 before rolling over
 BF> to the next field).

1) Won't work. It may work in the stored massage format as described in
FTS-0001, but it will fail in the packed message format as the only thing
separating the subject field from the message text is the null byte terminating
the subject field. Present software will see your character encoding byte as
the first byte of the message text. See FTS-0001 section C, paragraph 1.
"Packed Message".

2) Why create yet another backward incompatibility when the present situation
with dozens of character encoding is already messy enough? why not think
/forward compatibility/ and declare UTF-8 the default character encoding for
Fidonet?

 BF>    With 256 available char codes available, that should be enough.

nnn should be enough for everyone... where did I hear that before?

 BF> And, at the same time, maybe we could give all the different code
 BF> pages a specific registered number.

Yes we could, but why if we can simply follow the rest of the world and clean
out the mess of having to maintain dozens of codepages anf go unicode instead?

 BF>    That could prove to be a haven for all present developers -- not
 BF> having to take care of all kinds of more or less abandoned CHRS
 BF> definitions, I mean, but having an FTS document where you can get the
 BF> different code pages as a single byte.

The table of code pages will suffer the same fate as the present situation
where they are defined by tagname. It will be filled with dozens of more or
less obsolete encodings.

Get rid of the ness; go UTF-6.

Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20110320
 * Origin: http://www.vlist.org (2:280/5555)