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