ml>> ahhh... ok, that i can understand but it's still not anything
ml>> to go nuts over... we seem to be handling it fine so far for
ml>> the most part... i think

PE> Fidonet is not working fine, it is just working.

ml> i didn't say "fidonet is working fine," i said "we
seem to be handling [no 
ml> leading x'01' on all control lines] fine so far"

We're not.  We never have.  That's why when you try to type
"SEENBY" in your messages, most editors will change that.  That's
why I never write it properly in my examples, either.

ml>> that developing new formats to handle these things is fine but
ml>> we should NOT cause these new formats to force things upon us
ml>> that our current style does not force on us. tearlines being
ml>> one...

PE> Tearlines are VASTLY common practice.  The only person I've ever
PE> seen not generating a tearline (you) could easily start generating
PE> one.

ml> you do not read enough area, then... i know quite a few people all over the 
ml> world who do as i do...

They're as rare as hen's teeth is what I meant.

ml>> no, not really but then comes that inevitable discussion of
ml>> what, exactly, is a control line. who creates them or decides
ml>> that "this" is a new control line? i personally cannot view
ml>> tearlines are control lines. if they were,

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 control 
ml> lines. 

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

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

Kludge lines ARE control lines.

ml>> there'd be "rules" against altering them. as it is now, with
ml>> the retearing capabilities that the old "quickbbs, i'm not
ml>> registered and don't want my messages telling everyone" stuff
ml>> gave us, tearlines, in strict reality cannot be considered
ml>> anything other than "user" entered text... sysops configure
ml>> their systems to retear or remove them and users offline mail
ml>> packages put in whatever they want... both are in a position to
ml>> be considered "users"...

PE> You are allowed to change the tearline of your own system's
PE> messages, in the same way that you're allowed to change the origin
PE> line.  Right up to the point of hex-editing the outgoing packet.
PE> It's only after that that you can't modify either of them.

ml> and where do you get this info from? what document?? 

FTS-4.  Specs don't tell you what you can't do, they tell you how a packet
looks like.

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

My message creation software is CMD.EXE.  What about it?  To accuse someone
of not following specs, you need to be able to prove it to be the case. 
All you have is a .PKT file.  Your proof needs to be based purely on that.

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

PE>> I generate a tearline to comply to FTS-4.  I write SQL comments
PE>> to make my SQL look nice.  I expect the other end to be able to
PE>> distinguish between the two without any ambiguity.  That is the
PE>> fundamental requirement of a message system.

ml>> human differentiation is not enough?

PE> Bloody oath it's not enough!  A mail system should be technically
PE> correct!

ml> haha, you're lazy > 

It's more than laziness, it's a FUNDAMENTAL REQUIREMENT.  The internet did
it right (and simple).  "we" made a complete abortion.

ml> ... define "technically correct" 

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

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

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

PE> Everyone except you already is.  And you're not not-doing it
PE> because you don't have the technology, you're doing it
PE> deliberately.

ml> there are a lot more out there than just myself who are not generating 
ml> tearlines in their messages... i'm not doing it bacause i don't have what 
ml> technology? yes, i am doing it deliberately... to proove that tearlines are 
ml> not =technically necessary= or required for mail transportation or 

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

ml> manipulation.

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

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 without a 
ml> proper and valid date format as defined by fidonet technical standards?

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

Here's some examples, and I found the 62-second one too...

DTS001 Bad date: 01 Jun 94  21:28:60
DTS001 Bad date: 04 JUN 94  14:24:01
DTS001 Bad date:  2 Jun 94  09:05:47
DTS001 Bad date: SAT 30 JUL 94 13:01
DTS001 Bad date: FRi 25 NOV 94 09:22
DTS001 Bad date:  1 Jan 1600 00:40:0
DTS001 Bad date: 6 Sep 95 18:08:00
DTS001 Bad date: 00 er 00  00:00:00
DTS001 Bad date: 01 Jan 96  11:57:62
DTS001 Bad date: 13 Jan 96  24:32:00
DTS001 Bad date: 25 jul 96  01:23:29


ml>> software. isn't that how we set standards in fidonet? to have
ml>> an implementation in widespread use? isn't this implementation
ml>> of no required tearlines in widespread use? -=B-)

PE> One USER does not comprise widespread use.  What percentage of mail
PE> going through your system has a tearline?  Common practice.

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

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

---