PE>> If FTS-4, or any other standard, defines them, then they are
PE>> control lines BY DEFINITION.

ml>> i disagree... unless the actual definition states that they are
ml>> control lines.

PE> STANDARDS DEFINE CONTROL LINES!!!  That's what they're there for!!!
PE> You don't need to explicitly say "Mark, this origin line I am
PE> defining is a control line",

ml> and why not??? isn't this the exact degree of explicitness that you seek so 
ml> as to remove all ambiguity and (mis)interpretation ???

I want to remove the ambiguity.  I don't want to be absurd.  Are you also
going to put in a bit that says "The following document is written in
English, not Mark-language (Mark-language treats "not" as the
equivalent of the english word "must").

I have identified all of the ambiguities I found, in the SOT/EOT rationale.

PE> you just say "The origin line is placed here".

ml> that's what got us in this mess... it's too interpretable -=%-)

THAT IS NOT INTERPRETABLE.

ml>> in this case, tearlines are not defined as such. in fact, they
ml>> are not even defined as kludge lines or even user entered text...

PE> Kludge lines ARE control lines.

ml> no... "kludge" is akin to "jury rigged",
"afro-engineered", "shoestrings 
ml> and bubble gum", "scotch tape and band aids", etc...

"kludge" means "stupid hack".  The FTS inventors were
stupid enough not to make the format flexible for expansion.  This is the
stupid hack they provide to make it expandable after-the-event.  Those
stupid hacks are ALL control lines.

PE> My message creation software is CMD.EXE.  What about it?

ml> if CMD does not put in a tearline when the message is saved, then you still 
ml> leave it as it is. ie: no tearline   however, to my knowledge, CMD also 
ml> doesn't put in an origin line... ;-)

It does.  It spawns other executables in order to do it, e.g. msged,
retear, tobruk etc, but in the end, it gets the message I wanted, saved
into a .PKT file.

BTW, the above paragraph does not imply that I am no longer in need of a
copy of retear.  :-)

PE> If fido wasn't such a mess, we wouldn't even be having this
PE> conversation. It's quite a fundamental point that user-text should
PE> be separated, and that only packet formats used for interchange are
PE> actually standardized.

ml> i sure that usenet and internet hasn't gone thru this same discussion... 
ml> not!

I'm sure they haven't.  They did it right.  All control lines up front,
blank line separator.  Nothing wrong with that.

PE> Anyone who can prove that a user can enter some text, and it gets
PE> from A to B unmangled.

ml> for our discussions on this mail system, i'll accept these definitions for 
ml> now >

Ok.

PE> However it IS technically necessary, in the absence of some other
PE> delimiter, to do the manipulation required to extract the user
PE> text. I wish you were more concerned with technical correctness
PE> than "proving" some ridiculous point (ie that mailprocessors don't
PE> need it).  Your only solution is "extract the data manually".
PE> That's not a solution, that's proof of a mess.

ml> uh... how do you seperate signatures on internet email from user text? 

You don't.  They are part of the user text, as defined by the RFC specs. If
they were control lines, they go before the blank line.  Everything after
is user-text, according to the specs.  What the user chooses to fill his
user-text up with is COMPLETELY UP TO HIM.  If he puts in "fred loves
mary" at the beginning and end of his user-text portion, that's up to
him.  If he chooses to put a C program, with nothing else before or after
it, then a C program comes out of the other end.

ml>> it's not? then suppose you tell me how far a message will get
ml>> without a proper and valid date format as defined by fidonet
ml>> technical standards?

PE> ALL OVER THE WORLD.  ANYWHERE, ANYTIME.  CHECK YOUR OWN INBOUND
PE> PACKETS AND SEE WHERE THEY CAME FROM!!!!!!!!

ml> my system runs GMD on every echomail message arriving here. at this time, i 
ml> only have one timestamp problem appearing and it is from someone's 
ml> opusseadog conversion mess or lack of and assumption of one
format or 
ml> the other...

GMD misses out the most common error - putting " 2" instead of
"02" in the fido format.  I don't know what else it misses.  I
know the 19-byte date format is configurable (which way is yours)?  You
could have someone correcting the dates near you too.  I've mailed people
all over the world about the dates.  ie the messages get all over the
world. YOU DON'T NEED A VALID DATE FORMAT IN FIDONET MAILPROCESSING.

PE> It is BOTH widespread practice that a tearline is not required for
PE> mailprocessing to work AND to generate a tearline.  In the former
PE> case, the tearlines are not so much for the mailprocessor's use,
PE> but for the message reader, RFC822 converter etc, to separate out
PE> the user-text.

ml> where is it defined in any fido specs that the tearline is for the message 
ml> reader? 

It shouldn't.  It should only specify the format.  E.g. maybe you are
reading the format in order to convert to RFC-822.  In which case, it's not
for the reader, it's for the RFC-822 converter!!!  Which will either move,
or strip, both the tearline and the PID, to the control info block of the
RFC-822 message.  THE TEARLINE IS NO DIFFERENT TO THE PID.

ml> no where... FTS-0004 simply says that it puts in the tearline for 
ml> compliance... compliance with what?!!

In the absence of something to the contrary - compliance with the spec!

BFN.  Paul.
@EOT:

---