Hey Andrew!

Just a little something to brighten your day and perhaps spark much needed participation in this particular echoarea, or whatever the kids are calling it these days.

proposed DateTime = a string 19 bytes long.
Format = "YYYY-MM-DD hh:mm:ss" where,
YYYY = four digit year
MM = two digit month ranging from 01 to 12
DD = two digit day ranging from 01 to 31
hh = two digit hour ranging from 00 to 23
mm = two digit minute ranging from 00 to 59
ss = two digit second ranging from 00 to 59

Since there is no room for the UTC offset DateTime should be set to UTC in order to avoid confusion. This format will ensure that the packed message is exactly the same byte length as specified in fts-0001.016 not counting the ASCII null charater that terminates the string as per packed MSG header specification for all header strings (eg To, From, subj, etc).

Life is good,
Maurice

... Swa monige beoþ men ofer eorþan, swa beoþ modgeþoncas.
There are as many opinions as there are people on earth.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

18 Dec 20 06:36, you wrote to me:

Just a little something to brighten your day and perhaps spark much
needed participation in this particular echoarea, or whatever the kids
are calling it these days.

proposed DateTime = a string 19 bytes long.
Format = "YYYY-MM-DD hh:mm:ss" where,
YYYY = four digit year
MM = two digit month ranging from 01
to 12
DD = two digit day ranging from 01 to
31
hh = two digit hour ranging from 00 to
23
mm = two digit minute ranging from 00
to 59
ss = two digit second ranging from 00
to 59

Since there is no room for the UTC offset DateTime should be set to
UTC in order to avoid confusion. This format will ensure that the
packed message is exactly the same byte length as specified in fts-0001.016 not counting the ASCII null charater that terminates the string as per packed MSG header specification for all header strings
(eg To, From, subj, etc).

While I can see the merits of your proposal, it currently is not implemented in any FidoNet compatible software. Current FidoNet software that parses the DateTime field would need to be updated to support this new format. For compatibility with existing FidoNet software, implementations would need to be able to parse this format, or the 2 other existing formats (FTS-1 or SeaDog.) In addition, to avoid breaking existing software, this format should not be used in packets without confirming that the software on the other end can process it correctly.

Given that many software packages used in FidoNet have been abandoned, had their source code lost, or the authors are no longer available, it is not likely that this format will succeed.

Your best shot is to convince the maintainers of existing packages which are still being developed, such as HPT, D'Bridge, MBSEBBS, Synchronet, and Mystic of the merits of your proposal, and get it implemented. Several of these packages are open source, so you could conceivably implement it yourself and submit patches to the maintainers for consideration.

As for the use of UTC in packet headers, again you are fighting an uphill battle. The TZUTC kludge line was created because the .MSG and .PKT headers had no provision for timezone offsets.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hey Andrew!

While I can see the merits of your proposal, it currently is not implemented in any FidoNet compatible software.

Understood. That is why if it already hasn't rendered the software as useless it soon enough will. The two digit year has a cycle of expiration built right in. It has been witnessed before in this very echoarea although I am sure few people understood what they were witnessing given the lack of a proper fix. I recall pkzip causing serious problems way back when over the two digit year issue as well as the y2k bug.

Given that many software packages used in FidoNet have been
abandoned, had their source code lost, or the authors are no
longer available, it is not likely that this format will succeed.

I would have thought the opposite which is why I am currently proposing it as a fix for something that should have been fixed when it first reared it's head. The latest two digit year rollover was just last year sometime in 2019. It is destined to repeat itself many, many more times given the planned obsolesence of many programmers and software companies.

Your best shot is to convince the maintainers of existing
packages which are still being developed, such as HPT, D'Bridge,
MBSEBBS, Synchronet, and Mystic of the merits of your proposal,
and get it implemented.

Sounds like a plan. If not this echoarea then where? I would have thought this is the perfect echoarea for proposing changes to obviously flawed FTN standards rather then to chase down individuals who more than likely already know about this issue.

submit patches to the maintainers for consideration.

No thank you. I grow my own and haven't used the two digit year for anything that matters including echomail. Currently I am using a 64-bit floating point based date application to calculate proper datetime stamps including the two digit year included with this particular MSG. The expirey date for it is Wed Dec 31 23:59:59 UTC 2147485547. Try fitting that into 19 bytes. ;-)

The TZUTC kludge line was created because the .MSG and .PKT
headers had no provision for timezone offsets.

We'll see how this goes before ripping that 'fix' apart. :::evil grin:::

Life is good,
Maurice

... Ich habe Eichhörnchen in meiner Hose!
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Re: alternative DateTime (ref: fts-0001.016)
By: Maurice Kinal to Andrew Leary on Fri Dec 18 2020 05:59 pm

Hey Andrew!

While I can see the merits of your proposal, it currently is not implemented in any FidoNet compatible software.

Understood. That is why if it already hasn't rendered the software as useless it soon enough will. The two digit year has a cycle of expiration built right in. It has been witnessed before in this very echoarea although I am sure few people understood what they were witnessing given the lack of a proper fix. I recall pkzip causing serious problems way back when over the two digit year issue as well as the y2k bug.

Sure, but FidoNet is a legacy protocol that must (what I've observed) be enhanced only in backwards-compatible means. So if you want to add, say, the full year of authorship to to messages in a backwards compatible way, a new control paragraph (kludge line) would be the way to go.

And if you're going to introduce another date/time format, best to use existing standards (e.g. RFC822 or ISO-8601) rather than introducing yet another format.

Your best shot is to convince the maintainers of existing
packages which are still being developed, such as HPT, D'Bridge, MBSEBBS, Synchronet, and Mystic of the merits of your proposal,
and get it implemented.

Sounds like a plan. If not this echoarea then where? I would have thought this is the perfect echoarea for proposing changes to obviously flawed FTN standards rather then to chase down individuals who more than likely already know about this issue.

This seems to me to be the right place to discuss.

Hello Andrew,

On Fri Dec 18 2020 11:32:54, Andrew Leary wrote to Maurice Kinal:

Hello Maurice!

18 Dec 20 06:36, you wrote to me:

Just a little something to brighten your day and perhaps spark
much needed participation in this particular echoarea, or
whatever the kids are calling it these days.

proposed DateTime = a string 19 bytes long.
Format = "YYYY-MM-DD hh:mm:ss" where,
YYYY = four digit year
MM = two digit month ranging from
01 to 12
DD = two digit day ranging from
01 to 31
hh = two digit hour ranging from
00 to 23
mm = two digit minute ranging
from 00 to 59
ss = two digit second ranging
from 00 to 59

Since there is no room for the UTC offset DateTime should be set
to UTC in order to avoid confusion. This format will ensure that
the packed message is exactly the same byte length as specified
in fts-0001.016 not counting the ASCII null charater that
terminates the string as per packed MSG header specification for
all header strings (eg To, From, subj, etc).

While I can see the merits of your proposal, it currently is not implemented in any FidoNet compatible software. Current FidoNet
software that parses the DateTime field would need to be updated to support this new format. For compatibility with existing FidoNet software, implementations would need to be able to parse this format,
or the 2 other existing formats (FTS-1 or SeaDog.) In addition, to
avoid breaking existing software, this format should not be used in packets without confirming that the software on the other end can
process it correctly.

Given that many software packages used in FidoNet have been abandoned,
had their source code lost, or the authors are no longer available, it
is not likely that this format will succeed.

Your best shot is to convince the maintainers of existing packages
which are still being developed, such as HPT, D'Bridge, MBSEBBS, Synchronet, and Mystic of the merits of your proposal, and get it implemented. Several of these packages are open source, so you could conceivably implement it yourself and submit patches to the
maintainers for consideration.

As for the use of UTC in packet headers, again you are fighting an
uphill battle. The TZUTC kludge line was created because the .MSG and .PKT headers had no provision for timezone offsets.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

THIS

This is exactly why Fidonet is dying at a rapid rate.

While the Husky project, Synchronet, Mystic, D'Bridge, MBSE continue to be developed, they are limited in what they can actually do (to be honest, some have already just gave up on "fidonet standards" and moved on to supporting way more things than just FTN) in order to keep this backwards compatibility that systems 30 years ago used.

Most of said systems that use/used 30 year old software are gone, if not leaving shortly. If we actually want this to continue, we should probably at some point leave said backwards compatibility systems behind and move forward. In my recent experience, I've come across two types:

1) Old school people coming back around to see where the "scene" is at. These seem to be the ones that once they see people are still using garbage like, oh lemme come up with an example, IREX, they don't last long.

