TID: FMail-lnx64 2.1.0.18-B20170815
RFC-X-No-Archive: Yes
TZUTC: 0100
CHRS: UTF-8 2
PID: GED+LNX 1.1.5-b20161221
MSGID: 2:280/464 5fc7ccf1
REPLY: 1:153/7001 5fc7c45e
Hi Maurice,

On 2020-12-02 16:44:14, you wrote to me:

 WvV>> That's a broken MSGID implementation, because it could be
 WvV>> possible your system generates 2 (or more) messages in the same
 WvV>> second (maybe automated ones).

 MK> Understood.  I noticed that way back in the 1990's and brought it up back
 MK> then.  However for a single user application such as what I am doing this
 MK> is not an issue.  Basically all I've done is to write an offline
 MK> application using a slightly modified FTN MSG format that generates it's
 MK> own MSGID so that when tossed by a regular automated tosser such as hpt
 MK> (not abandonware ... yet) there shouldn't be an issue with dupes since
 MK> there are none.  Right?

Unless your application can crosspost a single written message to multiple
other areas? They all need different MSGID's...

 MK>>> ... A Møøse once bit my sister ...

 WvV>> Illegal characters without a CHRS: kludge!

 MK> Again it appears to be working without a useless CHRS kludge, especially
in
 MK> the case of UTF-8 as the above quote clearly demonstrates.  Also with
older
 MK> 16-bit DOS editors quoting UTF-8 characters works 100% which cannot be
said
 MK> about most (all?) FTN compliant editors.

If I were using a message editor that could and was configured to display
different charactersets. It wouldn't know how to display this one, because of
the missing CHRS kludge.


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
 * Origin: FMail development HQ (2:280/464)
SEEN-BY: 1/123 18/200 90/1 105/81 120/340 123/131 124/5016 154/10
SEEN-BY: 203/0 221/0 226/30 227/114 229/101 424 426 452 664 1016 240/5832
SEEN-BY: 249/110 206 317 400 280/464 5003 288/100 292/8125 310/31
SEEN-BY: 317/3 322/757 342/200 396/45 423/120 460/58 633/280 770/1
PATH: 280/464 229/101 426