| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Nodelist format |
Hi Michael, Saturday July 03 2004 01:33, you wrote to Gordon Lewicky: MG> Hello Gordon. 03 Jul 04 02:53, you wrote to me: MG>>> I disagree. Most mailers will already prevent any dialing when MG>>> they encounter -Unpublished- in field six, even without the Pvt MG>>>... MG> So we hold the network's progress hostage to antiquated software that MG> should have been updated long ago, except that the authors have MG> disappeared and not released the source code? At some point, one has MG> to give up on abandonware and use something that works for /today's/ MG> needs in this network. MG> If some people can't accept that you need to make some allowances for MG> the needs of others in this network, then I'd say that this network is MG> better off without them. Implementing new technologies or addtl. features into existing nodelist format _must_ be backwards compatible under all circumstances! This means, leaving restriction rules untouched. Add features in a way that old nodelist line parsing rules will work, for _all_ software, old and new without exceptions. The only exception that is acceptable is that the new features cannot be used by old software .... i.e. - placing a FQDN into field 3 or 4 (systemname, city fields) is acceptable 'cause these fields wasn't parsed by any software for any dialing rules. - Breaking the pvt/-unpub- rule breaks the restriction implented in existing and used software. - Placing a FQDN into the phone field breaks the rules that implemented in existing software and handled by one or more modem chipsets. Nobody can guarantees that case b or c changes of rules preventing existing running systems to barf. Exceptions are a known fact for these rules. So implementing these rules _can_ causes harm to members (i.e. phone costs, time to find out a solution to deal with). So this implemtation is inaccetable by design. Alternativly a Pvt redefinition by a policy upgrade, that pvt can also be used for alternate listings such as IONs will not break the software implemention rules to handle pvt. regards, uli ;-) ---* Origin: AMBROSIA - 63067 Offenbach/M. (2:244/1120) SEEN-BY: 633/267 270 @PATH: 244/1120 1200 2432/200 774/605 292/854 140/1 106/2000 633/267 |
|
| 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™.