TZUTC: -0800   
   MSGID: 8260.doorgame@1:103/705 2d9cac72   
   REPLY: 842.f_doors@1:2320/105 2d9c15ba   
   PID: Synchronet 3.21a-Linux master/1a1360a25 Dec 07 2025 GCC 12.2.0   
   TID: SBBSecho 3.32-Linux master/1a1360a25 Dec 07 2025 GCC 12.2.0   
   COLS: 80   
   BBSID: VERT   
   CHRS: CP437 2   
   FORMAT: flowed   
   NOTE: FSEditor.js v1.105   
     Re: Re: Kannons and Katapults   
     By: Mike Powell to Stephen Hurd on Mon Dec 08 2025 09:10 am   
      
    >   Re: Re: Kannons and Katapults   
    >   By: Stephen Hurd to Mike Powell on Sun Dec 07 2025 19:52:01   
    >   
    >  >   Re: Re: Kannons and Katapults   
    >  >   By: Mike Powell to STEPHEN HURD on Sun Dec 07 2025 11:13 am   
    >   
    >  >  > I have it set up to be accessible via two ports.  The primary allows   
    >  >  > folk who have a terminal program capable of RAW mode to call in   
    >  >  > without the double-CR while also being able to do things like download   
    >  >  > a QWK packet.   
    >   
    >  > To be clear, it's a CR LF, not a double-CR... but a lot of old software   
    >  > will   
    >   
    >   
    > I am a little leary to blame "old software" when the software itself has no   
    > issue interpreting the tap of the enter key as "one" return... CR or LF or   
    > whatever.   It seems more like a case of syncterm, etc., sending an extra   
    > character when in telnet mode that older software -- i.e. most BBS software   
    > that isn't Synchronet or Mystic -- doesn't know what to do with.   
      
   That's how the Telnet protocol is specified though.   
   https://www.rfc-editor.org/rfc/rfc854:   
      
            "CR LF" or "CR NUL" is required in both directions   
            (in the default ASCII mode), to preserve the symmetry of the   
            NVT model.  Even though it may be known in some situations   
            (e.g., with remote echo and suppress go ahead options in   
            effect) that characters are not being sent to an actual   
            printer, nonetheless, for the sake of consistency, the protocol   
            requires that a NUL be inserted following a CR not followed by   
            a LF in the data stream.   
      
   Note: there is no ASCII character for "the enter key", usually the enter key   
   is represented by a single CR (^M, ASCII 13), but in the case of the Telnet   
   protocol, it's not. When using Telnet and not in "binary transmit" mode, every   
   CR character must be followed by either a NUL or an LF.   
      
    > That might be semantics but I it is odd that using an older terminal program   
    > over a telnet connection (with something like VMODEM) doesn't cause this,   
    > which makes me suspect it is the modern BBS terminal programs that have   
    > changed something.  I am sure the answer is "cause telnet protocol" but   
    > since we are using these terminal programs to telnet into BBSes and not old   
    > VAX   
    > or mainframe machines, I have to wonder who thought that was necessary.   
      
   If the BBS doesn't actually support Telnet, then Telnet shouldn't be used.   
   --    
                                               digital man (rob)   
      
   Synchronet/BBS Terminology Definition #66:   
   RIP = Remote Imaging Protocol (e.g. RIPscrip)   
   Norco, CA WX: 82.0øF, 20.0% humidity, 0 mph NNE wind, 0.00 inches rain/24hrs   
   --- SBBSecho 3.32-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 10/0 1 102/401 103/1 17 705 105/81 106/201 124/5016 128/187   
   SEEN-BY: 129/14 305 153/7715 154/110 218/0 1 109 215 601 700 810 840   
   SEEN-BY: 218/860 880 900 226/30 227/114 229/110 112 134 200 206 307   
   SEEN-BY: 229/317 400 426 428 470 664 700 705 266/512 291/111 301/1   
   SEEN-BY: 320/219 322/757 342/200 396/45 633/280 712/848 902/26 5020/400   
   SEEN-BY: 5075/35   
   PATH: 103/705 218/700 229/426