| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.