2) New generation looking for the old school retro BBS thing. These even include college kids looking for some retro computing stuff. The only thing we seem to be able to show them is that not much has changed, and we can't evolve. So they exit stage left also.

This is why we're not growing, but rather declining.

We still have quite a few people developing for this technology. And a couple willing to take things further. For fuck's sake why are there people trying to hold them back every chance they get? People calling out software for being "buggy" just because it's newly updated and they don't use it. THAT'S HOW ADVANCEMENT WORKS! How about try it, test it, and give feedback on what can be improved!

It's seriously sad as fuck around here. I've taken long hiatuses from posting just because I knew arguments would ensue I didn't give a shit to be involved with. I'm a big fan of currently developed software, and have multiple systems (some not on Fidonet) running here to test software and enjoy the fact that my hobby when I was 15 years old (am now going to be 40 next month - and I don't care to hear how long any of you have been here) is still progressing (albeit at an alarmingly slow pace, pretty much due to the FTSC and or a select few people that apparantly want Fidonet to just die already).

If you want Fidonet to die, or you don't care any more, or you want to run down every new idea (even if it's actual code!) brought forth.. turn your system off or redirect your IP addresses elsewhere.. We could probably gain more interest and enthusiasm without you.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- GoldED+/LNX 1.1.5-b20181215
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hey Rob!

FidoNet is a legacy protocol that must (what I've observed) be
enhanced only in backwards-compatible means.

I am sorry but I am forced to call BS on the above and will cite the common usage of the "Type 2.2" pktheader scam as evidence to support my BS call. On the surface it appears that it succeeded in supplanting the orignal and documented pktheader as spelled out in fts-0001.016 which by default is the defacto standard regarding this issue. If backwards compatibilty is the true goal then why isn't the pktheader in fts-0001.016 not supported by ALL concerned especially the echomail movers? I am only aware of one that can still support it ... or at least could the last time I checked. Does your software support it?

On the surface it appears that a coup took place by what I can only describe as backstabbing weasels given the lack of evidence to support such a shift in so-called standards.

This seems to me to be the right place to discuss.

I agree but am willing to accept any ruling Andrew may make regarding this particular issue. Having said that I truly believe that I am 100% on topic for this echoarea and as the nodelisted sysop of 1:153/7001 I have every right to post here regarding the FTSC.

Life is good,
Maurice

... Nafað ænig mann freonda to fela.
No one can have too many friends.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Re: alternative DateTime (ref: fts-0001.016)
By: Maurice Kinal to Rob Swindell on Sat Dec 19 2020 01:39 am

Hey Rob!

FidoNet is a legacy protocol that must (what I've observed) be
enhanced only in backwards-compatible means.

I am sorry but I am forced to call BS on the above and will cite the common usage of the "Type 2.2" pktheader scam as evidence to support my BS call.

I find it interesting you would cause the type 2.2 packet header a "scam".

On the surface it appears that it succeeded in supplanting the orignal and documented pktheader as spelled out in fts-0001.016 which by default is the defacto standard regarding this issue. If backwards compatibilty is the true goal then why isn't the pktheader in fts-0001.016 not supported by ALL concerned especially the echomail movers?

Isn't it?

I am only aware of one that can
still support it ... or at least could the last time I checked. Does your software support it?

Indeed, it does. And type 2.2 packet headers are backward compatible with type 2.0/stone-age headers, so it's pretty easy to autodetect the type and support all the type-2 variants of incoming packets.

On the surface it appears that a coup took place by what I can only describe as backstabbing weasels given the lack of evidence to support such a shift in so-called standards.

Whoa there skippy! What on Earth are you talking about?

Good ${greeting_time}, Maurice!

18 Dec 2020 06:36:54, you wrote to Andrew Leary:

proposed DateTime = a string 19 bytes long.
Format = "YYYY-MM-DD hh:mm:ss" where,
YYYY = four digit year
MM = two digit month ranging from 01 to 12
DD = two digit day ranging from 01 to 31
hh = two digit hour ranging from 00 to 23
mm = two digit minute ranging from 00 to 59
ss = two digit second ranging from 00 to 59
Since there is no room for the UTC offset DateTime should be set to
UTC in order to avoid confusion. This format will ensure that the
packed message is exactly the same byte length as specified in fts-0001.016 not counting the ASCII null charater that terminates the string as per packed MSG header specification for all header strings
(eg To, From, subj, etc).

I've only one question: how would the software distinguish that from older (legacy) date format?

Even if we want everyone migrating to the new software, there should be some transition period, while we _must_ (as in FTA-1006) maintain compatibility. Given that, here's my proposal.

The "Date:" kludge containing the date and time in RFC-3339 format with one variation - allow the space between the time and UTC offset. The "datestr" format for that would be "%F %T %:z" (try `date '+%F %T %:z'`).

Rules:
0. The "Date:" kludge _must_ contain valid time in either "%F %T %:z" or "%F %T%:z" format.
1. Once the "Date:" kludge is present in a received message, the compatible software (that's aware of the "Date:" kludge) _must_ use the time from the kludge.
2. When composing a message, the compatible software _must_ fill the "Date:" kludge and _should_ fill the legacy header with the valid time (considering precision limitation) or it _may_ fill the legacy header with all zero bytes.

This would allow us to get rid of ancient software without breakind almost everything.

Also, the example of the "Date:" kludge can be found in this my message :-)


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... god@universe:~ # cvs up && make world
--- /bin/vi
* Origin: ::1 (2:5020/545)

Re: alternative DateTime (ref: fts-0001.016)
By: Alexey Vissarionov to Maurice Kinal on Sat Dec 19 2020 06:48 am

Good ${greeting_time}, Maurice!

18 Dec 2020 06:36:54, you wrote to Andrew Leary:

proposed DateTime = a string 19 bytes long.
Format = "YYYY-MM-DD hh:mm:ss" where,
YYYY = four digit year
MM = two digit month ranging from 01 to 12
DD = two digit day ranging from 01 to 31
hh = two digit hour ranging from 00 to 23
mm = two digit minute ranging from 00 to 59
ss = two digit second ranging from 00 to 59
Since there is no room for the UTC offset DateTime should be set to
UTC in order to avoid confusion. This format will ensure that the packed message is exactly the same byte length as specified in fts-0001.016 not counting the ASCII null charater that terminates the string as per packed MSG header specification for all header strings (eg To, From, subj, etc).

I've only one question: how would the software distinguish that from older (legacy) date format?

That may be possible for *newer* software to make sense of multiple formats, including a new one, but there's option for *older* software to recognize a new format. There in lies the rub.

Even if we want everyone migrating to the new software, there should be some transition period, while we _must_ (as in FTA-1006) maintain compatibility.

I think that transition period, for FidoNet, is: forever. :-)

Given that, here's my proposal.

The "Date:" kludge containing the date and time in RFC-3339 format with one variation - allow the space between the time and UTC offset. The "datestr" format for that would be "%F %T %:z" (try `date '+%F %T %:z'`).

Rules:
0. The "Date:" kludge _must_ contain valid time in either "%F %T %:z" or "%F %T%:z" format.
1. Once the "Date:" kludge is present in a received message, the compatible software (that's aware of the "Date:" kludge) _must_ use the time from the kludge.
2. When composing a message, the compatible software _must_ fill the "Date:" kludge and _should_ fill the legacy header with the valid time (considering precision limitation) or it _may_ fill the legacy header with all zero bytes.

"all zero bytes" is not a backwards compatible date value, most likely causing the packet to be discarded as corrupted or just really old, by existing or old FidoNet software. I would mandate that the FTS-1 date field be set as defined in FTS-1.

This would allow us to get rid of ancient software without breakind almost everything.

Also, the example of the "Date:" kludge can be found in this my message :-)

I didn't see a "Date:" kludge in your message (I looked).

Re: alternative DateTime (ref: fts-0001.016)
By: Rob Swindell to Alexey Vissarionov on Fri Dec 18 2020 09:14 pm

That may be possible for *newer* software to make sense of multiple formats, including a new one, but there's option for *older* software to recognize a new format. There in lies the rub.

Of course, I meant to write "there *no* option for *older* software" ...

Hey Rob!

I find it interesting you would cause the type 2.2 packet header
a "scam".

I got burned by it way back when and almost quit. However the fighting spirit later got awoken in me and it sparked a bout of backwards engineering which is still part of the routine(s) being deployed in this neck of the woods. Anyhow I will still cite it as evidence that not all is as it seems in Fidonet wrt backwards compatibilty/standards/whatever.

Are you defending it?

isn't the pktheader in fts-0001.016 not supported by ALL
concerned especially the echomail movers?

Isn't it?

Nope. Like I said previously I only am aware of one and it's been awhile since I tested it there so even that one may not support it anymore. He is still moving mail and it wouldn't be too hard to test it out if needed.

And type 2.2 packet headers are backward compatible with type 2.0/stone-age headers, so it's pretty easy to autodetect the
type and support all the type-2 variants of incoming packets.

Really? Have you actually tested that? Or is this some type of blind faith statement on your part? Also, while I am at it, I only found one that could handle Type 2+ pktheaders and it wasn't the same one that could do type 2 pktheaders. Most are 2.2 only and don't even know it.

Whoa there skippy! What on Earth are you talking about?

:-) Nothing you need to worry about ... I think.

