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).
