(The technical things I'm speaking about here CAN and would be solved. But I'm trying to point out the major differencies(?) here)


On one side, we have the DNS-system. Keeping the current nodelist as it is, and

using the Internet DNS-system for IP connections, with some extenstions and glue, to make it work with diffrent transfer protocol, on user selected ports, and (optionally) with HINFO, to provide system and sysop-name. Resulting in a solution providing all the information in the current nodelist, except the changed transport information. A completly robust solution.


On the other side, we have a a New Nodelist Format. A tag-based format, containing a list of nodes. And along with each node, a list of 0 or more transport defitiontions. Service type, and service specific data. For POTS(?), it will contain Phone number, along with modem-flags. For BinkP, IP and port. And so on. And in order for current nodes to prevail(?), public domain conversion tools will be provided, making it impossible for current nodes to even notice they are using a nodelist based on the new nodelist. A robust solution as well.


Why do I prefer a New Nodelist Format over the DNS-system?

There is one major thing making me believe a New Nodelist Format would be the best option for FidoNet. And I think you could call it network independency. You will be able to add new transfer methods as time passes. The New Nodelist Format could be used even after the death of the Internet. A solution that will

prevail.



Yes, I am a dreamer. But also a programmer and FidoNet SysOp that will work hard for the future existance of this lovely phenomena(?).


* Origin: ... (2:206/149.13)
--- SBBSecho/Win32 v2.00
* Origin: Baddog BBS (1:218/903)

On (20 Jul 02) Johannes Lundberg wrote to All...

Hello Johannes,

(The technical things I'm speaking about here CAN and would be solved.

But I'm trying to point out the major differencies(?) here)
Why do I prefer a New Nodelist Format over the DNS-system?

There is one major thing making me believe a New Nodelist Format would
be the best option for FidoNet. And I think you could call it network independency. You will be able to add new transfer methods as time
passes. The New Nodelist Format could be used even after the death of
the Internet. A solution that will prevail.

On a political format, I agree. My "fear" for Fidonet is that as we
move further into the Internet world, we become more "the Internet"
and less "Fidonet". Using the Internet DNS as a "Nodelist" for Fidonet
is another step in this direction.

I realize that Fidonet is technical and should be technical in its
reasoning, but there is, and will always be, some political areas that
combine with the technical.

Your above technical view is also combined with a political view and I
agree with it on both areas.

Yes, I am a dreamer. But also a programmer and FidoNet SysOp that will work hard for the future existance of this lovely phenomena(?).

I think we are all dreamers in Fidonet. Fidonet started, if you will,
as a "dream" of "can this be done". It's still being done when many
have said it should be dead and gone. :-)

Keep dreaming.

Regards,

Frank

http://pages.sbcglobal.net/flv
http://biseonline.com/r19

--- PPoint 3.01
# Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
* Origin: Baddog BBS (1:218/903)

Hi Johannes,

Resulting in a solution
providing all the information in the current nodelist,
except the changed transport information. A completly robust solution.

Agreed.

On the other side, we have a a New Nodelist Format. A tag-based format, containing a list of nodes. And along with each node, a
list of 0 or more transport defitiontions. Service
type, and service specific data. For POTS(?), it will
contain Phone number, along with modem-flags. For
BinkP, IP and port. And so on. And in order for current
nodes to prevail(?), public domain conversion tools
will be provided, making it impossible for current
nodes to even notice they are using a nodelist based on
the new nodelist. A robust solution as well.

I can certainly see the perspective for keeping a Fidonet nodelist, however I still think we need to be EXTREMELY careful about attempting to modify the current nodelist. Like it or not, we are likely to have POTS only nodes around for a while, so we CANNOT break any existing S/W they may be using. We MUST in all cases remain completely compatible with current practise.

There is one major thing making me believe a New
Nodelist Format would be the best option for FidoNet.
And I think you could call it network independency. You
will be able to add new transfer methods as time
passes. The New Nodelist Format could be used even
after the death of the Internet. A solution that will
prevail.

While I can also see your rationale here, I still think there are better ways of doing this. I don't believe we need a new nodelist format, simply because I do NOT believe we need a NEW Nodelist. What I think we really need in addition to the connectivity issues for IP nodes (such as using DNS for contact info), is a Fidonet MEMBERSHIP list, IE something that tells a Fidonet node what "other" Fidonet nodes actually exist. It seems (to me) that this is what people

are really talking about. Somehow we need to marry that need up with the technical information need, without breaking the current Nodelist. Thats no small task in itself.

I see the simplest "solution" for the Nodelist, is to provide a method for "listing" IP nodes, that does not break current POTS nodes. All that needs to happen to the Nodelist is for Fidonet to come up with an agreed way of pointing

people to the DNS for contact info.

Yes, I am a dreamer. But also a programmer and FidoNet
SysOp that will work hard for the future existance of
this lovely phenomena(?).

