Hey Manny!

This works. I am officially calling it abandonware so that it can now fly under the so-called "common practice" flag. :::snicker:::

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi Maurice,

On 2020-12-02 01:52:41, you wrote to Manny Common:

@MSGID: 1:153/7001 5fc6f369
Hey Manny!

This works. I am officially calling it abandonware so that it can now

fly

under the so-called "common practice" flag. :::snicker:::

I would call it broken, with only the MSGID flag...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hey Wilfred!

I would call it broken, with only the MSGID flag...

No more broken than with all the additional flags. Note that this reply contains a REPLY flag that matches your MSGID as per specs, as well as nonconforming MSGIDs that certain software generates. Also the hex part of the MSGID can be used to generate a real datetime stamp accurate to the second and is vastly more informative than any so-called fix for the obsolete MSG header's datetime stamp;

$ date --date="@$(printf "%d" 0x5fc6f369)"
Wed 02 Dec 2020 01:52:41 AM UTC

I can easily write a C routine using the strftime() function of time.h to do the exact same thing as coreutils' date is doing in the above commandline, except that I am now officially retired after abandoning the only software capable of generating fidonet pkts. However as shown below the hex part as is will expire in on;

$ date --date="@$(printf "%d" 0xffffffff)"
Sun 07 Feb 2106 06:28:15 AM UTC

Always something broken in FTN messaging which even you have admitted will never, ever get fixed. All I did was to reduce the breakage with the absolute minimum of data required to make this work, which it obviously does given your reply to the original. That is more than can be said about most of the abandonware still in use.

It appears that your MSGID carries the same information;

$ date --date="@$(printf "%d" 0x5fc76588)"
Wed 02 Dec 2020 09:59:36 AM UTC

which when compared with your obsolete MSG header's datetime stamp - 02 Dec 20
10:59:06 - is off by exactly one hour. Definetly fixable with a proper utc offset I would imagine. Too bad there isn't one in Fidonet eh? ;-)

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi Maurice,

On 2020-12-02 15:41:36, you wrote to me:

@MSGID: 1:153/7001 5fc7b5b0
@REPLY: 2:280/464 5fc76588

I would call it broken, with only the MSGID flag...

No more broken than with all the additional flags. Note that this reply contains a REPLY flag that matches your MSGID as per specs, as well as nonconforming MSGIDs that certain software generates. Also the hex part

of

the MSGID can be used to generate a real datetime stamp accurate to the second and is vastly more informative than any so-called fix for the obsolete MSG header's datetime stamp;

$ date --date="@$(printf "%d" 0x5fc6f369)"
Wed 02 Dec 2020 01:52:41 AM UTC

That's a broken MSGID implementation, because it could be possible your system generates 2 (or more) messages in the same second (maybe automated ones). In that case there would be 2 (or more) different messages with the same MSGID...

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

Illegal characters without a CHRS: kludge!

(And yes I know mine isn't correct ;-))

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hey Wilfred!

$ date --date="@$(printf "%d" 0x5fc6f369)"
Wed 02 Dec 2020 01:52:41 AM UTC

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

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

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

Illegal characters without a CHRS: kludge!

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

(And yes I know mine isn't correct ;-))

It doesn't matter since it does nothing. It's the 8-bit character sets, especially the so-called LATIN-1 codes, that are totally fscked up. Ignore it and there is no problem. :-)

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi Maurice,

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

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

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

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

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

Illegal characters without a CHRS: kludge!

Again it appears to be working without a useless CHRS kludge, especially

in

the case of UTF-8 as the above quote clearly demonstrates. Also with

older

16-bit DOS editors quoting UTF-8 characters works 100% which cannot be

said

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)

Hey Wilfred!

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

Do you have a reference for that? I was under the impression that dupe checking is an AREA specific thing. Do you want to check that? I'd be willing to crosspost a msg just to see what happens at your end. It will have to wait until later today as I am just about to head out the door and will be gone for a couple hours. Even retired people need to take care of 'business'.

If I were using a message editor that could and was configured
to display different charactersets.

That is doable. However I wouldn't trust the CHRS kludge for that functionality especially LATIN-1 since there is no such encoding ... errr ... at least not one acceptable to useful tools like iconv. Again this is a matter for proper universally accepted standards and not some silly broken FTN kludge. The CHRS documentation requires a wholesale edit methinks and first to get the heave-ho should be the nonexistant LATIN-1 alias.

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi Maurice,

On 2020-12-02 17:52:34, you wrote to me:

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

Do you have a reference for that?

Of course. ;)

http://ftsc.org/docs/fts-0009.001

States:

"and a serial number unique to that message on the originating system"
^^^^^^

I was under the impression that dupe checking is an AREA specific
thing.

It can be, but that is implementation dependent. I know FMail for instance keeps a system wide dupe database. Others do it by area.

Do you want to check that?

No. ;)

I'd be willing to crosspost a msg just to see what happens at your
end. It will have to wait until later today as I am just about to
head out the door and will be gone for a couple hours. Even retired people need to take care of 'business'.

Ok.


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hey Wilfred!

"and a serial number unique to that message on the originating
system"
^^^^^^

In this case the system is me and given the way it is being generated here I feel comfortable saying that it is unique for all time ... up to 2106 that is.

Anyhow I don't plan on crossposting, nevermind generating new MSGIDs for them.

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)