PE> Eh?  Not prefixing all kludge lines by x'01' is the original dog's

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

Fidonet is not working fine, it is just working.

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

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

PE> breakfast.  Just whacking text control lines into user-text with no
PE> way to distinguish the two is the dog's breakfast.  Do you
PE> seriously think that was an OK thing to do?

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

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

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

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

PE> I generate a tearline to comply to FTS-4.  I write SQL comments to
PE> 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? 

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

ml> yes, i think it'd be a nice feature 
ml> for mail reading programs 

or RFC-822 converters etc

ml> to remove all the extraneous stuff from source 
ml> code messages and others like them but is it really worth forcing everyone 
ml> to do something that not strictly required? 

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

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

Nor is a valid date format!  So bloody what?

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

One USER does not comprise widespread use.  What percentage of mail going
through your system has a tearline?  Common practice.  BFN.  Paul. 
@EOT:

---