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
ml>> 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",

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

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

that's what got us in this mess... it's too 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.

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

what was a "kludge" at one time can become standard use but then
it "changes" from being a "kludge" and is now known as
something else that fits the actual purpose...

ml>> i can tell you now that there is NOT one that says what you say
ml>> above... in all that i remember reading, they all say that the
ml>> tearline is to be left as the message creation program put them.

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

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

 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.

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

ml>> ... define "technically correct"

 PE> Be able to achieve the fundamental requirement of delivering a
 PE> message from A to B intact.

ml>> ... by who's definition is "correct" the absolute one?

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

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

ml>> technology? yes, i am doing it deliberately... to proove that
ml>> tearlines are not =technically necessary= or required for mail
ml>> transportation or

 PE> No-one said that you can't design a mail system without it.

right...

ml>> manipulation.

 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.

uh... how do you seperate signatures on internet email from user text?
answer? you don't... this is akin to the same thing you are wanting to do
in fido stuff... strip off the signatures so you can compile directly
without having to edit... usenet and internet mail =MAY= have a -- (two
dashes) "tearline" but it is not mandatory, technically
necessary, or uniform thru out in it's use... yes, many are two dashes,
there are also many that are three dashes and many that have none at all...

ml>>> look how long my messages have been flowing in fidonet without
ml>>> a tearline! they, in themselves, are proof enough that
ml>>> tearlines are not required by the major movers or their

PE>> Nor is a valid date format!  So bloody what?

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!!!!!!!!

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

ml>> =i= am not the only one in the world. but =my= status is not
ml>> what we are tlaking about. the widespread use that i'm talking
ml>> about is that that is in effect by all the mail tossers out
ml>> there! THEY allow me to not have a tearline in my messages and
ml>> they DO pass those messages on unaltered and intact! THAT IS
ml>> WIDESPREAD USE/IMPLEMENTATION. not me, paul.

 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.

where is it defined in any fido specs that the tearline is for the message
reader? no where... FTS-0004 simply says that it puts in the tearline for
compliance... compliance with what?!!

)\/(ark