Re: [ietf-smtp] Stray <LF> in the middle of messages

Hi Keith,

On 6/10/2020 7:33 AM, Keith Moore wrote:
> On 6/8/20 10:03 AM, Hector Santos wrote:
>
> CRLF also may have had an advantage in that text files using that
> representation could be sent directly to an ASCII terminal (like a
> teletype or CRT) or printer without the need for translation.
+1.

My early software development career was working on teletypes, punch 
card machines, dumb, smarter, raster vs vector graphics capable 
terminals, printers, include lasers and plotters. I provided tools to 
make "life" easier for the corp, so I am well-verse with the 
input/output control designs.
<OPTIONAL_READING>

My burned-out memory is fading, but here goes:

You are correct ASCII control codes (0 to 31) were used for text-based 
devices to control the movement of the printer head or the terminal 
cursor position. Graphical capable terminals also had own set, 
usually, ESCAPE sequence based, to control their CURSOR/HEAD.
The 80x25 screen dimension with the 80 columns, was an emulation of 
punch card machines.  8x8 pixel cells were used hence why early 
terminals in graphic mode were 640x400 pixels dimension, 80x8=640, 
8x25=400. I believe the IBM terminals had different capabilities. I 
never programmed them.
With smarter graphical-capable terminals (switchable from raster vs 
vector graphics) allowed for 132 columns (in graphic mode) which was 
an extension for additional columns punch card emulation.
Programming Punch Card machines was basically mechanical for 
repeatability to reduce typing and auto push out the current and add 
the next card.
I have written ANSI/VT10x drivers/emulators, telecomm clients that 
worked with early hosting software. Over X.25, PCBOARD was among the 
first, if not the first, hosting app reprogrammed (upon my request) to 
support non-modem (RS232) profiles also called NULL modems to support 
EICON and X.25 with PAD (Packet Assembler/Disassembler) devices. They 
worked by waking up the host with a CR character or it raised the 
hardware carrier detection signal. PADs also had to be programmed to 
be in passthru mode and switched from software-based Flow Control to 
Hardware-based Flow Control. Otherwise binary file transfer would stop 
if there was a control S, ^S, characters in the payload that were not 
escaped.
In my early X.400 work, I worked a program ("Emailatator"), an MUA per 
se, to capture ASCII screen dumps of X.400 messages to print the 
messages for managers/engineers to read first thing in the morning 
with their coffee and donuts. People may recall when we used our 
office telephone as a data connection to some device (probably a PAD) 
that woke up the X.400 software.  That is why I didn't recall what 
X.400 used for its EOL because the host displayed the email line by 
line. The screen capture software did not see control characters, just 
the rendered screen output. With CompuServe, an early Offline Mail 
Readers (MUA) called TapCIS used the same primitive screen capturing 
method.  But on PCs, now the "Smarter" terminal now only with 
graphics, it has Memory and Storage now. When the backend host began 
to offer "add-on" backend hooks allowing Mail Packing software to be 
installed (on the backend) to allow a companion frontend apps (on the 
frontend, a MUA pe se) to pickup compressed mail packets, and also 
send back. Qmail Deluxe was the first to do this and Silver Xpress (my 
first commercial product) followed suit using the QWK and OPX mail 
format. Al Gore had yet to "invent the internet" but when he did, that 
was my first venture into the IETF when I added RFC822 support to the 
Silver Xpress MUA. The backend used UUCP/UUCICO as a store and forward 
mail gateway.
Today Wildcat! still supports VT10x/ANSI connection detection and 
emulations for the various text-based interfaces devices, example;
telnet winserver.com

It will know if you are human using an ANSI/TERMINAL or an automated 
mail data transfer app.  It also detected PPP, "mini-ppp" and the old 
RIP protocol (obsolete) which as an early competitor to HTML and of 
course, HTML won.  The proprietary Mini-PPP used a similar PPP 
detection designed to interface with a graphical Frontend.
The text-based terminals and client software, all offered 
configurations add either just send the CR or CRLF with the enter key. 
So I think the OSes used CR or CRLF as a EOL for that reason or LF for 
*nix although I don't see why a human would type a LF as a terminator 
when it takes two key (^J) but then again, today, many online 
messaging/comment logic don't use the enter key to submit the text. 
Oh boy, many will be in trouble is the ENTER key was the EOL. But 
technically, LF does not move the cursor or "file position" to the 
beginning of the next line, so for storage, why did *nix use LF for 
its EOL?
When I worked with text and laser printers, such as HP, OkiData 
printers, one of my early programs which started on a VAX then moved 
to the PC, was my LPRINT program to print text files with first page 
user name banner similar to the batch job print outputs we use to get. 
I still have lprint:
lprint V3.00/32 - Laser print utility by SSI
usage: lprint [file spec] <file spec>...<file spec> <options>

       infile   - any text file
       options:
        -H produce header with file name, page #
        -D print current system date on header (-D promotes -H)
        -L landscape print -B bold print, -C condense
        -B bold print
        -C condense print
        -X print preformatted files, like WORD. All other switches 
ignored.
        -PLxx set the page length
        -L6 set the 6 lines per inch (default, Auto sets PL to 55)
        -L8 set the 8 lines per inch. (Auto sets PL to 75
        -WW set word wrap on
        -TXxx expand tabs to XX blanks (default 8)
        -Ooutfile (default is LPT1. Overwritten by environment PRN 
string)
        -GB (Generate Banner Page, default None)
        -V  verify file to print (Ask you Y/N to print file)
        -DG DG laser printer HP Mode

sample: LPRINT source.c *.h *.mak -h -d -c

Lprint will format your file for text/laser printing. A banner page 
will be
printed with your file name, your user name, and date. The user name is
defined by having a SET ID= environment string (or USERNAME). Lprint also
looks for SET PRN= environment string if the output file is not defined.
Within the text file itself, you may embed the following keywords in
column one:

      //PAGE or /*PAGE*/          :  force pagination of your print.
      //BOLD or /*BOLD*/          :  force bold print.
      //CONDENSE or /*CONDENSE*/  :  force condense print.
      //NORMAL  or /*NORMAL*/     :  force normal print.

I recall using the built-in (default) BIOS character set to get the 
8x8 pixel cells per character and used that to do the large print 
banners of your name, i.e. HSANTOS, KMOORE, etc.
I also worked on FAX devices which used scan lines. It also used 8x8 
cells, at least early ones as I recalled programming one.
Anyway, as you can see, I was well verse with all these earlier 
terminal/printer HEAD/CURSOR control design considerations.
I did not why with CRLF was used for RFC822 but as you said FTP was an 
early start into transferring "mail".
But I have always believed (presumed) when the dumb terminals were 
used to program and test the early text-based client/server protocols 
like FTP, POP3, SMTP, NNTP, etc the developers was hitting enter (CR) 
key. It was all the human had to naturally do to end the line and send 
it to there to the backend host. Either the terminal was send the CR 
or optionally CRLF.  The backend could also echo back each character 
in full duplex mode including the CR and/or LF.
Microsoft Telnet has these two options:

o Local echo off
o Line feed mode - Causes return key to send CR

The line feed mode sends an CR because the backend (telnet server) is 
expected to echo back the LF. When the terminal is in Local Echo Off 
mode, it is expected of the  backend will echo back all characters.
Ironically, Legacy applications still thrive!  One my current projects 
is writing a cSharp (c#) SDK libraries for ANSI/VT100 and IBM Extended 
character emulation. 3rd party developers are writing C#-based 
applications are spawned by the Host to take over the COMM I/O with 
end users.  Many of them are writing games or had some text/andi/vt100 
service.
</OPTIONAL_READING>

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp