Subj : jumpin' jack flash To : Little Mikey From : mark lewis Date : Wed Apr 25 2018 05:40:18 On 2018 Apr 23 14:35:20, you wrote to me: ml>> really? type 2[.0] is definitely defined in there... LM> Indeed. However no mention of any other type except type 1 which LM> fts-0001.016 declares to be obsolete. right... but the original statement said there was no packet types defined in the document... ml>> 1:153/7715 doesn't run sbbs or sbbsecho... LM> The reply was to 1:153/757. that wasn't apparent... ml>> and here we thought you were old-school... the old-school way is ml>> forced right-hand margins with CRLF on each line... LM> type 1? A reference would have been nice. the format of the packed messages doesn't have anything to do with the PKT type ;) LM> As for CRLF, those are even more excessive than just a single LF. Old LM> school only requires a single CR but then again that depends on where LM> one gets schooled and of course doesn't apply when speaking LM> fts-0001.016. i'm speaking of old-school programs that have been used in fidonet since forever... LM> As for right-hand margins that requires even more wasted bytes in a LM> packed message. They certainly aren't required for display if one LM> considers inserting them at the start of each line, which of course is LM> variable depending on the hardware the message(s) get written to. at one time, the huge majority of messages being carried in fidonet had line terminators on every line... that's the "forced right margins" i speak of... in recent times, we've seen them forced to less than 40 places because someone was posting from a phone device... the majority of those messages from the heyday were posted via offline mail systems like QWK or bluewave... i'm not talking about what the specs call for... only what the programs are emitting... it took until the '90s before forced EOLs were being dropped in a majority of FTN compliant software... we still see a lot of it, though... even your posts fail to take all of my 199 column screen width which they should if there're no forced right margins... ml>> sbbsecho's MSGID is not corrupt... it just doesn't match some ml>> template that some fidonet folks think it should... LM> Reference? fts-0009.001 claims; sbbsecho does not claim to support fts-0009 so it does not apply... LM> ^AMSGID: origaddr serialno LM> where origaddr constitutes a valid return address for the originating LM> network. If indeed fts-0001.016 is to be considered the defacto standard LM> for Fidonet messaging then the origaddr would be 1:153/757 in this case. that depends on the definition of "valid return address for the originating network"... the data that sbbsecho puts in its msgid lines has enough detail to take you back to the actual message base and specific message number... the standard FTN msgid can only get you to the node... besides, the node number is in the MSGID line from sbbsecho... we won't even mention that the spec doesn't say that there cannot be more data given in the origaddr part... nor will we mention that the MSGID is not supposed to be parsed or used for anything other than message linking and duplicate detection... )\/(ark Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... .... Gravity is the chief cause of airplane crashes. --- * Origin: (1:3634/12.73) .