Subj : proposed new nodelist [2] To : Peter Knapper From : Jasen Betts Date : Tue Jul 16 2002 02:16 pm Hi Peter. 15-Jul-02 21:17:38, Peter Knapper wrote to Jasen Betts PK> Hi Jasen, PK>> A new format YES, but as an addition to the current nodelist, NOT PK>> a replacement JB>> Why not duplicate the nodelist information in the new file, it JB>> would make its use easier ... PK> Because its not needed. true.... I see that now. there's no need to improve the nodelist for internet nodes, but a tool to "downgrade" the nodelist so that POTS mailers that have problems with some current conventions can make sensible choices when given crashmail for IONs. JB>>> Leave them broken? why? PK>> The current Nodelist is NOT broken to me. JB>> you are not all of fidonet... PK> I never said I was, however I am a member who has no problems with PK> the current Nodelist data, I just understand that it will not PK> always work for some. And that's valid not motivation to fix it? JB>> (do you really want me to list my gripes with what is again?) PK> Well never having seen your previous comments I have no idea what PK> you are talking about. If you are talking about the way people PK> have mangled Nodelist entries to do something they wanted and PK> "broke" the way the Nodelist works for others, then I am not PK> surprised. yeah, basically that. JB>> but I see no way that this plan of yours can benefit users of JB>> existing software. PK> Its not designed to, it is only for IP nodes, the PSTN segment PK> always has the nodelist to satisfy their needs It won't benefit users of existing ip fido software either. but it does seem to be a good addition to fidonet. JB>> like the nodelist? like echomail routing? you're relying on JB>> others every day when you use fidonet. PK> So minimise the amount you have to repy on them. I favour maximising the reliability of the rest of fidonet... same goal different strategy. PK> One thing a lot of people forget is that just about the entire PK> Fidonet Backbone is moved using IP these days. All these IP nodes PK> work using something other than Nodelist info. Amazing how they PK> manage to do this without using the Nodelist.......;-) true, the nodelist sn't used for moving echomail (except in some errorchecks) JB>> And this is not somethoing than cold be implemented overnight. PK> Exactly the reason why it needs to be worked out properly and PK> agreed with as many Fidonet people as possible, before something PK> is started what I mean is that intiallly most IP nodes won't support this... it'll be a gradual change-over not a sudden one, and there's no way that I can for existing IP mailers to send crashmail without using a nodelist unless they are modified in some way... JB>> The nodelist is already in the control for the *C structure, it's JB>> their main reason for existing (as i read P4), if they kick you JB>> out of the nodelist a server on ypur PC will do you not good JB>> whatsoever. PK> Something somewhere has to define what makes up Fidonet so others PK> can get a feel for what Fidonet really is. The Nodelist is the PK> current master list. The Nodelist and the DNS records could be the PK> furture master list.. yeah, that would work. PK> If you get kicked out of the Nodelist, then you have exactly the PK> same procedures available to rectify that (via a Policy complaint PK> to the *C structure) PK>> The end node then has the ability to manage THEIR membership as PK>> they wish, OR use a "shared" server JB>> Is this about some *Cs disallowing certain nodelist entries JB>> (mainly those notconforming to FTS0005) they claim to do this JB>> because those "bad" entries cause problems with some systems. PK> Nothing like that at all, its just another option for distributing PK> responsibility ok... I was wondering what you were trying to achieve with this scheme I think I understand it now. JB>> don't worry about that, it's alreadly lost. PK> No it isn't. It just needs putting back on the rails by giving PK> those that made the "invalid" changes the option to correct the PK> mistakes Good luck with trying. PK>> No. The Mailer uses the Nodelist to perform the action defined by PK>> the Operator. The decision to Host Route, Network Route, Crash or PK>> Hold mail, is all with the Sysop. It is up to the Sysops(s) to PK>> ensure their system has the best chance possible of succeeding each time I read that it makes more sense. JB>>> however the present nodelist doesn't evem provide a way fr a PK> If I wish to crash a Netmail to someone, and a crash poll fails PK> for a reason I can't determine remotely, I then Host Route that PK> Netmail. The most likely reason for Crash failing that I have PK> found, is because the Nodelist entry is not strictly telling the PK> truth for some reason. This is becoming more and more of the real PK> situation these days, which is why I usually Route all my Netmail, PK> I don't usually bother to even try Crashing it ah..... JB>> There are HUBS (and NCs and atleast one RC) with no published JB>> POTS connection. PK> Then (IMHO) strictly speaking, it sounds like the *C above them is PK> not doing their job, an *C should ALWAYS be PSTN contactable PK> somehow to be compliant with P4. it does make some sense, the argument against it is that it's anacronistic, which also makes sense but so is the whole concept of zones nets for IP nodes, Requiring Hosts to be POTS capable is unlikely to be a permanent solution unless IP nodes can exist without a host. PK> I believe this is most important PK> for NC's, and also why it can be a huge bone of contention with PK> some people. I also understand that some Zones may view this PK> differently JB>>> how's a mailer supposed to know that it's the same destination JB>>> with just a different "name" PK>> But its not the same destination, its a different node number. PK> < text deleted > JB>> some of them _may_ be one sysop running multiple fido systems but JB>> most of them appear to me to be the same BBS but with too many JB>> connections to list on a single nodleist line (either line JB>> length, flags conflict, or some other cruft is forcing them to JB>> list multiple times) PK> Initial appearances can be very deceptive. A different type of PK> modem may require different flags to be shown, or hours of service PK> for different reasons. yes I understand many of the reasons. In my opinion it would be good if they could put all that in a single nodelist entry... obviously doing that without losing functionality would require major changes to the nodelist format. JB>> I'm aware of 1900 others. PK> Have you considered that you may be too picky over other peoples PK> reasons for doing this? I'm not saying they shouldn do it, I'm saying to could be done better. with a bnew nodelist format. PK> As I described above, and they are being used like that. The main problem I see with multi-listed systems is the mailer being able to recognise it as multi-listed and pick the most appropriate node so send the mail to. -=> Bye <=- --- # Origin: Sturgeon's Law: 90% of everything is crud. (3:640/531.42) * Origin: Baddog BBS (1:218/903) .