Life is good,
Maurice

... Mon sceal... gebidan þæs he gebædan ne mæg.
One must wait for what cannot be hastened.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Alexey!

how would the software distinguish that from older (legacy) date
format?

As proposed it wouldn't. I thought I'd leave that part open to discussion and just go for the gold. This is something that should have happened just over 20 years ago or at least in 2002 when the opportunity presented itself when the 2 digit year was declared obsolete by those in the know.

To be honest I am not aware of anyone who is using abandonware these days so I am not convinced this is really an issue if the much needed change were to actually take place. Do you? It seems to me that this would be a welcome addition all things considered but I do understand it would take some time to impliment. For the software being deployed on this node it is a nobrainer and I could have it up and running in no time. How about you?

The "Date:" kludge containing the date and time in RFC-3339
format with one variation - allow the space between the time and
UTC offset. The "datestr" format for that would be "%F %T %:z"

I was adding it as a kludge except with this format; "%F %T %z" which is one byte less than your datestr and does indeed work with every dating routine I threw it at. All use the strftime() function which is available to c, c++, and every half-decent scripting language I can find (perl, python, etc). Even gawk has the strftime() function available to it. This makes it extremely portable to every OS I can think of including Windows.

(try `date '+%F %T %:z'`).

-={ date '+%F %T %:z' }=-
2020-12-19 05:49:41 +00:00

I am partial to;

-={ date '+%F %T %z' }=-
2020-12-19 05:51:23 +0000

which saves a byte and is just as useful. I'll put it as a kludge in my followup msg. Please stay tuned.

Life is good,
Maurice

... [Læt] þine lareowas leofe in mode þa þec geornast to gode trymmen.
Hold your teachers dear in mind, who eagerly urge you to good.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Alexey!

(try `date '+%F %T %:z'`)

See corresponding RFC-3339 kludge 'hidden' in this reply.

Life is good,
Maurice

... Gold geriseþ on guman sweorde... sinc on cwene.
Gold is fitting for a man's sword, precious things for a woman.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Re: alternative DateTime (ref: fts-0001.016)
By: Maurice Kinal to Rob Swindell on Sat Dec 19 2020 04:59 am

Hey Rob!

I find it interesting you would cause the type 2.2 packet header
a "scam".

I got burned by it way back when and almost quit. However the fighting spirit later got awoken in me and it sparked a bout of backwards engineering which is still part of the routine(s) being deployed in this neck of the woods. Anyhow I will still cite it as evidence that not all is as it seems in Fidonet wrt backwards compatibilty/standards/whatever.

Are you defending it?

I'm not defending anything, just sharing my observations on how FidoNet (collectively) is vehemently opposed to anything that is not interoperable with FidoNet software from the 80's or 90's.

isn't the pktheader in fts-0001.016 not supported by ALL
concerned especially the echomail movers?

Isn't it?

Nope. Like I said previously I only am aware of one and it's been awhile since I tested it there so even that one may not support it anymore. He is still moving mail and it wouldn't be too hard to test it out if needed.

And type 2.2 packet headers are backward compatible with type 2.0/stone-age headers, so it's pretty easy to autodetect the
type and support all the type-2 variants of incoming packets.

Really?

Really. And it's been that way since about 1992.

Have you actually tested that?

Of course.

Or is this some type of blind faith statement on your part?

I don't operate that way.

Also, while I am at it, I only found one that could
handle Type 2+ pktheaders and it wasn't the same one that could do type 2 pktheaders. Most are 2.2 only and don't even know it.

"Most" what? SBBSecho defaults to exporting type 2+ packets and can import and export type 2.0, 2e, 2+ and 2.2. Type 2.2 packets are actually pretty rare from what I've observed.
http://wiki.synchro.net/ref:fidonet_packets

Whoa there skippy! What on Earth are you talking about?

:-) Nothing you need to worry about ... I think.

Sounds like it. :-)

Hello Nicholas!

18 Dec 20 18:56, you wrote to me:

THIS
This is exactly why Fidonet is dying at a rapid rate.

It has long been a principle of FidoNet that new innovations be implemented in a backwards compatible way.

We still have quite a few people developing for this technology. And a couple willing to take things further. For fuck's sake why are there people trying to hold them back every chance they get? People calling
out software for being "buggy" just because it's newly updated and
they don't use it. THAT'S HOW ADVANCEMENT WORKS! How about try it,
test it, and give feedback on what can be improved!

I have tried most of the available packages at one time or another.

It's seriously sad as fuck around here. I've taken long hiatuses from posting just because I knew arguments would ensue I didn't give a shit
to be involved with. I'm a big fan of currently developed software,
and have multiple systems (some not on Fidonet) running here to test software and enjoy the fact that my hobby when I was 15 years old (am
now going to be 40 next month - and I don't care to hear how long any
of you have been here) is still progressing (albeit at an alarmingly
slow pace, pretty much due to the FTSC and or a select few people that apparantly want Fidonet to just die already).

So you are advocating changing things without regard for maintaining compatibility with existing software?

If you want Fidonet to die, or you don't care any more, or you want to
run down every new idea (even if it's actual code!) brought forth..
turn your system off or redirect your IP addresses elsewhere.. We
could probably gain more interest and enthusiasm without you.

I personally welcome the discussion that Maurice started, and Alexey has now joined in on. In fact, I am giving serious consideration to implementing some form of this in MBSE.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Alexey!

19 Dec 20 06:48, you wrote to Maurice Kinal:

The "Date:" kludge containing the date and time in RFC-3339 format
with one variation - allow the space between the time and UTC offset.
The "datestr" format for that would be "%F %T %:z" (try `date '+%F %T %:z'`).

Rules:
0. The "Date:" kludge _must_ contain valid time in either "%F %T %:z"
or "%F %T%:z" format. 1. Once the "Date:" kludge is present in a
received message, the compatible software (that's aware of the "Date:" kludge) _must_ use the time from the kludge. 2. When composing a
message, the compatible software _must_ fill the "Date:" kludge and _should_ fill the legacy header with the valid time (considering
precision limitation) or it _may_ fill the legacy header with all zero bytes.

The legacy date/time field _must_ be filled with the valid time (considering precision limitations.) If the legacy date/time field is filled with NULs, the packet may be discarded as old or invalid by existing software.

This would allow us to get rid of ancient software without breakind
almost everything.

Agreed.

Also, the example of the "Date:" kludge can be found in this my
message :-)

I didn't see it... ;-)

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Maurice!

19 Dec 20 05:29, you wrote to Alexey Vissarionov:

(try `date '+%F %T %:z'`).

-={ date '+%F %T %:z' }=-
2020-12-19 05:49:41 +00:00

I am partial to;

-={ date '+%F %T %z' }=-
2020-12-19 05:51:23 +0000

which saves a byte and is just as useful. I'll put it as a kludge in
my followup msg. Please stay tuned.

I'll second that; although the byte savings really won't matter these days.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hi, Maurice -- on Dec 19 2020 at 05:29, you wrote:

@REPLY: 2:5020/545 5fdd86aa
@MSGID: 1:153/7001 5fdd8fb6
Hey Alexey!

To be honest I am not aware of anyone who is using abandonware these
days so I am not convinced this is really an issue if the much

Here I've Squish, Max, Binkley, Irex, and a number of small utilities -- all abandonware.



Cheers... Dallas

--- timEd/NT 1.30+
* Origin: The BandMaster, Vancouver, CANADA (1:153/7715)

Hey Rob!

SBBSecho defaults to exporting type 2+ packets

Okay I had a looksee at a pktheader parser I wrote awhile back and I now see that I was confusing 2+ with 2.2 so your statement above would put SBBSecho amongst the majority. All my links support type 2+ pkts while only one supports type 2, while another can do 2.2. So from my perspective both 2 and 2.2 are equally rare.

FidoNet (collectively) is vehemently opposed to anything that is
not interoperable with FidoNet software from the 80's or 90's.

I wish I could say that them were the days but my heart wouldn't be in it. Everyone I knew from that time is no longer in the game and whatever software they were using back then has long since been abandoned even before y2k and the two digit year became real issues of concern. I am convinced that had the four digit year replaced the packed msg DateTime back in 1999 or 2002 there would have been minimal problems with it.

Life is good,
Maurice

... Monig biþ uncuþ treowgeþofta, teorað hwilum.
Many a trusted friend will prove to be unknown, will fail at times.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Andrew!

I'll second that; although the byte savings really won't matter
these days.

Excellent. I've now applied it to the kludge in this reply. However I still maintain that the "%F %T" part replace the DateTime in fts-0001. Also making it retroactive to Dec 31, 1999 would be a nice touch. :::evil grin:::

Life is good,
Maurice

... Leorna hwæthwugu æt ðam wisran, þæt þu mæge læran þone unwisran.
Learn something from the wise, so you can teach the ignorant.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Dallas!

Here I've Squish, Max, Binkley, Irex, and a number of small
utilities -- all abandonware.

Which one was/is compatible with Type 2.2 headers? It was/is your link where I noticed I could safely ship Type 2.2 pkts to. I don't recall Squish being able to successfully toss Type 2.2 pkts but I haven't used Squish in so long that I can't really say when the last time was.

Binkley was back around 1997-ish at the latest ... same with Max. I never did get Irex working on anything.

Life is good,
Maurice

... Beforan his freonde biddeþ, se þe his wædle mæneþ.
He who bemoans his poverty should seek help from his friends.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 19 Dec 20 06:48:00, Alexey Vissarionov said the following to Maurice Kinal:

Even if we want everyone migrating to the new software, there should be som transition period, while we _must_ (as in FTA-1006) maintain compatibility.

Fidonet is mostly a dead-end... its just a silly network people are mostly happy to just trade banter so long as shit works. Any changes or
improvements to established standards or practice is decades too late and a likely a waste of time. There will never be a massive software-migration and any desire to have everyone on new software will need to wait a few decades while natural-selection takes care of the stubborn ones.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Good ${greeting_time}, Maurice!

19 Dec 2020 05:29:26, you wrote to me:

I am partial to;
2020-12-19 05:51:23 +0000
which saves a byte and is just as useful.

RFC-3339 compatibility looks more important to me. And saving a byte is not something important: I can save much more by simply using KOI8-R instead of overbloated UTF-8.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: ::1 (2:5020/545)

Good ${greeting_time}, Maurice!

19 Dec 2020 09:17:26, you wrote to Andrew Leary:

@RFC-3339: 2020-12-19 09:17:26 +0000

I'll second that; although the byte savings really won't matter
these days.

Excellent. I've now applied it to the kludge in this reply.

You've violated both RFC-3339 and my proposal.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: ::1 (2:5020/545)

Good ${greeting_time}, Dallas!

19 Dec 2020 01:11:40, you wrote to Maurice Kinal:

To be honest I am not aware of anyone who is using abandonware
these days so I am not convinced this is really an issue

Here I've Squish, Max, Binkley, Irex, and a number of small
utilities -- all abandonware.

It's time to upgrade.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net
--- /bin/vi
* Origin: ::1 (2:5020/545)

Good ${greeting_time}, Nick!

19 Dec 2020 03:55:36, you wrote to me:

Even if we want everyone migrating to the new software, there should
be some transition period, while we _must_ (as in FTA-1006) maintain
compatibility.

Fidonet is mostly a dead-end... its just a silly network people are
mostly happy to just trade banter so long as shit works.

Please speak for yourself. Or at most for your part of the network, if you exactly know the situation inside.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... god@universe:~ # cvs up && make world
--- /bin/vi
* Origin: ::1 (2:5020/545)

On 19 Dec 20 13:57:00, Alexey Vissarionov said the following to Nick Andre:

Fidonet is mostly a dead-end... its just a silly network people are mostly happy to just trade banter so long as shit works.

Please speak for yourself. Or at most for your part of the network, if you exactly know the situation inside.

As a Fido developer of a product used in the back-office of two zones and as as a ZC of one of them, I believe my contributions are somewhat valid here if you are willing to listen and not act like a petulent child.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Maurice wrote (2020-12-19):

Hey Dallas!

Here I've Squish, Max, Binkley, Irex, and a number of small
utilities -- all abandonware.

Squish is open source and still works.

Which one was/is compatible with Type 2.2 headers? It was/is your link where I noticed I could safely ship Type 2.2 pkts to. I don't recall Squish being able to successfully toss Type 2.2 pkts but I haven't used Squish in so long that I can't really say when the last time was.

There is one common pkt flavour and that is the one described in FSC-0039. Every other format is just a waste of code and mostly useless. Especially the stupid flavour that tries to be compatible with and obsolete format that no software uses anymore (since 25+ years ago).

---
* Origin: (2:280/464.47)

Hello Alexey!

19 Dec 20 13:54, you wrote to Maurice Kinal:

@REPLY: 1:153/7001 5fddc526
@MSGID: 2:5020/545 5fdddbc9
@CHRS: CP866 2
@TZUTC: 0300
Good ${greeting_time}, Maurice!

19 Dec 2020 09:17:26, you wrote to Andrew Leary:

@RFC-3339: 2020-12-19 09:17:26 +0000

I'll second that; although the byte savings really won't matter
these days.

Excellent. I've now applied it to the kludge in this reply.

You've violated both RFC-3339 and my proposal.

`date --rfc-3339=seconds` should be correct.

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hey Alexey!

RFC-3339 compatibility looks more important to me.

Okay. Please find one attached to the kludge section that follows rfc-3339 to the letter and would be far more useful as a unique identifier given the nanosecond part.

I can save much more by simply using KOI8-R instead of overbloated UTF-8.

Neither of which has anything to do with rfc-3339 given all the characters are ascii (7-bit) as well as being universally accepted given the lack of alpha characters.

For the record, none of this has anything to do with my original proposal other than the proposed DateTime also contains no alpha characters and fits perfectly into the specified field in fts-0001.016.

Life is good,
Maurice

... Blind byþ bam eagum se þe breostum ne starat.
He is blind in both eyes who does not look with the heart.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Alexey!

You've violated both RFC-3339 and my proposal.

I lied - one more for the road. The attached one follows rfc-3339 to the letter. I am not convinced that your proposal is not in violation of rfc-3339 given the space between %T and %:z.

Life is good,
Maurice

... Wat se þe cunnað hu sliþen bið sorg to geferan.
He who has experienced it knows how cruel a companion sorrow is.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Oli!

There is one common pkt flavour and that is the one described in
FSC-0039.

How does that apply to the topic onhand? From this angle it appears to muddy the waters even more wrt DateTime which has absolutely nothing to do with pkt headers.

Every other format is just a waste of code and mostly useless.
Especially the stupid flavour that tries to be compatible with
and obsolete format that no software uses anymore (since 25+
years ago).

Sure. Looks like more evidence to support my claim that everyone is in violation of FTN standards, whatever that may turn out to actually mean. You are adding fuel to the fire methinks.

Life is good,
Maurice

... Wel bið þam eorle þe him on innan hafað... rume heortan.
Well shall it be for the man who has within him a generous heart.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Here I've Squish, Max, Binkley, Irex, and a number of small utilities -- all abandonware.

I don't know about the others, but the Squish source code has been freely available for decades -- to me that does not count as abandonware. No more so than e.g. linux...



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Re: alternative DateTime (ref: fts-0001.016)
By: Maurice Kinal to Rob Swindell on Sat Dec 19 2020 09:02 am

Hey Rob!

SBBSecho defaults to exporting type 2+ packets

Okay I had a looksee at a pktheader parser I wrote awhile back and I now see that I was confusing 2+ with 2.2 so your statement above would put SBBSecho amongst the majority.

Earlier you stated "Most are 2.2 only and don't even know it.", so even allowing that you confused 2+ with 2.2, that's still not true of SBBSecho.

All my links support type 2+ pkts while only one
supports type 2, while another can do 2.2. So from my perspective both 2 and 2.2 are equally rare.

The term "support" and "do" here are rather vague: those terms could refer to the production of packets of a particular type, the consumption of packets of a particular type, or a combination.

FidoNet (collectively) is vehemently opposed to anything that is
not interoperable with FidoNet software from the 80's or 90's.

I wish I could say that them were the days but my heart wouldn't be in it. Everyone I knew from that time is no longer in the game and whatever software they were using back then has long since been abandoned even before y2k and the two digit year became real issues of concern. I am convinced that had the four digit year replaced the packed msg DateTime back in 1999 or 2002 there would have been minimal problems with it.

<shrugs> If a new date/time format can be introduced in a backward-compatible manner, that's how it should be done, IMHO. And FidoNet should use an existing standard this time, stop making up new (badly defined) ones.

Hi, Maurice -- on Dec 19 2020 at 09:34, you wrote:

Which one was/is compatible with Type 2.2 headers? It was/is your
link where I noticed I could safely ship Type 2.2 pkts to. I don't

I believe so, but there's nothing in the docs to indicate anything about pkt type. :-(

Binkley was back around 1997-ish at the latest ... same with Max. I
never did get Irex working on anything.

Irex can be a real pain to get running, but it seems very stable (here) once it does work!


Cheers... Dallas

--- timEd/NT 1.30+
* Origin: The BandMaster, Vancouver, CANADA (1:153/7715)

Hi, Alexey -- on Dec 19 2020 at 13:55, you wrote:

It's time to upgrade.

To what? It would take a LOT of work to change my entire system over - and gain me very little!

Cheers... Dallas

--- timEd/NT 1.30+
* Origin: The BandMaster, Vancouver, CANADA (1:153/7715)

Hi, Oli -- on Dec 19 2020 at 16:37, you wrote:

Squish is open source and still works.

I didn't realize it was open source - Max isn't.




Cheers... Dallas

--- timEd/NT 1.30+
* Origin: The BandMaster, Vancouver, CANADA (1:153/7715)

Hi, Björn -- on Dec 19 2020 at 20:32, you wrote:

I don't know about the others, but the Squish source code has
been freely available for decades -- to me that does not count as abandonware. No more so than e.g. linux...

Yes, as I commented to someone else, I wasn't aware that it was available. Thanks.


Cheers... Dallas

--- timEd/NT 1.30+
* Origin: The BandMaster, Vancouver, CANADA (1:153/7715)

Hey Rob!

If a new date/time format can be introduced in a
backward-compatible manner, that's how it should be done, IMHO.

That is exactly what my proposal attempts to do. It works within the confines of an already existing string without modification of the structure of the well defined header.

And FidoNet should use an existing standard this time, stop
making up new (badly defined) ones.

It isn't badly defined. If you would prefer that strftime-speak was used instead then "%F %T" could replace all the text that spells out each element found in the DateTime definition in fts-0001.016. Spelling it ALL out makes it far more "backwards compatible" in 1995 terms. How much more backwards does one need to go?

Most importantly the four digit year takes care of the much needed bug fix that two digit years are the direct cause of. In my particular case the horror would happen starting on January 1, 2069 which causes a rollback to January 1, 1969.

-={ date --date="01 Jan 69 00:00:00" }=-
Wed 01 Jan 1969 12:00:00 AM UTC

whereas;

-={ date --date="2069-01-01 00:00:00" }=-
Tue 01 Jan 2069 12:00:00 AM UTC

Big difference and it should be noted that this carries on right through 2099. On other systems it is even worse and the rollovers are reported to be on 20 year cycles, some even less.

For the record today's date in 2120 produces;

-={ date --date="19 Dec 20 20:59:37" }=-
Sat 19 Dec 2020 08:59:37 PM UTC

as opposed to;

-={ date --date="2120-12-19 20:59:37" }=-
Thu 19 Dec 2120 08:59:37 PM UTC

Note the different days with the four digit year producing the accurate output ... barring any catastrophic even happening that alters the orbit and rotation of the earth as we currently understand it.

Life is good,
Maurice

... Ear byþ egle eorla gehwylcun.
The grave is a horror to every man.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Re: alternative DateTime (ref: fts-0001.016)
By: Dallas Hinton to Oli on Sat Dec 19 2020 12:34 pm

Hi, Oli -- on Dec 19 2020 at 16:37, you wrote:

Squish is open source and still works.

I didn't realize it was open source - Max isn't.

Maximus was open sourced as well: github.com/sdudley/maximus

Re: alternative DateTime (ref: fts-0001.016)
By: Maurice Kinal to Rob Swindell on Sat Dec 19 2020 08:59 pm

Hey Rob!

If a new date/time format can be introduced in a
backward-compatible manner, that's how it should be done, IMHO.

That is exactly what my proposal attempts to do. It works within the confines of an already existing string without modification of the structure of the well defined header.

Your proposal is not backwards compatible.

And FidoNet should use an existing standard this time, stop
making up new (badly defined) ones.

It isn't badly defined.

I did not mean to imply I was referring to your proposal - I was not. I was referring to the badly defined specs published by the FTSC over the past 30+ years.

Hey Dallas!

Which one was/is compatible with Type 2.2 headers? It was/is
your link where I noticed I could safely ship Type 2.2 pkts to.

I believe so, but there's nothing in the docs to indicate
anything about pkt type. :-(

It doesn't surprise me any.

Irex can be a real pain to get running, but it seems very stable
(here) once it does work!

From this perspective it had issues with PST8PDT. I don't recall which, PST or PDT, was an hour out. Not really a biggie though given the issues caused by the change over twice a year. That is one reason I stick with UTC which doesn't suffer from switch over issues.

For the record the Maximus opensource was available at one time and might even still be for all I know. I did manage to successfully compile it with whatever version of gcc I had at the time but never did actually run it. I did use the opensource Squish but that was before we were linking. By the time we became links I was using all my own homegrown stuff which I am still using as we speak. Speaking of which I still have you as a link although we actually haven't exchanged anything since Alan took over. It should still work.

Life is good,
Maurice

... Hæle sceal wisfæst ond gemetlice, modes snottor.
A man should be firm in wisdom and moderate, prudent in mind.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Rob!

Your proposal is not backwards compatible.

My best guess is that any application that cannot handle the four digit year deserves to die a horrible death if it hasn't already. My proposal would have worked just as well back in 1995 as it does today without any alteration.

I was referring to the badly defined specs published by the FTSC
over the past 30+ years.

If so then perhaps there should be more proposals such as mine in order to correct the wrongs. I have plans on continuing depending on the outcome of this particular proposal. How about you?

Too bad it didn't happen 20 years ago when it *should* have but it has to start somewhere and near as I can figure I am doing the exact right thing. If you can come up with something better I am all ears and am more than willing to cede. Until then my proposal stands as is.

Life is good,
Maurice

... Gyf þu well sprece, wyrc æfter swa.
If you speak well, act accordingly.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 19 Dec 20 14:08:09, Rob Swindell said the following to Maurice Kinal:

Your proposal is not backwards compatible.

Unrelated, can you shoot me an email... nandre -at- net229 -dot- org

Had some questions for you...

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Re: alternative DateTime (ref: fts-0001.016)
By: Maurice Kinal to Rob Swindell on Sat Dec 19 2020 11:26 pm

Hey Rob!

Your proposal is not backwards compatible.

My best guess is that any application that cannot handle the four digit year deserves to die a horrible death if it hasn't already. My proposal would have worked just as well back in 1995 as it does today without any alteration.

Which is to say: it would not work at all, in a backwards compatible way.

I was referring to the badly defined specs published by the FTSC
over the past 30+ years.

If so then perhaps there should be more proposals such as mine in order to correct the wrongs. I have plans on continuing depending on the outcome of this particular proposal. How about you?

Continuing what?

Too bad it didn't happen 20 years ago when it *should* have but it has to start somewhere and near as I can figure I am doing the exact right thing. If you can come up with something better I am all ears and am more than willing to cede. Until then my proposal stands as is.

The something better is a new control paragraph which includes a complete unambiguous date/time stamp in a standard format. I'm pretty sure I stated so in my first reply to this topic.

Hey Rob!

Which is to say: it would not work at all, in a backwards
compatible way.

It is EXACTLY as backwards compatible as it needs to be, both for now as well as back in 1995 and probably earlier. Unless you can point to a currently running system, or even one back in 1968, that required a two digit year to function in order to achieve proper FTN based digital communications, then I will still maintain that the current proposal stands and is indeed TRULY backwards compatible. By you limited definition nothing is backwards compatible including 8-bit systems that require a 2 digit year for their punch card IO database.

Please feel free to fold, spindle and mutilate THAT.

Continuing what?

Living and learning.

Life is good,
Maurice

... Hwæt bið betst and wyrst? Ic ðe secge, mannes word.
What is the best and the worst thing? I tell you, man's word.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Re: alternative DateTime (ref: fts-0001.016)
By: Maurice Kinal to Rob Swindell on Sun Dec 20 2020 12:52 am

Hey Rob!

Which is to say: it would not work at all, in a backwards
compatible way.

It is EXACTLY as backwards compatible as it needs to be, both for now as well as back in 1995 and probably earlier.

I guess you don't know what "backwards compatible" means. Backwards compatible means it would continue to work with existing systems. Your proposal does not continue to work with existing systems.

Unless you can point to a currently running system, or even one back in 1968, that required a two
digit year to function in order to achieve proper FTN based digital communications,

All currently running systems using SBBSecho would reject packets that contain dates in your proposed format since the date format you propposed does not conform to the FTN specs. I suspect most other echomail programs would do the same.

then I will still maintain that the current proposal stands
and is indeed TRULY backwards compatible. By you limited definition nothing is backwards compatible including 8-bit systems that require a 2 digit year for their punch card IO database.

Its not specifically the number of digits in the year that is the problem but rather that the various numeric fields are in a different order and at different offsets within the date/time string field.

Please feel free to fold, spindle and mutilate THAT.

Is this how you normally engage in technical discussions?

Continuing what?

Living and learning.

Sure. I don't see the relevance.

Hi, Rob -- on Dec 19 2020 at 14:04, you wrote:

Maximus was open sourced as well: github.com/sdudley/maximus

Huh - learn something new every day!! Thanks!




Cheers... Dallas

--- timEd/NT 1.30+
* Origin: The BandMaster, Vancouver, CANADA (1:153/7715)

Hey Rob!

I guess you don't know what "backwards compatible" means.

I guess the same about you.

Backwards compatible means it would continue to work with
existing systems.

I swear that is known simply as compatibilty. Backwards implies the past. However in both cases it is obvious the software we're using is {,backwards} compatible given our exchanges.

I suspect most other echomail programs would do the same.

Mine as well. However mine can quicky adapt to a much needed change in order to facillitate progress especially when it concerns an obviously needed fix. Your proposal doesn't allow for a proper fix and solves nothing. Mine does and is therefore superior as well as much needed.

Is this how you normally engage in technical discussions?

I thought it was obvious that I don't normally engage in technical discussions. Regarding this one I believe I am 100% correct and you are 100% wrong.

Life is good,
Maurice

... Se forholena cræft and forhyded gold ne bið ællunga ungelice.
Concealed skill and hidden gold are not entirely unalike.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Re: alternative DateTime (ref: fts-0001.016)
By: Maurice Kinal to Rob Swindell on Sun Dec 20 2020 01:49 am

Hey Rob!

I guess you don't know what "backwards compatible" means.

I guess the same about you.

Backwards compatible means it would continue to work with
existing systems.

I swear that is known simply as compatibilty. Backwards implies the past. However in both cases it is obvious the software we're using is {,backwards} compatible given our exchanges.

Backwards compatible means enhancing/fixing functionality *without* impacting interoparability with old systems that lack the enhancement or fix.

I suspect most other echomail programs would do the same.

Mine as well. However mine can quicky adapt to a much needed change in order to facillitate progress especially when it concerns an obviously needed fix. Your proposal doesn't allow for a proper fix and solves nothing. Mine does and is therefore superior as well as much needed.

I haven't really proposed anything, but if I were, it would be a new control paragraph (kludge line) in the variable length portion of the packed-message. This would have no impact on older/existing systems and yet would allow newer systems to utilize the more precise date/time information if they wished.

Control paragraphs are how new features have been introduced into FidoNet for decades without breaking backward compatibility. This is the way.

Is this how you normally engage in technical discussions?

I thought it was obvious that I don't normally engage in technical discussions. Regarding this one I believe I am 100% correct and you are 100% wrong.

Huh. So you agree that existing FTN systems would break if the rest of the network were to switch to a new date format in packets, yet you don't consider that breaking backwards compatibility. And I'm the one that's wrong? I can't
tell if you're joking, but I hope so. :-)

Hey Rob!

Backwards compatible means enhancing/fixing functionality
*without* impacting interoparability with old systems that lack
the enhancement or fix.

Not at all cost. In this case it is the two digit year that is the source of the problem and it will continue to propogate it's embedded corruption throughout the network, including systems that have been doing the correct thing all along. The *only* true fix is to eliminate the cause which means you and I would be further ahead by helping the old systems adapt so that the desease they are spreading is finally cured. I honestly see no way around that fact. The kludge doesn't address this need.

Control paragraphs are how new features have been introduced
into FidoNet for decades without breaking backward compatibility.
This is the way.

They are at best a placebo that ignores the real issue. A proper cure is needed and has been for 20 years now. Control paragraphs do nothing to solve the real problem which is the two digit year. It *MUST* die. It is the *ONLY* way.

So you agree that existing FTN systems would break if the rest
of the network were to switch to a new date format in packets

The breakage is already there and has been for 20 years now. The proposal as it stands will effectively eliminate it and if it drags down systems with it then I would suggest it is 20 years overdue as they've been more than just a drag to the network's viability and integrity. It is the right thing to do.

I can't tell if you're joking, but I hope so. :-)

Yes and no.

Life is good,
Maurice

... Yrre oft amyrreð monnes mod þæt he ne mæg þæt riht gecnawan.
Anger often disturbs a man's mind so that he cannot see the right.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 19 Dec 20 18:39:28, Rob Swindell said the following to Maurice Kinal:

I haven't really proposed anything, but if I were, it would be a new contro paragraph (kludge line) in the variable length portion of the packed-messag This would have no impact on older/existing systems and yet would allow new systems to utilize the more precise date/time information if they wished.

I'm not a fan of kludging things to death, but this sounds more logical than outright changing something in packets, thus in my case changing tosser code that has been mostly unchanged since '89.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

On 20 Dec 20 03:14:41, Maurice Kinal said the following to Rob Swindell:

They are at best a placebo that ignores the real issue. A proper cure is needed and has been for 20 years now. Control paragraphs do nothing to sol the real problem which is the two digit year. It *MUST* die. It is the *ONLY* way.

Unfortunately its going to be difficult to draft a proposal to let something die versus something that lets systems continue to run.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Hi Maurice,

On 2020-12-20 01:49:29, you wrote to Rob Swindell:

I suspect most other echomail programs would do the same.

Mine as well. However mine can quicky adapt to a much needed change in order to facillitate progress especially when it concerns an obviously needed fix. Your proposal doesn't allow for a proper fix and solves nothing. Mine does and is therefore superior as well as much needed.

So why don't you do the experiment and "fix" your system to put this "much needed change" in your message headers, and see how big your network becomes/remains? (Without everyone else doing the same)

... Se forholena cræft and forhyded gold ne bið ællunga ungelice.

Btw: What's this? Your message lacks a CHRS: kludge so my editor wouldn't know how to make it readable for me... :-(

Bye, Wilfred.

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

Good ${greeting_time}, Nick!

19 Dec 2020 09:06:54, you wrote to me:

Fidonet is mostly a dead-end... its just a silly network people

are

mostly happy to just trade banter so long as shit works.

Please speak for yourself. Or at most for your part of the network,
if you exactly know the situation inside.

As a Fido developer of a product used in the back-office of two zones

git clone what?

and as as a ZC of one of them,

Do you mean that one consisting of less than 500 listed nodes, with most of them being duplicates operated by one sysop?

Good for a network level. Acceptable for a region. Miserable for a zone.

I believe my contributions are somewhat valid here if you are willing
to listen and not act like a petulent child.

That's you who are considering yourself one of "silly network people"...


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... that's why I really dislike fools.
--- /bin/vi
* Origin: ::1 (2:5020/545)

Hey Nick!

Unfortunately its going to be difficult to draft a proposal to
let something die versus something that lets systems continue to
run.

Speaking as the one who wrote it, it was easy. As for whether or not it gets accepted, rejected or totally ignored I was/am prepared to go along with whatever the powers that be determine to do ... or not do as the case may be. As per usual I will soldier on.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Wilfred!

So why don't you do the experiment and "fix" your system to put
this "much needed change" in your message headers,

It has been tested at this end.

and see how big your network becomes/remains?

Like you I already know the answer to that.

Your message lacks a CHRS: kludge so my editor wouldn't know
how to make it readable for me...

Bummer. Anyhow I took care of it for you as per this reply. No need to thank me for it.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi Maurice,

On 2020-12-20 14:36:51, you wrote to me:

So why don't you do the experiment and "fix" your system to put
this "much needed change" in your message headers,

It has been tested at this end.

But not outside your system?

and see how big your network becomes/remains?

Like you I already know the answer to that.

Good that you still have a sense of reality! ;-)

Your message lacks a CHRS: kludge so my editor wouldn't know
how to make it readable for me...

Bummer. Anyhow I took care of it for you as per this reply. No need to thank me for it.

A pure ascii message, that indeed doesn't need a CHRS: kludge...

... Don't cry for me I have vi.

Bye, Wilfred.

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

Hello Andrew,

On Sat Dec 19 2020 01:25:16, Andrew Leary wrote to Nicholas Boel:

It's seriously sad as fuck around here. I've taken long hiatuses
from posting just because I knew arguments would ensue I didn't
give a shit to be involved with. I'm a big fan of currently
developed software, and have multiple systems (some not on
Fidonet) running here to test software and enjoy the fact that my
hobby when I was 15 years old (am now going to be 40 next month -
and I don't care to hear how long any of you have been here) is
still progressing (albeit at an alarmingly slow pace, pretty much
due to the FTSC and or a select few people that apparantly want
Fidonet to just die already).

So you are advocating changing things without regard for maintaining compatibility with existing software?

No. Compatibility with existing software is great. However, when can one take into account that said existing software is just about extinct and move on without it?

Example: Most newer software has at one time or another implemented workarounds and other hacks in order to keep IREX useable when it's obviously broken. It hasn't been (nor will it be) updated in decades. If something like that is holding up advancement, why not try to persuade the possible handful of people still using it to use something else and carry on with moving forward?

There are plenty others that fall into that category as well. When can said software be considered defunct?

I personally welcome the discussion that Maurice started, and Alexey
has now joined in on. In fact, I am giving serious consideration to implementing some form of this in MBSE.

That's great! However it seems we just have to add/support more kludges because 30+ year old software will never support it. That's the annoying part.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- GoldED+/LNX 1.1.5-b20181215
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hey Wilfred!

It has been tested at this end.

But not outside your system?

I currently have three, two of which are known to fidonet. I haven't tested between 1:153/7001 and 2:280/464.113 but could easily do so if push comes to shove. The third I have a point setup to 1:153/7001 and that is where the good stuff is. I've posted from there to fidonet via 1:153/7001 more than a few times lately and between the two they have no issues with playing with headers and the such. As for 2:280/464.113, it is currently setup to compensate for those believing that kludges actually do something. :::snicker:::

Works like a charm despite the current DateTime stamp. None of the three actually use that for anything. It is just filler to compensate for a braindead standard. Isn't everything?

A pure ascii message, that indeed doesn't need a CHRS: kludge

Neither does utf-8 but I understand the limitations an editor like golded has especially when it comes to utf-8 and fidonet. Pure idiocy if you ask me. Mind you one of the 'problems' with vim is that it allows you to be totally stupid no matter what language you post in ... kludge or no kludge. :-/

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 20 Dec 20 16:52:00, Alexey Vissarionov said the following to Nick Andre:

I believe my contributions are somewhat valid here if you are willing to listen and not act like a petulent child.

That's you who are considering yourself one of "silly network people"...

LOL. I stand by all my words and your type of response and others you've written before - the "fag" remarks and all that - makes you the teenage script-kiddie of the network, never to be taken seriously, privileged to sit
at the grownups table for Christmas dinner, screams murder when the Iphone is taken away. Thats unfortunate because you do not speak for all of Region 50.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Hello Maurice!

Being a few days in hospital I will take the first post to answer. As we have seen, backward compatibility is always a problem with old software. But would the solution not be, simply defining a new version of the pkt-format? The structure is already versioned. So new software can work with advanced structures, while old software can just operate onwards with the old structures. As you nowadays have to agree on some agreements between sending and receiving system this would be just one more.

You could do this either by just working the new structure on systems knowing each other, or define a mailer or nodelist flag for the mailer session to signal the support of the new structure to any calling system.

Yes, the fidonet standards are old and have slept a long time, but nearly any part was designed with signaling for versions and support flags. Why not use them for what they are designed: signaling of new versions and supports that may or may not become a future to fidonet?



18 Dec 20 06:36, you wrote to Andrew Leary:

Just a little something to brighten your day and perhaps spark much
needed participation in this particular echoarea, or whatever the kids
are calling it these days.

proposed DateTime = a string 19 bytes long.
Format = "YYYY-MM-DD hh:mm:ss" where,
YYYY = four digit year
MM = two digit month ranging from 01
to 12
DD = two digit day ranging from 01 to
31
hh = two digit hour ranging from 00 to
23
mm = two digit minute ranging from 00
to 59
ss = two digit second ranging from 00
to 59

Since there is no room for the UTC offset DateTime should be set to
UTC in order to avoid confusion. This format will ensure that the
packed message is exactly the same byte length as specified in fts-0001.016 not counting the ASCII null charater that terminates the string as per packed MSG header specification for all header strings
(eg To, From, subj, etc).

Joachim


--- GoldED+/LNX 1.1.5--b20170303
* Origin: ----> FidoPI (2:240/6309)

Hey Joachim!

Being a few days in hospital I will take the first post to
answer.

Hopefully it wasn't anything too serious and I feel honoured that your first post was directed towards myself.

As we have seen, backward compatibility is always a problem with
old software. But would the solution not be, simply defining a
new version of the pkt-format?

Offhand I have two issues with this idea, the first being that writing a new format would be much more work than the rfc-3339 kludge and more than likely have the same result. Secondly it doesn't fix the problem embedded in the two digit year whereas replacing the DateTime stamp does and is probably the simplest and most effective true fix for a 20 year old bug that continues to haunt and will continue to haunt. Using a hospital analogy, you cannot call a disease cured if you still have the disease when being released from the hospital. At best you can say that it is in remission which isn't too far off from the current problem with two digit years.

Anyhow, as I said in a previous post I am open to dropping the proposal if something better is presented. So far I haven't seen it although your reasonable suggestion probably comes the closest but I am doubtful that it will have greater success than the rfc-3339 kludge idea. Having said that it isn't up to me to decide the merits of any proposal.

Why not use them for what they are designed: signaling of new
versions and supports that may or may not become a future to
fidonet?

That sounds very reasonable. I for one would appreciate seeing a rough draft of such a thing but the final decision isn't in my hands. However if I were a betting man I'd say your idea might have the greater edge at being successful.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

18 Dec 20 06:36, you wrote to Andrew Leary:

proposed DateTime = a string 19 bytes long.
Format = "YYYY-MM-DD hh:mm:ss" where,
YYYY = four digit year
MM = two digit month ranging from 01 to
12
DD = two digit day ranging from 01 to 31
hh = two digit hour ranging from 00 to
23
mm = two digit minute ranging from 00 to 59
ss = two digit second ranging from 00 to 59

Since there is no room for the UTC offset DateTime should be set to UTC
in order to avoid confusion. This format will ensure that the packed message is exactly the same byte length as specified in fts-0001.016 not counting the ASCII null charater that terminates the string as per
packed MSG header specification for all header strings (eg To, From,
subj, etc).

This is just creating busywork for the handful of developers left (eg. me, occasionally) and new bugs for no benefit.

In Fidonet you can safely assume that a two-digit year in any message is in the range of 1984-2083, given that the network began in 1984.

Anyone miraculously still running a FidoNet node in the year 2083 can either:

0. do nothing
1. modify the 1984-2083 window in their mail reader
2. invent a ^A control line that has the four digit year in it

#1 is easiest.

Timezones are already covered by FTS-4008 (TZUTC), and still not everyones uses those.

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

21 Dec 20 23:34, I wrote to Maurice Kinal:

This is just creating busywork for the handful of developers left (eg.
me, occasionally) and new bugs for no benefit.

Maybe it's too late, but if you want to actually create something useful (and long overdue), come up with some ideas of transparently detecting and overcoming mail delivery failures in FidoNet.

In the 25+ years I've been using FTN software this has become my biggest gripe. The software has no way of detecting that a node has gone down and automatically routing around the problem.

Because the only way I can tell if my uplinks go down is if I check my binkd logs for persistent errors, then manually intervene. With that part requiring a lot of mundane re-linking of echomail areas from another uplink I'm "friends" with, assuming they even carry the echos I've become disconnected from.

Not to mention netmails that never get delivered because an intermediate node went down permanently.

Admittedly this scenario is much less likely than it was in the dialup days, now that running a 24/7 binkp node costs very little, and hardware is much more reliable.

But there's always the possibility your uplink will suddenly disappear without warning.

Echomail "meshing" does help a bit, but obviously not with netmail.

Best of all, solving this problem shouldn't break any existing software, because it would be entirely opt-in. But beneficial for the people who opted-into the system, if it worked well.

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

On 21 Dec 20 11:22:58, Joachim Probst said the following to Maurice Kinal:

Being a few days in hospital I will take the first post to answer. As we ha seen, backward compatibility is always a problem with old software. But wou the solution not be, simply defining a new version of the pkt-format? The

This has been brought up so many times over the years... and beaten to death.

There is very little software in use that can be updated to a new packet format. Many Sysops prefer running software that is either abandonware or cannot be updated any further.

We have self-appointed experts who believe in dumping everything for new software but go to crickets chirping when asked "who enforces this". There is no longer any real means to tell a Sysop that they must use something newer. There is no requirement for anyone to use something newer.

Therefore at this point, new structures is a whimsical fantasy. At best, we are stuck with kludge lines to add anything new.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

On 21 Dec 20 23:53:52, Andrew Clarke said the following to All:

Maybe it's too late, but if you want to actually create something useful (a long overdue), come up with some ideas of transparently detecting and overcoming mail delivery failures in FidoNet.

I can already script all of this with D'Bridge.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Good ${greeting_time}, andrew!

21 Dec 2020 23:53:52, you wrote to All:

This is just creating busywork for the handful of developers left
(eg. me, occasionally) and new bugs for no benefit.

Maybe it's too late, but if you want to actually create something
useful (and long overdue), come up with some ideas of transparently detecting and overcoming mail delivery failures in FidoNet.
In the 25+ years I've been using FTN software this has become my
biggest gripe. The software has no way of detecting that a node has
gone down and automatically routing around the problem.

Ughm... here in R50 we had this almost solved many years ago, and the key software for it is available at https://github.com/huskyproject/fidoroute


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... god@universe:~ # cvs up && make world
--- /bin/vi
* Origin: ::1 (2:5020/545)

Hey andrew!

This is just creating busywork for the handful of developers
left (eg. me, occasionally) and new bugs for no benefit.

I am surprised nobody has criticised me over the year 9999 yet but perhaps they are all too distracted by backwards compatibilty rather than forwards compatibilty.

In Fidonet you can safely assume that a two-digit year in any
message is in the range of 1984-2083, given that the network
began in 1984.

Actually I've brought that up before but on my systems the real problem starts on 2069 since a two digit year reports itself as 1969 which in turn will create a negative time_t;

-={ date --date="01 Jan 69" +%s }=-
-31536000

Now that is scary. Mind you I will be well over 100 years old by then and unlikely to be a nodelisted Fidonet sysop, if indeed I make it that far.

0. do nothing
1. modify the 1984-2083 window in their mail reader
2. invent a ^A control line that has the four digit year in it

#1 is easiest.

I'd bet that 0. is the most likely and I including myself in that mix.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

Friday December 18 2020, Maurice Kinal wrote to Andrew Leary:

ss = two digit second ranging from 00
to 59

You have a little error on this field: sometimes the minute have 61 seconds - for example 31 december 2016 was 23:59:60 , or 30 june 2015 was 23:59:60 .
So - this field have ranging from 00 to 60 .

Regards, Vladimir Donskoy

--- GoldED+/W64-MSVC 1.1.5-b20180707
* Origin: DVB Station (2:5020/2992)

Hey Vladimir!

ss = two digit second ranging from 00 to 59

You have a little error on this field: sometimes the minute have
61 seconds - for example 31 december 2016 was 23:59:60 , or
30 june 2015 was 23:59:60 . So - this field have ranging from 00
to 60 .

That is not an error since there is no guarentee that leap seconds are universally accepted. Having said that I will take the liberty of dumping the above data into coreutils-8.32 'date' and see what it thinks about it;

-={ date --date='2016-12-31 23:59:60 +0000' }=-
date: invalid date '2016-12-31 23:59:60 +0000'

-={ date --date='2015-06-30 23:59:60 +0000' }=-
date: invalid date '2015-06-30 23:59:60 +0000'

In both cases it fails. However this works for both;

-={ date --date='2016-12-31 23:59:59 +0000' }=-
Sat 31 Dec 2016 11:59:59 PM UTC

-={ date --date='2015-06-30 23:59:59 +0000' }=-
Tue 30 Jun 2015 11:59:59 PM UTC

I read somewhere that leap seconds have to be added using a different method and I'll probably look it up later just in case someone makes the query. I don't recall if they (whoever they are) cited any app where you could input the datetime stamp in order to facillitate the above examples. I am fairly certain it wouldn't be found on most systems. Certainly not any FTN abandonware I am sure.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)