TIP: Click on subject to list as thread! ANSI
echo: net_dev
to: Paul Edwards
from: mark lewis
date: 1996-11-07 11:30:32
subject: Re: FTS-0005

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

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.

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

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.

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

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

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.

i disagree... unless the actual definition states that they are control
lines. in this case, tearlines are not defined as such. in fact, they are
not even defined as kludge lines or even user entered text...

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.

and where do you get this info from? what document?? i can tell you now
that there is NOT one that says what you say above... in all that i
remember reading, they all say that the tearline is to be left as the
message creation program put them.

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!

haha, you're lazy > ... define "technically
correct" ... by who's definition is "correct" the absolute
one?

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

 PE> 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
ml>> forcing everyone to do something that not strictly required?

 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.

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

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?

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

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.

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

-=B-)

)\/(ark

* Origin: (1:3634/12)
SEEN-BY: 13/13 37/100 50/99 102/735 105/103 119/88 129/11 138/146 153/800 920
SEEN-BY: 157/586 167/90 200/204 201/505 203/512 992 204/200 209/720 7211
SEEN-BY: 239/1 245/6910 260/742 261/1137 270/101 102 103 104 211 272/160
SEEN-BY: 280/1 801 282/1 4073 283/657 292/511 876 320/119 321/1 332/1 334/201
SEEN-BY: 341/70 1002 344/3 345/12 348/105 362/37 367/1 385/100 387/31 396/1
SEEN-BY: 402/311 403/150 405/0 406/100 430/105 440/1 600/348 620/243 626/660
SEEN-BY: 632/348 640/206 230 305 820 821 822 823 700/101 711/409 410 413 430
SEEN-BY: 711/808 809 934 712/515 713/317 724/10 800/1 2002/2002 2430/1423
SEEN-BY: 2433/225 2602/100 2604/104 2613/5 2624/306 2630/1001 3401/308
SEEN-BY: 3611/18 3615/7 50 7104/2
@PATH: 3634/12 170/400 396/1 270/101 209/720 640/820 711/409 808 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.