And yes, surely most of us are dreamers too....;-) I am VERY grateful that we still have (a few) S/W developers around Fidonet. Without them, Fidonet can do very little.

My IP node works by using all the little bits I have put together myself (mainly OS/2 Rexx coding as a wrapper to executables), the only thing missing is a "common" IP Nodelist type format, and all that needs is an agreement between all of Fidonet over how its going to handle this part of the problem.

Cheers...........pk.


--- Maximus/2 3.01
# Origin: Another Good Point About OS/2 (3:772/1.10)
* Origin: Baddog BBS (1:218/903)

On a political format, I agree. My "fear" for Fidonet is that as we
move further into the Internet world, we become more "the Internet"
and less "Fidonet". Using the Internet DNS as a "Nodelist" for Fidonet
is another step in this direction.

Locking FidoNet to a certain "physical" network is in my opinion a bad thing. That's why a new nodelist format would be to prefer. To make FidoNet compatible

with the future.a

I think we are all dreamers in Fidonet. Fidonet started, if you will,
as a "dream" of "can this be done". It's still being done when many
have said it should be dead and gone. :-)

True.

Keep dreaming.

I will. :-)


* Origin: ... (2:206/149.13)
--- SBBSecho/Win32 v2.00
* Origin: Baddog BBS (1:218/903)

I can certainly see the perspective for keeping a Fidonet nodelist, however I still think we need to be EXTREMELY careful about attempting to modify the current nodelist. Like it or not, we are likely to have POTS only nodes around for a while, so we CANNOT break any existing S/W they may be using. We MUST in all cases remain completely compatible with current practise.

I totally agree with you here. Whatever solutions we may come up with, current nodes should be able to keep running without problems.

[answers to the other comments later on]

My IP node works by using all the little bits I have put together myself (mainly OS/2 Rexx coding as a wrapper to executables), the only thing missing is a "common" IP Nodelist type format, and all that needs is an agreement between all of Fidonet over how its going to handle this part
of the problem.

I used to run OS/2 myself. Switched to Debian/GNU Linux for, well, quite some years now. Having bort regular modem-access (BBS/Fido), and BinkP.


* Origin: ... (2:206/149.13)
--- SBBSecho/Win32 v2.00
* Origin: Baddog BBS (1:218/903)

On (21 Jul 02) Johannes Lundberg wrote to Frank Vest...

Hello Johannes,

On a political format, I agree. My "fear" for Fidonet is that as we
move further into the Internet world, we become more "the Internet"
and less "Fidonet". Using the Internet DNS as a "Nodelist" for Fidonet
is another step in this direction.

Locking FidoNet to a certain "physical" network is in my opinion a bad thing. That's why a new nodelist format would be to prefer. To make FidoNet compatible with the future.a

This is true. I just don't think that moving to the Internet is so
good either. IMHO, Fidonet should remain a separate network, but use
the Internet, or whatever is available, to provide Fidonet services.

As a thought: A new format could keep us as a separate network, but
still allow us to use whatever means needed to provide Fidonet mail.
The Internet itself is a bunch of different networks that use a
"common" medium to transfer files, mail and such. Fidonet is no
different. In fact, we use the DNS now. When an IP mailer makes use of
the Internet to connect to another IP mailer, does it not use a DNS to
look up the address.

We can use the DNS or whatever is available to provide Fidonet
services, but let's stay Fidonet.


Regards,

Frank

http://pages.sbcglobal.net/flv
http://biseonline.com/r19

--- PPoint 3.01
# Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
* Origin: Baddog BBS (1:218/903)

Hi Peter.

I can certainly see the perspective for keeping a Fidonet
nodelist, however I still think we need to be EXTREMELY careful
about attempting to modify the current nodelist.

Yeah the SLF should be frozen or even rolled back a bit.

Like it or not,
we are likely to have POTS only nodes around for a while, so we
CANNOT break any existing S/W they may be using.

Gotta keet thap old internet software working too.

We MUST in all cases remain completely compatible with current practise

I'd prefer something that works better.

While I can also see your rationale here, I still think there are
better ways of doing this. I don't believe we need a new nodelist
format, simply because I do NOT believe we need a NEW Nodelist.

So this DNS thing you're pushing is not a new nodelist?

We need a new nodelist format because the old one is full and that's
stifling development.

What I think we really need in addition to the connectivity issues
for IP nodes (such as using DNS for contact info), is a Fidonet
MEMBERSHIP list, IE something that tells a Fidonet node what
"other" Fidonet nodes actually exist. It seems (to me) that this
is what people are really talking about.

According to P4 the nodelist is the membership list.

Somehow we need to marry
that need up with the technical information need, without breaking
the current Nodelist. Thats no small task in itself

I see the simplest "solution" for the Nodelist, is to provide a
method for "listing" IP nodes, that does not break current POTS
nodes.

