Hi David.  I have tried to send this to you numerous times, but
if you have been replying, I haven't been receiving the netmail.
I could be having netmail problems, I don't know.  Apologies
to anyone who thinks this is off-topic (there is -->*C*<--- code 
that implments this proposal already BTW, PQWK221.ZIP, available
for FREQ from 3:711/934), but this is the only conference that
David and I both get (to my knowledge).  BFN.  Paul.

Document: FSC-????
Version:  000
Date:     10-Sep-1994




                      Distinguishing user-entered text 
                      Paul Edwards, FidoNet 3:711/934
                                 1994-09-10




Status of this document:

     This FSC suggests a proposed protocol for the FidoNet(r) community,
     and requests discussion and suggestions for improvements.
     This document is released to the Public Domain.

     Fido and FidoNet are registered marks of Tom Jennings and Fido
     Software.




       The Problem:
       ------------

         Most kludge lines in messages start with a x'01' so are readily
         distinguishable from user-entered text.  However, there are the
         following exceptions, found mainly in echomail:
         
         "AREA:"       - the name of the echomail area
         "---"         - the tearline
         "SEEN-BY:"    - the seenby control lines
         
         These control lines, being normal text lines, could be entered by
         the user, or appear in quoted text, etc.  This can then interfere
         with mailprocessing done by Fidonet Technology software.  It is 
         such a problem that some quoters will change the word "SEEN-BY" 
         to "SEEN+BY", e.g., in quoted material.  This is quite annoying, 
         and stems from the fact that these control lines were not prefixed 
         with a x'01'.
         
         
       The Solution:
       -------------
       
         In both netmail and echomail, before the user text starts, a
         "^ASOT:" line may be inserted.  This is a kludge line that
         follows the rules in FTS-1.
         
         When the user text finishes, there should be a corresponding
         "^AEOT:" line inserted.  This should appear after the user 
         text, and before the tearline et al.
         
         There shall be exactly one SOT and one EOT.
         
         Some mailprocessors find the SEENBY lines by reading backwards 
         until they hit a non-SEENBY line.  The ^AEOT, being a non-SEENBY
         line, will thus make sure that user-text with a SEENBY in it will
         not be interpreted as a SEENBY.
         
         It will also stop a netmail message starting with "AREA:" (entered
         by the user) from being recognized as an echomail message, assuming
         the mailprocessor is looking for "AREA:" as the very first bit of
         data.
         
         The SOT and EOT lines will be a maximum of 80 characters in length,
         including the x'01', the  and an optional . 
At a later date,
         data may appear after the keyword, ie "^ASOT:
" and the format 
         of that data will be documented in this document.  If there is 
         additional data, then there MUST be EXACTLY ONE space between the
         keyword and the data.  If there is no additional data, then there
         MUST NOT be any space or other characters after the keyword and
         before the .


       Implications of using SOT/EOT
       -----------------------------
         
         If you choose to generate SOT/EOT, the following things
         must be true when the packet leaves your system.  However,
         since most of this is control information, it can quite
         validly be changed in-transit, so you should not rely on
         this stuff remaining true when you receive the information,
         and so long as the message conforms to the relevant FTS
         specs, you should just ignore (not delete) the presence
         of the SOT/EOT kludges if something seems amiss.
         
         1. All occurrences of x'8d' in the user text must be
         normal text data that was entered by the user, not
         "soft-CRs".  x'8d' is a printable character in some
         character sets, just like 'A', 'B' and 'C' are in ASCII.
         
         2. Between the "^ASOT:" and "^AEOT:" lines there should
         be only user text and other kludge lines.
         
         3. The AREA line in an echomail message will be the very 
         first line, ie no intervening kludges.
         
         4. The SOT kludge will be the very last kludge in the
         initial block of kludges.
         
         5. The EOT kludge will be the very first kludge after
         the user text ends.
         
         6. Only kludges that are meant to give further information
         about selected bits of user text shall be placed between
         SOT and EOT.
         
         7. The only text control lines will be the ones shown
         above, plus any number of blank lines.  Ie you cannot
         use '# Origin' or anything else not protected by a ^A.
         This rules out a Ctrl-Z as well.
                  
         8. There will be no LF present in the user data or control
         lines.  CR is all that is required.
         
         9. Origin lines will be a maximum of 80 characters long,
         including the CR.  Tearlines will be a maximum of 40
         characters long, including the CR.  SEENBYs will be a
         maximum of 80 characters long, including the CR.  The
         AREA line will be a maximum of 80 characters long,
         including the CR, placing a maximum limit on the area
         name of 74 characters.  All kludge lines must be a
         maximum of 255 character long, including the CR and the
         ^A.
         
         10. The date format in the message will be Fido format,
         not Seadog format.  Also please note that the Fido date 
         format in FTS-1 mandates that a leading '0' will be
         present in days less than 10.
         
         11. The Origin line will contain a 4D address in brackets
         at the end (ie 5D is not allowed).  There will be nothing 
         except the address in the brackets.  There will be no 
         characters after the right bracket, except for the CR.
         
         12. There shall be no occurrences of x'01' in the user
         text, except for valid kludge lines (ie you cannot
         quote the x'01').  Also x'00' obviously can't be used
         in user text.
         
         13. There shall be no padding blank lines put in between
         the SOT and the start of the user text, and the end of
         the user text and the EOT.  However, if the user put in
         blank lines at the start or end of their message, then
         they will stay there.  So it should be possible to send
         a message that has 5 blank lines, 1 line of text, then
         3 blank lines, without software getting in the way.
         
         14. The control lines must be generated in this order
         (after the EOT):
         ******************************************************
         one blank line
         tearline (optional, unless an FTS spec says otherwise)
         origin line (mandatory)
         seenbys (mandatory)
         path (mandatory)
         any other kludges (optional)
         ******************************************************
         Thus there should be exactly one blank line after the
         EOT.
         
                  
       More Information:
       -----------------

         If you intend to follow this proposal you must implement all of 
         it. If you have any questions as to how certain sentences are to 
         be interpreted, do not hesitate to contact the author of this 
         document, whose address is at the top of this document.

@EOT:

--- Mksmsg