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:

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

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

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

Joachim


--- GoldED+/LNX 1.1.5--b20170303