[Oberon] Re (2): Removing unnecessary and embedded RETURNs.

[peter at easthope.ca]

J=F6rg,

Thanks for the replies.

From:	"joerg.straube at iaeth.ch" <joerg.straube at iaeth.ch>
Date:	Mon, 13 Nov 2023 05:08:37 +0000
> The idea with the state machine is good.

I spent some hours tossing ideas before adopting that. Of course my 
self-evaluation risks bias.  =8~)

> I don't understand your remark "ReadText is external to this byte 
> padding" In my point of view in the ELSE part of state 3 you would 
> have to strip the stuffed period.

Initially, I had exactly the same thought and worked in that direction.  
Then resorted to empiricism to clarify how "byte stuffing" fit in the process.

ReadText takes bytes from the communication link and puts them 
in the MailMessages file.  MailMessages can be examined directly with 
an editor.  It is plain text with lines ending CR LF.

According to my tests and observations this is the process.

(1) Sending MUA "byte stuffs" the message body.

(2) The sending MUA submits to the communication link with 
End-of-message represented by CR LF "." CR LF.

(3) The stream of bytes is transmitted unchanged over the link.

(4) The receiving MUA takes bytes from the link and appends to 
MailMessages until CR LF "." CR LF. The sequence CR LF "." CR LF is 
included in MailMessages to mark the end of the message.  Observe that 
a byte stuffed line '".." blah blah blah CR LF' is always distinct 
from end-of-message, CR LF "." CR LF. "Byte stuffing" is a clever 
idea.  =8~)

(5) When the recipient requests to see the messge, the receiving MUA 
extracts it from the MailMessages file and displays with periods 
"unstuffed".

If you have the Mail module working, make a test message containing a 
line beginning with a period and send it to yourself.  Then examine 
the MailMessages file with an editor.  There the line beginning with 
two periods will be visible.  The message is displayed with periods 
"unstuffed".

Here is my summary.
(1) "Stuff" any line where the first byte is ".".

(2) Submit to transmitting link.

(3) ... 

(4) Receive off the link.

(5) "Unstuff" and display.

Stuffing and message transfer are distinct.  I should have written 
that stuffing is external to transmission rather than transmission is 
external to stuffing.  ReadText is part of transmission.  ReadText 
should not alter "stuffing".

Incidentally "full stop padding" or "period padding" are better terms
than "byte stuffing". "Period" is more specific than "byte" and 
"padding" is more correct than "stuffing". Padding is on the perimeter 
of something whereas stuffing is inside.

From:	"joerg.straube at iaeth.ch" <joerg.straube at iaeth.ch>
Date:	Mon, 13 Nov 2023 05:37:10 +0000
> As the last line with only =93.CRLF=94 is not considered part of the text, =
> you should delay Files.Write(R, ch); in state 3, 4, 5 until you know whethe=
> r it=92s the termination case or byte-stuffed case.

Explanation above.  Stuffing remains in MailMessages.  Unstuffing 
occurs when the message is extracted from MailMessages and displayed.  
If periods are unstuffed in MailMessages, a message line containing 
only a period can appear to be end-of-message.  =8~/

> the original code does not copy the starting =93.=94 of a line to the file,

See above and verify empirically.

> copies over the final CRLF. In most cases, this additional CRLF at 
> the end does not harm but is - strictly speaking - not correct.

I agree but suppose a message is submitted ending with these bytes and 
no folllowing CR LF.
The end of my message.

My Mail.Sig.Text file contains these two lines.
-- 
My mail signature.

If the MUA does not add an end-of-line to separate the message body 
and signature, these two lines will be transmitted.

The end of my message.-- 
My mail signature.

That breaks the signature delimiter syntax from RFC 3676.
https://en.wikipedia.org/wiki/Signature_block#Standard_delimiter

So we don't know whether a CR LF between the end of the message body 
and the signature was added by the human sender or by the MUA. The 
ambiguity is imposed by RFC 3676.  I don't know a good resolution but 
usually end a message body with CR LF.

Thanks for the discussion,                    ... P.L.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope