Subj : proposed new nodelist [2]
To : Malcolm Miles
From : Jasen Betts
Date : Tue Jul 16 2002 01:25 pm
Hi Malcolm.
15-Jul-02 16:16:42, Malcolm Miles wrote to Jasen Betts
MM> On Jul 14, 2002 Jasen Betts wrote to Peter Knapper:
PK>>> My current messages have been aimed at something completely new
PK>>> JUST for IP nodes, leave the PSTN side of things alone as they
PK>>> are
JB>>> Leave them broken? why?
PK>> The current Nodelist is NOT broken to me.
JB>> you are not all of fidonet...
MM> It is not broken for me either. Seeing that the current nodelist
MM> format has kept Fidonet running for at over 10 years, including
MM> supporting IP nodes, I don't think you could say it is broken.
It's brokren because it provides bogus contact information in some
instances.
MM> Granted, although the current format does support IP nodes, it is
MM> a kludge and what we are looking for here is a more ideal
MM> solution. If we can use standard Internet protocols and services
MM> then I believe that is the correct way to go. No point in
MM> inventing our own protocols and services which, in reality, nobody
MM> is going to code up
JB>> That's a good thing, but you're still relying on a nodelist of
JB>> sorts, all you've trimmed from it are the capability flags. if
JB>> you're a dedicated anarchist you may want to to a less structured
JB>> model like gnutella for instance. - something like that could
JB>> probably be modified for ftn
MM> Gnutella-type models are based on content, not nodes.
What I mean is some sort of host-less peer-to-peer information service.
practically indestructable.
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.
MM> And why is this a bad thing?
I dodn't say it was (and I'm not convinced that it is).
I was asking peter if that was one of his motives.
JB>> This is why I want to transform the nodelist into something that
JB>> can contany any useful information and is fututre proof and easy
JB>> to extend. then the won't have a technical argument against those
JB>> nodes.
MM> Totally disagree, a technical argument should be the only argument
MM> used to disallow nodes. If a node is causing problems on the
MM> network, they should be denied access to the network until they
MM> fix the problem
that makes sense... what I mean is whole debate over 000- "phone numbers"
and other related topics.
PK>> Of course it does. If the node is NOT listed as crash, then its
PK>> the callers fault for attempting to do so when they are not
PK>> supposed to. If I am unable to send mail direct to a node (for
PK>> whatever reason), then I Host Route it via the NC/HUB
JB>> There are HUBS (and NCs and atleast one RC) with no published
JB>> POTS connection.
MM> I believe that every Host node (and a host node does not have to
MM> be the NC)
Yeah the NC just cracks the whip right (if he can convice some other node
to be host that's fime) as I read the "rules" the NC is "resposible" for
seing that netmail moves...
MM> should have a POTS connection and should have the
MM> capability to get a netmail to any of the nodes in the net.
yeah, haing nodes in a net that can't get mail from the host would be a
problem.
MM> RCs don't have to route mail to their nets
They probably should if they have ION region independants...
(I expect you don't like them either)
There's a guy in zone 1 called Gregory_Deyss who seems to have found a way
to tunnel V32 over IP if the nodelist can be believed ;)
-=> Bye <=-
---
# Origin: Misery loves company, but company does not reciprocat (3:640/531.42)
* Origin: Baddog BBS (1:218/903)
