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)