List them as PVT... nothing radical there.

All that needs to happen to the Nodelist is for Fidonet to
come up with an agreed way of pointing people to the DNS for
contact info

probably the best way is to use their fidonet address in fidonet.org

My IP node works by using all the little bits I have put together
myself (mainly OS/2 Rexx coding as a wrapper to executables), the
only thing missing is a "common" IP Nodelist type format, and all
that needs is an agreement between all of Fidonet over how its
going to handle this part of the problem

So go for it, find some DNS info work out your formats, have a lookd at
the new BIND (dunno if it'll run on OS/2, but it does do dynamic DNS which
is probably useful.) ... just don't expect the rest of us to live with
the current broken nodelist. (if it wasn't broken there wouldn't be people trying to fix it)

Bye <=-

---
# Origin: rights are what can't be taken from you (3:640/531.42)
* Origin: Baddog BBS (1:218/903)

Why do I prefer a New Nodelist Format over the DNS-system?

There is one major thing making me believe a New Nodelist
Format would be the best option for FidoNet. And I think you
could call it network independency.

[trim]

eggggzactly!!!

Yes, I am a dreamer. But also a programmer and FidoNet SysOp
that will work hard for the future existance of this lovely
phenomena(?).

fidonet was built from dreams and some hard work... all the politics came later...

)\/(ark


* Origin: (1:3634/12)
--- SBBSecho/Win32 v2.00
* Origin: Baddog BBS (1:218/903)

Hi Jasen,

We MUST in all cases remain completely compatible
with current practise

I'd prefer something that works better.

So create something NEW that works alongside the old stuff without breaking it...

While I can also see your rationale here, I still think there are
better ways of doing this. I don't believe we need a new nodelist
format, simply because I do NOT believe we need a NEW Nodelist.

So this DNS thing you're pushing is not a new nodelist?

In itself, definately not, because DNS is a distributed Database. I suppose someone in Fidonet could run a DNS parser across the Fidonet domain and create a file that could then be "merged" with the POTS Nodelist entries to create the

"enhanced" Nodelist, but I question if that's really necessary.

Ok, each ZC could generate the IP segment for their Zone and then attach that to the regular nodelist that they issue. However you have to remember what the nodelist is for, its so a MACHINE can contact other MACHINES, its not supposed to be for human consumption. Yes, humans can read it and use it, but that is not its primary purpose. And then the ONLY purpose such a modified Nodelist would have is to validate the Nodes that belong to Fidonet. Gone is its original purpose of helping people to contact each other.

No... I am not sure we need something exactly like the Nodelist, at least not for the current purpose of it...

We need a new nodelist format because the old one is full and that's stifling development.

As has been stated many times, the current Nodelist is far from full, its main problem is that its design does not allow it to be used for the new communications needs of Fidonet.

What I think we really need in addition to the connectivity issues
for IP nodes (such as using DNS for contact info), is a Fidonet
MEMBERSHIP list, IE something that tells a Fidonet node what
"other" Fidonet nodes actually exist. It seems (to me) that this
is what people are really talking about.

According to P4 the nodelist is the membership list.

For the current environment yes, but maybe that should change...

I see the simplest "solution" for the Nodelist, is to provide a
method for "listing" IP nodes, that does not break current POTS
nodes.

List them as PVT... nothing radical there.

Exactly, thats how I think it could work, PVT node with a flag pointing to the DNS entry. Keep it very very simple. However we also need that "new" thing to support the IP nodes and then figure out how to tie the 2 halves back together in a way that allows the halves to talk to each other...

Cheers............pk.

--- Maximus/2 3.01
# Origin: Another Good Point About OS/2 (3:772/1.10)
* Origin: Baddog BBS (1:218/903)

On Jul 23, 2002 Peter Knapper wrote to Jasen Betts:

List them as PVT... nothing radical there.

Exactly, thats how I think it could work, PVT node with a flag
pointing to the DNS entry.

No need for a flag to point to the DNS entry. All nodes have an implicit address of f999.n999.z3.fidonet.net/org. Use that to query the DNS for the IP address.

Best wishes,
Malcolm

--- timEd/386 1.10.y2k+
* Origin: Tardis BBS +61 3 9819 7093 (3:633/260)

Hi Malcolm,

List them as PVT... nothing radical there.

Exactly, thats how I think it could work, PVT node with a flag
pointing to the DNS entry.

No need for a flag to point to the DNS entry. All nodes
have an implicit address of
f999.n999.z3.fidonet.net/org. Use that to query the DNS
for the IP address.

True, howver I was trying to come up with a way of adding useful information to
the Nodelist, not just the DNS. I think it desirable to have both environments complement each other wherever possible.

Cheers.............pk.


--- Maximus/2 3.01
* Origin: Another Good Point About OS/2 (3:772/1.10)