Hiya everyone,
I just did a 30 day rescan of the echo, and was returned one message.
If this is due to a pass-thru on my uplink's system, please let me
know what has beed going on the last month or so (in nutshells
please).
I would ask all IP programmers to chime in here on this, and express
their collective thoughts of feasibility. :)
Hiya everyone,
Umm... maybe? If anyone is here. :)
I keep 10 days on my Point system. You are the first in at least that
long. :/ The echo is passthrough on my Node/BBS system.
I would ask all IP programmers to chime in here on this, and express their collective thoughts of feasibility. :)
I'm not a programmer.... My $.02 is that Fidonet really doesn't need a
new format.
I just did a 30 day rescan of the echo, and was returned
one message. If this is due to a pass-thru on my uplink's
system, please let me know what has beed going on the
last month or so (in nutshells please).
i go back to Nov 11 and yours is the 24th message... frakn vest's reply is and this one will be 26... there hasn't been a whole lot going on because s backbone distributions do not view this area as an "official" "admin-type"
additionally, traditionally, this has been the gathering place of developer and spec creators while the FTSC gathered here and in other places...
I just did a 30 day rescan of the echo, and was returned
one message. If this is due to a pass-thru on my uplink's
system, please let me know what has beed going on the
last month or so (in nutshells please).
i go back to Nov 11 and yours is the 24th message...
I just did a 30 day rescan of the echo, and was returned
one message. If this is due to a pass-thru on my uplink's
system, please let me know what has beed going on the
last month or so (in nutshells please).
i go back to Nov 11 and yours is the 24th message...
I have about 350 messages here, dating back to Feb 2002. Yell
if you want them, I can rescan and deliver them (binkD of
course...;-)) to whatever address you wish.
Be that as it may, we should do what we can to get people here to
touch bases and discuss implimentation of the different ideas debated there.
I would ask all IP programmers to chime in here on this, and express their collective thoughts of feasibility. :)
I'm not a programmer.... My $.02 is that Fidonet really doesn't need a
new format.
You'll agree it needs /something/ though, right? ;-)
I've read several threads on this and that solution, and believe that
an expanded NL format will be the easiest to accomplish and
distribute. At least, I'd like the possibility investigated... :)
I just did a 30 day rescan of the echo, and was returned
one message. If this is due to a pass-thru on my uplink's
system, please let me know what has beed going on the
last month or so (in nutshells please).
It was suggested to me that this echo would be a great place to
start discussing possible nodelist format changes, and the
software which would utilize them.
I just did a 30 day rescan of the echo, and was returned one
message. If this is due to a pass-thru on my uplink's system,
please let me know what has beed going on the last month or so (in nutshells please).
Some of you are aware that elections are ongoing for new standing
members of the FTSC. Once elected, it is my hope that the new
panel will take a different approach to reaching and applying
standards that can incorporate IP listings, without compromising
current PSTN methods.
A lot has been debated regarding flags and fields in the current
NL format, but recent tests have (so far) shown promise for an
extended NL format that make use of ;E(rror) lines, which could be
used by modifying currently developing mailers, and a seg editor
to compile it.
I would ask all IP programmers to chime in here on this, and
express their collective thoughts of feasibility. :)
Bye <=-
I'm not a programmer.... My $.02 is that Fidonet really doesn't need a
new format.
You'll agree it needs /something/ though, right? ;-)
No (wrong).
I've been through this before in this echo. It's a mess. :-) What
needs to be done, IMHO, is to get the specs/standards in order. Then
get programs that are still being developed to follow those specs and standards.
It was suggested to me that this echo would be a great place to
start discussing possible nodelist format changes, and the
software which would utilize them.
we were kicking that ball around a bit a few months back,
we came up with a few different proposals for a new (IE non-slf)
nodelist formats and little else
uunfortunately FTSC doesn't make the rules, the ZCC does AFAICT.
A lot has been debated regarding flags and fields in the current
NL format, but recent tests have (so far) shown promise for an extended NL format that make use of ;E(rror) lines, which could be used by modifying currently developing mailers, and a seg editor
to compile it.
it'll require programmers to think a bit more when reading the nodelist and code their software to look-ahead a bit, but that shouldn't be a problem for experienced programmers.
I have about 350 messages here, dating back to Feb 2002. Yell
if you want them, I can rescan and deliver them (binkD of
course...;-)) to whatever address you wish.
that would be fine... send'em to this address... please
also include a netmail so that i will know they are
here...
You'll agree it needs /something/ though, right? ;-)No (wrong).
I have a lot of respect for you and your opinions on many topics, but
in this I think you are a bit blinded. Why, I have no idea. Nearly everyone here has agreed that the current NLF is insufficient to deal
with current (much less emerging) technology.
I've been through this before in this echo. It's a mess. :-) What
needs to be done, IMHO, is to get the specs/standards in order. Then
get programs that are still being developed to follow those specs and standards.
My point exactly. I'd like to see both happen at the same time.
We have to condescend to the lowest common denominator (legacy SW),
and concentrate of current and emerging software.
Let me go through this a little better and see what gets
stirred up.
Binkp, telnet and ftp are protocols for IP. Just as zedzap,
emsi, zmodem and others are protocols for POTS.
Of course, the argument is that with POTS, the protocols
are negotiated upon connection. There is a thread in the
FTSC_PUBLIC echo that is attempting to work out just such
a thing for IP Nodes.
Let me go through this a little better and see what gets
stirred up.
you got it! <<GG>>
Binkp, telnet and ftp are protocols for IP. Just as zedzap,
emsi, zmodem and others are protocols for POTS.
i use zedzap, emsi, zmodem, and others on IP with relatively no problems...
Of course, the argument is that with POTS, the protocols
are negotiated upon connection. There is a thread in the
FTSC_PUBLIC echo that is attempting to work out just such
a thing for IP Nodes.
it can be done in IP mailers just exactly like it is done in POTS mailers... trouble is, it seems, that coders don't want to or haven't figured out how ;-(
I have about 350 messages here, dating back to Feb 2002. Yell
if you want them, I can rescan and deliver them (binkD of
course...;-)) to whatever address you wish.
that would be fine... send'em to this address... please
also include a netmail so that i will know they are
here...
A ZIP file is being dropped off as I type...
Put the IP or domain in the "name" field of the Nodelist.
Standardize an IP flag ("IP" would do) that tells IP
mailers to access the finger daemon on the default "Fidonet" port at
the IP/domain address listed to get the information on what the Node
is capable of and what port(s).
With this in place, the current Nodelist would work for "legacy"
mailers since there is nothing really changed in it...
NR mode was set by my recent addition of the defnode setting in binkd...
one thing that i've discovered that that has led to is
that i must define all the fidonet addresses of those
nodes connecting to me... at least, it appears that
way, so far... two other systems could not connect due
to their presentation of all fidonet akas instead of
just the one we use between us... i have to wait on the
others to connect and see what happens with them...
several are flying akas in other networks...
Ok, I read the entire message first, however there is at least one
major section that I feel needs further discussion.
Put the IP or domain in the "name" field of the Nodelist.
The probem I see is this. The "System Name" field was designed for ...
the System name. If you now wish to use it for something else, you are going to confuse a lot of people and S/W, simply because of this one apparently simple change.
No person, and no S/W, will be able to guarantee what data they are reading from that field. There is also, no "safe" way to determine if
one should use the field or not. As an IP node, I may prefer to have
my system name distinct, and not follow any particular Domain name,
and yet you are now saying that I can't do that any more. The net
result from doingthis will make it VERY hard for Fidonet members to
accept this convention (IMHO).
Standardize an IP flag ("IP" would do) that tells IP
mailers to access the finger daemon on the default "Fidonet" port at
the IP/domain address listed to get the information on what the Node
is capable of and what port(s).
A couple of things here, I can't really see a "Finger" daemon as being necessary, the functionality is minimal, and the similar capability
can be determined by "testing" the result of each "open". Locating the service ports can be done in the DNS (with SRV records), again
With this in place, the current Nodelist would work for "legacy"
mailers since there is nothing really changed in it...
Agreed, with all the new bits added elsewhere, the current Nodelist
will work purfectly for PSTN nodes.
Umm... maybe? If anyone is here. :)
Now, put this into operation. Put the IP or domain in the "name" field
of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP mailers to access the finger daemon on the default "Fidonet" port at
the IP/domain address listed to get the information on what the Node
is capable of and what port(s).
The net
result from doing this will make it VERY hard for Fidonet members to accept this convention (IMHO).
No software now uses XML either. The 'trick" with any idea is to get
it in use and software to surpport it. The rest is getting the idea to become a standard.
If you don't list your IP or domain, you don't fly the IP flag.
If you don't list a phone number in the Nodelist, you fly the
PVT flag. Simple, eh?
It was hard for Fidonet members to accept the Internet as a transport medium a few years ago too. Will it be easier to accept any other convention? :)
Ok. DNS is fine. I really don't care what is used. Telepathy is ok for
all I care... as long as it works. :-)
Agreed, with all the new bits added elsewhere, the current Nodelist
will work purfectly for PSTN nodes.
I think it will work for IP nodes as well. YMMV.
I just don't see having two Nodelists... one for my pots mailer and
one for my IP mailer. Or, one that is converted to another where
needed. To maintain two Nodelist formats on my system seems redundant
and taking up space for the sake of taking up space.
One Nodelist with a flag that tells the IP mailer that this is an IP capable Node with a "phone number" of <some.domain> while the pots
mailer will look for a phone number in the "phone" field and use it if configured to do so seems better to me.
Now, put this into operation. Put the IP or domain in the "name" field
of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP mailers to access the finger daemon on the default "Fidonet" port at
the IP/domain address listed to get the information on what the Node
is capable of and what port(s).
Yup, read the whole thing, and agree in general.
Just like to make one comment on what to do with the domain name.
It might be vanity on my part, or ego, but my bbs /IS/ called
Milky Way.
It's not milkyway.somewhere.com just as my name isn't glewicky@somewhere.com
Dammit, I am 2 personae. I am Gordon Lewicky and I am Milky Way
and I am damn proud of both names! :)
No software now uses XML either. The 'trick" with any idea is to get
it in use and software to surpport it. The rest is getting the idea to become a standard.
Thats why I can't see it flying, people need to see value with the
idea, and if the idea adds confusion, then there is lttle value...
If you don't list your IP or domain, you don't fly the IP flag.
You are of course, then saying there is no other possible way to find
out how to contact that node, which of course is not correct....;-)
If you don't list a phone number in the Nodelist, you fly the
PVT flag. Simple, eh?
Because there was no other way to do it for PSTN nodes, however with
IP nodes we have other ways. Why propagate something that is no longer valid?
It was hard for Fidonet members to accept the Internet as a transport medium a few years ago too. Will it be easier to accept any other convention? :)
The speed of acceptance of the Internet was directly related to how
long it took for the benefits to be seen as worthwhile to the end
node. Certain nodes had no troube using the Internet back in 1992,
however most agreed the cost of doing that was quite high. As the cost droppped, more and more people moved over to that way of working, its really just a natural progression.
Ok. DNS is fine. I really don't care what is used. Telepathy is ok for
all I care... as long as it works. :-)
I would need to see DIRECT proof that it works first........;-)
Agreed, with all the new bits added elsewhere, the current Nodelist
will work purfectly for PSTN nodes.
I think it will work for IP nodes as well. YMMV.
Yes, it CAN work for IP, however I am still slightly concerned with
some of the suggestions and the possible ramifications that might
result.
I just don't see having two Nodelists... one for my pots mailer and
one for my IP mailer. Or, one that is converted to another where
needed. To maintain two Nodelist formats on my system seems redundant
and taking up space for the sake of taking up space.
Agreed, One Nodelist, but UNMANGLED and using other resources (eg DNS) where it helps.
One Nodelist with a flag that tells the IP mailer that this is an IP capable Node with a "phone number" of <some.domain> while the pots
mailer will look for a phone number in the "phone" field and use it if configured to do so seems better to me.
Its this type of mangling that concerns me....;-(
I have a lot of respect for you and your opinions on many topics, but in this I think you are a bit blinded. Why, I have no idea. Nearly everyone here has agreed that the current NLF is insufficient to deal with current (much less emerging) technology.
Agreement? Everyone?
Let me go through this a little better and see what gets stirred up.
The Nodelist is a comma delimited file used by Fidonet mailers (and
other programs) to determine /where/ to connect.
Now, using that and your statement, along with the arguments of others
that the Nodelist can not show binkp, telnet and other connection
information or emerging technologies, I put it forth that the Nodelist could not and did not work properly with POTS to begin with. There is
no indication that my POTS mailer can do emsi, zedzap or other
protocols.
The Nodelist gives information on where to contact Nodes. In the POTS realm, that is the phone number. In the IP world, that is the IP
address or domain name. Protocols are not shown in the Nodelist, and
for good reason. Imagine if there had to be a flag for emsi, zedzap
and all the other POTS protocols. Taking this further, consider POTS
Nodes with multiple phone lines. What if each one wanted to list each
line with different protocols? One line does emsi only while others
will handle other protocols. <whew!>
Of course, the argument is that with POTS, the protocols are
negotiated upon connection. There is a thread in the FTSC_PUBLIC
echo that is attempting to work out just such a thing for IP Nodes.
but, if successful, this would remove the need for protocol flags in
the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would bring the Nodelist back to what it should be. A comma delimited file
for Fidonet mailers to determining "how" to contact other Fidonet
mailers instead of what "protocols" to use to make contact.
Even in the IP mailers, there is no indication that the telnet mailer
can do emsi, zedzap or other protocols... but some can. :-)
Now, put this into operation. Put the IP or domain in the "name" field
of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP mailers to access the finger daemon on the default "Fidonet" port at
the IP/domain address listed to get the information on what the Node
is capable of and what port(s).
To go one step further... It has been pointed out that many IP mailers don't rely on the Fidonet Nodelist anyway.
To anyone that wants to chop this reply up and argue each paragraph,
Agreement? Everyone?
Please read me correctly. I said 'nearly everyone'.
Let me go through this a little better and see what gets stirred up.
OK... but you may not like licking the spoon. ;-)
The Nodelist is a comma delimited file used by Fidonet mailers (and
other programs) to determine /where/ to connect.
And 'how/to what extent' to connect.
Now, using that and your statement, along with the arguments of others
that the Nodelist can not show binkp, telnet and other connection
Correct... in it's current format.
information or emerging technologies, I put it forth that the Nodelist could not and did not work properly with POTS to begin with. There is
I beg to differ. FTS were written FOR pots, and "adjusted" for IP.
All known analog modem connection methods can be so indicated in the
NL.
no indication that my POTS mailer can do emsi, zedzap or other
protocols.
This is independant of the NL, as session protocols are inherently negotiated at connect. No such info is needed in the NL (for POTS).
The Nodelist gives information on where to contact Nodes. In the POTS realm, that is the phone number. In the IP world, that is the IP
address or domain name. Protocols are not shown in the Nodelist, and
for good reason. Imagine if there had to be a flag for emsi, zedzap
and all the other POTS protocols. Taking this further, consider POTS
<handing over box of Kleenex>
You're making this sound more complex than it needs. This is because you're putting different connection types in the same basket. I will
help by understanding that this is NOT about POTS, or POTS session
connect methods. Those are well documented and applied, and are not
in need of revision.
Nodes with multiple phone lines. What if each one wanted to list each
line with different protocols? One line does emsi only while others
will handle other protocols. <whew!>
Again, this session information is automatically negotiated between
the two mailers (not users, btw). Why would one need to differentiate this in the NL? If a particular mailer cannot negotiate a connection, it's not writte within FTS specs.
<retrieving Kleenex, wiping brow>
Of course, the argument is that with POTS, the protocols are
negotiated upon connection. There is a thread in the FTSC_PUBLIC
echo that is attempting to work out just such a thing for IP Nodes.
Been reading that, and there are some good ideas there... all of which should follow the same methods as POTS... built into the mailer, not
the nodelist. I'm pretty sure that some of the IP authors neglected
to take into consideration future technologies, just as the FTSC...
which is why we are here today.
but, if successful, this would remove the need for protocol flags in
the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would bring the Nodelist back to what it should be. A comma delimited file
for Fidonet mailers to determining "how" to contact other Fidonet
mailers instead of what "protocols" to use to make contact.
I'm not sure this is entirely possible, or even desired. There are
too many factors in IP connection and transport. Too much depends
on 3rd parties (ISP's, DS's, FW's, etc) to incorporate every sort
of possible condition into a mailer(s). We'll still need the NL for
a good share of it.
Even in the IP mailers, there is no indication that the telnet mailer
can do emsi, zedzap or other protocols... but some can. :-)
Again, the abaility to determine that should be built into the
mailers. If it isn't, it's not compliant, and shouldn't be used.
Now, put this into operation. Put the IP or domain in the "name" field
of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP mailers to access the finger daemon on the default "Fidonet" port at
the IP/domain address listed to get the information on what the Node
is capable of and what port(s).
Fine.... show me an example entry that can do this... without breaking current software.
To go one step further... It has been pointed out that many IP mailers don't rely on the Fidonet Nodelist anyway.
Don't they extract the IP info from the NL to create their proprietary dialing list? If not, who/what tells them?
To anyone that wants to chop this reply up and argue each paragraph,
<putting away jigsaw>
I did read your entire message before replying, as I usually do. :)
I'll leave the technical arguments to the techies, and try to learn
as I read. I don't perport to know a whole lot about the Inet end
of this debate... only that what we have isn't working, and will get
worse as time and technology progress.
If you don't list your IP or domain, you don't fly the IP flag.
You are of course, then saying there is no other possible way to find
out how to contact that node, which of course is not correct....;-)
Not at all. Each Node can set up contacts with each other without the
use of any Nodelist. Even POTS Nodes can do this. :)
As the cost
droppped, more and more people moved over to that way of working, its really just a natural progression.
And as a method of listing Fidonet Nodes in the Nodelist becomes used more, it will be moved to as well.
Telepathy is ok forall I care... as long as it works. :-)
I would need to see DIRECT proof that it works first........;-)
You and me both. (I'm sending you my connection info via telepathy
right now. Did you receive it??) :-))
One Nodelist with a flag that tells the IP mailer that this is an IP capable Node with a "phone number" of <some.domain> while the pots
mailer will look for a phone number in the "phone"
field and use it if configured to do so seems better to me.
Its this type of mangling that concerns me....;-(
How so?
All that is being done is adding a flag to tell the IP mailer
to look in the DNS record for <IP or domain> or poll a finger daemon
or some such "standard" Internet listing to get the connection
information (IE: protocol-port).
I understand your point. Would the "location" field be better? Or is where you live as important to you as your name and your system name?
Using a flag to indicate the IP or domain address is fine too. As long
as it is /one/ flag instead of one for every IP protocol.
Now, using that and your statement, along with the arguments of others
that the Nodelist can not show binkp, telnet and other connection
Correct... in it's current format.
Not relevant in the context of the rest of the sentence.
information or emerging technologies, I put it forth that the Nodelist could not and did not work properly with POTS to begin with.
All known analog modem connection methods can be so indicated in the NL.
Yes and No. The phone number is listed and the type (name flag of the) mailer. XA for Frontdoor and so forth. Nothing about connection
methods as far as protocols are concerned.
no indication that my POTS mailer can do emsi, zedzap or other
protocols.
No need for binkp to be listed either. That protocol can be listed in
the "mailer name" as above for POTS mailers. In reality, I don't know
why the mailer flags (XA, XX and such) need to be there anyway. I'm
sure there is a good reason, but using this same good reason, the IP
flag that is proposed could be made into a "mailer" flag.
Protocols are not shown in the Nodelist, and
for good reason. Imagine if there had to be a flag for emsi, zedzap
and all the other POTS protocols. Taking this further, consider POTS
Again, this session information is automatically negotiated between the two mailers (not users, btw). Why would one need to differentiate this in the NL? If a particular mailer cannot negotiate a connection, it's not writte within FTS specs.
Beg to differ. The only protocol required for POTS by Fidonet is FTS-1 (Xmodem, I believe). If my mailer only does Xmodem, I'm still within requirements.
but, if successful, this would remove the need for protocol flags in
the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would bring the Nodelist back to what it should be. A comma delimited file
for Fidonet mailers to determining "how" to contact other Fidonet
mailers instead of what "protocols" to use to make contact.
Even in the IP mailers, there is no indication that the telnet mailer
can do emsi, zedzap or other protocols... but some can. :-)
Again, the abaility to determine that should be built into the mailers. If it isn't, it's not compliant, and shouldn't be used.
Then BinkD, Irex and several other mailers are not compliant. I can
not connect to BinkD or Irex and make a negotiated connection. I have
to tell them that the system I'm calling does binkp, ftp or whatever protocol. It's not negotiated.
Fine.... show me an example entry that can do this... without breaking current software.
That's not relevant in this context. There is no software that can...
FWIW, I don't think you and I are that far apart on this thing. I hope
that with time, we will get closer.
If you don't list your IP or domain, you don't fly the IP flag.
You are of course, then saying there is no other possible way to find
out how to contact that node, which of course is not correct....;-)
Not at all. Each Node can set up contacts with each other without the
use of any Nodelist. Even POTS Nodes can do this. :)
Ok, I think I can see where you are heading. Let me re-phrase my
statement slightly. By saying a sysop can't list an IP FLAG if he does
not list the his domain name in the Nodelist, you are placing a
limitation on the PUBLIC method of telling people about your system
that can work perfectly well.
A PVT listing tells you its PVT, but it does not list its Phone number
in the Nodelist and yet you may still be able to contact that node if privately given the number and hours of service.
I don't see why there is a need to penalise IP operations over PSTN in such a manner.
droppped, more and more people moved over to that way of working, its really just a natural progression.
And as a method of listing Fidonet Nodes in the Nodelist becomes used more, it will be moved to as well.
When Fidonet started, it NEEDED to create the Nodelist, there was no common PHONE directory available to look up. With IP, such a directory already exists (the DNS). If Fidonet ignores that, then you will end
Telepathy is ok forall I care... as long as it works. :-)
I would need to see DIRECT proof that it works first........;-)
You and me both. (I'm sending you my connection info via telepathy
right now. Did you receive it??) :-))
First prove to me that you sent it, before I confirm if I did receive
it (or not).........;-))
One Nodelist with a flag that tells the IP mailer that this is an IP capable Node with a "phone number" of <some.domain> while the pots
mailer will look for a phone number in the "phone"
field and use it if configured to do so seems better to me.
Its this type of mangling that concerns me....;-(
How so?
Well it depends on how you read what you said above. If the DATA for <some.domain> goes INTO the nodelist, just where are you going to put
it without breaking existing functionality of the Nodelist? Change the System name or Location fields, and you difuse the functionality of
those fields for all nodes (not just PSTN). Current standards prohibit using a FLAG for that info, so I don't see how one can keep that info
in the Nodelist without breaking SOMETHING at least.
However, if you NOT suggesting to put <some.domain> into the Nodelist, then the MOST practical place left is the DNS, which is fine with me.
I just thought of another possibilty. Fidonet constructs a server that provides ALL that info from one single point (an online Nodelist???), allowing Fidonet to retain "control" over its own destiny. Except that means Fidonet re-invents the wheel by re-creating what already exists,
but that may just keep some people happy........;-)
All that is being done is adding a flag to tell the IP mailer
to look in the DNS record for <IP or domain> or poll a finger daemon
or some such "standard" Internet listing to get the connection
information (IE: protocol-port).
However we don't really need a Finger Daemon, the IBN flag in the
Nodelist is all thats needed to tell people to find BinkP by looking
up the DNS for that node.
Now IF its also necessary to advise people that a different PORT is to
be used, then we have a couple of options, list the PORT in the FLAGS field, or use SRV type DNS records for this purpose. Personally, I
prefer to use the DNS for this (although I doubt that any Fidonet S/W currently exists that can use SRV records), because its related more
to DNS than Nodelist type data.
I understand your point. Would the "location" field be better? Or is where you live as important to you as your name and your system name?
Well, if we're gonna throw out the geography rule, then to me at
least, location is important since we can no longer depend on
zone, region, net! And I sure can't figure out where
bbs.micronet.com is! :)
Actually, I'm getting somewhat annoyed at this trend to
impersonality in this supposed network of computer enthusiasts.
If I want impersonality, I'll go on the net.
I happen to enjoy knowing who the sysop is, what their bbs name is,
and where they park their butt! :)
Using a flag to indicate the IP or domain address is fine too. As long
as it is /one/ flag instead of one for every IP protocol.
I may be wrong, but basically there are only 2 different connect addresses, domain name or ip, and email addy. Surely we can
accomodate these 2 somewhere in the line without mucking around
with sticking them where they shouldn't be.
Seems to me that the coupling the addy with the applicable inet
connect flag works or we develop new fields or files for inet
addressing and leave the connect flags denoting non-standard
ports.
But this kludging addys into various former fields is
exacly that, kludging.
Now, using that and your statement, along with the arguments of others
that the Nodelist can not show binkp, telnet and other connection
Correct... in it's current format.
Not relevant in the context of the rest of the sentence.
information or emerging technologies, I put it forth that the Nodelist could not and did not work properly with POTS to begin with.
Again... currently... and quite relevant. AAMOF, we find ourselves
in a worse position than back then. Up until now, there was room to
add provisions for additional modem protocols (which were the only
type of changes). We are now at a crossroad, where the NL can no
longer be kludged to accomodate all the desired info, and still fall within the limitations of SW that reads/processes it.
<hearing echo>
No need for binkp to be listed either. That protocol can be listed in
the "mailer name" as above for POTS mailers. In reality, I don't know
why the mailer flags (XA, XX and such) need to be there anyway. I'm
sure there is a good reason, but using this same good reason, the IP
flag that is proposed could be made into a "mailer" flag.
That's a possibility. I think the mailer-specific flag was because
not all mailers had all session capacities, and was a means to help
newer mailers connect easier, and still maintain backward
compatibility.
Someone will correct me if I'm wr...wr...wro... well, you know. ;-)
Protocols are not shown in the Nodelist, and
for good reason. Imagine if there had to be a flag for emsi, zedzap
and all the other POTS protocols. Taking this further, consider POTS
I don't undersatnd why you leep bringing session negotiation methods
Beg to differ. The only protocol required for POTS by Fidonet is FTS-1 (Xmodem, I believe). If my mailer only does Xmodem, I'm still within requirements.
Now you're complicating things further by bring in another variety
of fruit... transfer protocols. Focus on the areas that need to be addressed.
but, if successful, this would remove the need for protocol flags in
the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would bring the Nodelist back to what it should be. A comma delimited file
for Fidonet mailers to determining "how" to contact other Fidonet
mailers instead of what "protocols" to use to make contact.
If the standards favor DNS, yes. I don't think that's going to
fly as the only method of addressing. My money's on ESLNL format,
or (Gawd<tm> forbid) XML.
Again, the abaility to determine that should be built into the mailers. If it isn't, it's not compliant, and shouldn't be used.Then BinkD, Irex and several other mailers are not compliant. I can
not connect to BinkD or Irex and make a negotiated connection. I have
to tell them that the system I'm calling does binkp, ftp or whatever protocol. It's not negotiated.
I don't believe standards have been written for IP session
connections. I'd have to read the FTS docs to know for sure. Have
minimum connect requirements been set by the FTSC?
Fine.... show me an example entry that can do this... without breaking current software.
That's not relevant in this context. There is no software that can...
I think it is, since we're debating on whether the SLNF can continue
to be used. You have some interesting examples, but none seem to go futher than (most of) todays technology.
FWIW, I don't think you and I are that far apart on this thing. I hope
that with time, we will get closer.
Where you and I meet will mean little, since we won't be making the decisions. I just hope that our voices are heard and taken for face value. :)
No penalty involved there. Why would one fly a PVT flag in the
Nodelist and then list a phone number?
Same for IP Nodes. Why fly an IP flag and not list your IP/domain?
When Fidonet started, it NEEDED to create the Nodelist, there was no common PHONE directory available to look up. With IP, such a directory already exists (the DNS). If Fidonet ignores that, then you will end
Without listing the IP/domain in the Nodelist, there is little way to
use the DNS except for a default domain like fidonet.net or something
like that.
Current standards prohibit using a FLAG for that info, so I don't
see how one can keep that info in the Nodelist without breaking
SOMETHING at least.
Create a new standard.
However, if you are NOT suggesting to put <some.domain> into the Nodelist, then the MOST practical place left is the DNS, which is PK>fine with me.
And use some default domain for Fidonet?
Except that means Fidonet re-invents the wheel by re-creating
what already exists, but that may just keep some people
happy........;-)
To do this would require that Fidonet become a "legal" entity. I'm not sure how that would fly. :/
However we don't really need a Finger Daemon, the IBN flag in the
Nodelist is all thats needed to tell people to find BinkP by looking
up the DNS for that node.
And for those that use telnet mailers? or FTP? What about future
protocols and mailers? Do we add flags to no end for them?
With one flag to denote IP capabilities and the IP/domain to that
would work for me. It's better than a flag for each IP protocol.
Lotsa lurkers.
Same for IP Nodes. Why fly an IP flag and not list your IP/domain?
As I alluded in my previous mail, thats one place where the PSTN and
the Internet differ. When Fidonet started using the PSTN there was no common index (phone book) that could be used, so the Nodelist was born
to contain that detail. However the Internet does already have such an index (the DNS), so why not use it? Why does Fidonet have to re-invent
the wheel?
When Fidonet started, it NEEDED to create the Nodelist, there was no common PHONE directory available to look up. With IP, such a directory already exists (the DNS). If Fidonet ignores that, then you will end
Without listing the IP/domain in the Nodelist, there is little way to
use the DNS except for a default domain like fidonet.net or something
like that.
Well for all the times I have used fidonet.net to reach an end IP
node, its worked fine for me. If the node is not listed, the mail is Routed.
I can only see Fidonet requiring everyone to use a Nodelist entry for
DNS info, as a truely backward step, and as is currently done by Zones
2 & 7 (yes 7!) the "rest" of Fidonet will continue doing it THEIR way because Fidonet does not want to work they way THEY want to work. Now
is Fidonet here FOR its Sysops, or are the Sysops here FOR Fidonet?
As a guide, a quick analysis of the fidonet.net Domain shows to me
that at least 150+ defined NETWORKS of IP nodes exist in the Zone 2
and Zone 7 sections of fidonet.net, while a TOTAL of round 50-100
NODES exist within the rest of Fidonet combined. Are we going to
totally ignore the way a vast majority of Fidonet IP users appear to
wish to work? Surely this should tell us something?
I suspect the prime reason the English speaking Zones have not been
aware of the growth of fidonet.net usage is simply because of the
language differences, we (the English speaking Zones) really are
ignorant of how non-English speaking Zones operate.
Current standards prohibit using a FLAG for that info, so I don't
see how one can keep that info in the Nodelist without breaking
SOMETHING at least.
Create a new standard.
A new standard what, Nodelist? You really DO like taking on big tasks....;-)
However, if you are NOT suggesting to put <some.domain> into the
Nodelist, then the MOST practical place left is the DNS, which is
fine with me.
And for those that use telnet mailers? or FTP? What about future
protocols and mailers? Do we add flags to no end for them?
No, Fidonet needs to settle on an IP transmission standard fairly
quickly (probably based on the existing BinkP protocol), similar to
the PSTN standard. We currently use several flags to help the PSTN
side of things (V24,V32,V42b, etc), a few similar ones for IP should
With one flag to denote IP capabilities and the IP/domain to that
would work for me. It's better than a flag for each IP protocol.
I dunno, but reveiwing all the "I" flags, they all seem
reasonable. Each is a distinct connectivity method, no different
then all the modem flags.
Flying them all only leads currently to problems with line length restrictions, but that is easily fixed and is being worked on as
we speak.
The real problem is what do we do with the inet connect addy.
Where do we place it, should it be in a field of it's own, and
maintaining a cross-over for legacy by allowing the kludges into
system name or phone num fields.
And along with that, let's get a fixed definition of PVT. And I
see nothing wrong with defining it to mean a non directly
contactable system which must be routed to, and if direct contact
is needed then arrangements must be made with that node for the
means. And that is all it should stand for, IMO! :)
That is a limit of the software, not the Nodelist format.
That's the whole point, Frank. But because the software now in use
is limited, it make the file they read limited. We need to make it de-limited, period. ;-)
I don't undersatnd why you keep bringing session negotiation methods
Because protocols are being listed in the current Fidonet Nodelist.
They shouldn't be listed there.**
What I'm tring to point out is the differences between protocol types,
and their relevance. Until such time that all mailers are able to auto-detect a transport protocol, some indicator will be needed as
a stop-gap measure. However, in the proper format, one can have as
many as one wants in the NL without taking up too much room.
Well... at least we agree on XML. ;-) Not that I totally disagree on
DNS and/or ESLNL either.
You will eventually "see the light", meaning the need for change,
since that need goes beyond our current situation(s). :)
Let me go through this a little better and see what gets
stirred up.
you got it! <<GG>>
Oh gawd! You're here too?? <GD&R> :)
Binkp, telnet and ftp are protocols for IP. Just as zedzap,
emsi, zmodem and others are protocols for POTS.
i use zedzap, emsi, zmodem, and others on IP with relatively no
problems...
With telnet?? i wager?
Of course, the argument is that with POTS, the protocols
are negotiated upon connection. There is a thread in the
FTSC_PUBLIC echo that is attempting to work out just such
a thing for IP Nodes.
it can be done in IP mailers just exactly like it is done in POTS
mailers... trouble is, it seems, that coders don't want to or haven't
figured out how ;-(
Yup. Always go with the new, no matter what, just because. :(
Was my description/proposal/argument accurate and well
presented?
Did I make sense?
What is your opinion on the idea?
You can answer in Netmail if desired.
NR mode was set by my recent addition of the defnode
setting in binkd...
Interesting... The docs I read said that NR mode was better
enabled for "ad-hoc" connections, so it was set to NR for
defnode anyway.
I have removed it now, to see how it goes next time.
Oh, the connection was found using * for the DNS
name.......;-)
one thing that i've discovered that that has led to is
that i must define all the fidonet addresses of those
nodes connecting to me... at least, it appears that
way, so far... two other systems could not connect due
to their presentation of all fidonet akas instead of
just the one we use between us... i have to wait on the
others to connect and see what happens with them...
several are flying akas in other networks...
I remember seeing something about problems with AKA's and
BinkD but I can't remember the detail, because its never
restricted my operation (as far as I know). I am still using
the older 0.93h that I have been using for years. I have 0.94
here so I must upgrade (one day).....;-).
What is your opinion on the idea?
hummm... need to go back and reread it again... that was several days
ago and i've been "occupied" since then <<wink>>
No reason to re-invent the wheel. The wheel (Nodelist) is fine. The
wheel (DNS) is fine. The other wheels are fine too. The problem is
that there are too many wheels? How the heck do we steer this thing?!?:-)
Fidonet still needs the Nodelist. IMHO, it always will. When Fidonet doesn't need its own Nodelist, Fidonet will not be Fidonet.
There's the key. Routed. If the Node is not listed in the Nodelist or
the DNS, the message is routed.
If the default DNS is fidonet.net, then all Nodes that wish to be contactable would need to be listed in the fidonet.net DNS?
Ok. The majority rules... no matter what?
Are we going to
totally ignore the way a vast majority of Fidonet IP users appear to
wish to work? Surely this should tell us something?
How many NODES of the 9000+ in Fidonet use fidonet.net?
However, if you are NOT suggesting to put <some.domain> into the
Nodelist, then the MOST practical place left is the DNS, which is
fine with me.
DNS is fine as a fallback default. I just think that there needs to be some indication in the Nodelist that the Node is IP capable.
For POTs or IP, Fidonet must have a Nodelist and entries for the
Nodes in the Nodelist telling where to "call" to contact that Node.
I hope we never get to the point of not needing a Nodelist.
No, Fidonet needs to settle on an IP transmission standard fairly
quickly (probably based on the existing BinkP protocol), similar to
How? There are too many already. binkp, ftp, telnet. Of which, telnet seems to handle the old POTS protocols.
the PSTN standard. We currently use several flags to help the PSTN
side of things (V24,V32,V42b, etc), a few similar ones for IP should
The flags you mention are not protocol flags. They are connection
ability flags.
Flags for DSL, cable modem, dial-up isp and such would fit better
in your above statement.
One picky technical difference. :) Binkp and the other IP flags are protocol flags, not connectivity flags in the respect that the Fidonet Nodelist expects.
Agreed... to a point. Not all should be needed.
That's the whole point, Frank. But because the software now in use
is limited, it make the file they read limited. We need to make it de-limited, period. ;-)
That's part of my point as well. Many of the POTS mailers are no
longer under development. Many of the IP mailers are still
under development. It seems better to have the IP mailers make some
changes than to try to get POTS mailers that are "dead" to be
upgraded.
What I'm tring to point out is the differences between protocol types, and their relevance. Until such time that all mailers are able to auto-detect a transport protocol, some indicator will be needed as
a stop-gap measure. However, in the proper format, one can have as many as one wants in the NL without taking up too much room.
And it would be just as easy to have the IP mailers look in a DNS
entry or poll a finger daemon or some other IP technology to get the protocol information.
I see more light than some. :-)
Just a few of my rambling thoughts. :)
it'll require programmers to think a bit more when reading the
nodelist and code their software to look-ahead a bit, but that
shouldn't be a problem for experienced programmers.
Like those worling with IP software? ;-)
Bye <=-
Bye <=-
What kept you so long, Bill?
Again... currently... and quite relevant. AAMOF, we find ourselves
in a worse position than back then. Up until now, there was room to add provisions for additional modem protocols (which were the only type of changes). We are now at a crossroad, where the NL can no longer be kludged to accomodate all the desired info, and still fall within the limitations of SW that reads/processes it.
That is a limit of the software, not the Nodelist format.
I don't undersatnd why you keep bringing session negotiation methods
Because protocols are being listed in the current Fidonet Nodelist.
They shouldn't be listed there.**
Well... at least we agree on XML. ;-) Not that I totally disagree on
DNS and/or ESLNL either.
Just a few of my rambling thoughts. :)
I think I agree with you. (Wow! That's scary) :-)
open source stuff is easily to deal with, but even closed
source stuff can be "destruction tested" with artificial scenariaos.
nets with 10000 nodes, nodelist lines longer than the available memory, that sort of stuff :)
personally I don't feel XML is the answer at the moment
I lean more towards a lightweight structuered list
one format dreamt up by Frank Vest an I went like this:
If you don't list a phone number in the Nodelist, you fly the PVT
flag. Simple, eh?
Because there was no other way to do it for PSTN nodes, however
with IP nodes we have other ways. Why propagate something that is
no longer valid
Bye <=-
Quoting Frank Vest to Gordon Lewicky Subj. linked, dated
14-Dec-2002 10:35
Hi ya Frank,
I understand your point. Would the "location" field be better?
Or is where you live as important to you as your name and your
system name?
Well, if we're gonna throw out the geography rule, then to me at
least, location is important since we can no longer depend on
zone, region, net! And I sure can't figure out where
bbs.micronet.com is! :)
Actually, I'm getting somewhat annoyed at this trend to
impersonality in this supposed network of computer enthusiasts. If
I want impersonality, I'll go on the net.
I happen to enjoy knowing who the sysop is, what their bbs name
is, and where they park their butt! :)
Using a flag to indicate the IP or domain address is fine too. As
long as it is /one/ flag instead of one for every IP protocol.
I may be wrong, but basically there are only 2 different connect addresses, domain name or ip, and email addy.
Surely we can accomodate these 2 somewhere in the line without
mucking around with sticking them where they shouldn't be.
But this kludging addys into various former fields is exacly that, kludging.
Bye <=-
They can go in the flags.. INA and IEM (or attached to the mailer
flags) the 157 limit though may meed that there is less room got other fields like sysop name, location, and system namee.
If you don't list a phone number in the Nodelist, you fly the PVT
flag. Simple, eh?
Because there was no other way to do it for PSTN nodes, however
with IP nodes we have other ways. Why propagate something that is
no longer valid
PVT should be used for IONs because, as you said, there's no other way for POTS nodes to understand the nodelist entry correctly.
On 14 Dec 02 19:26:21, Jasen Betts said the following to Bob
Short:
open source stuff is easily to deal with, but even closed source
stuff can be "destruction tested" with artificial scenariaos.
But unnecessesary. The fields for POTS entries is fine.
nets with 10000 nodes, nodelist lines longer than the available
memory, that sort of stuff :)
We only WISH we had that many node in a new. <g>
The rest is insignificant when using newer SW to read/write the info.
personally I don't feel XML is the answer at the moment I lean
more towards a lightweight structuered list
Restructured, and it may be that an ESLNL would be a bit larger.
It will require a short enrty for the POTS 1/2, and the expanded
enrty for the IP section...
though it will allow merging of data
currently spread over several enrties into a single one (multiple connectivity).
one format dreamt up by Frank Vest an I went like this:
Except that this concept would require rearranging the POTS
listings too, thus making people change SW to read it.
But if that format is used in the IP section...
Bye <=-
open source stuff is easily to deal with, but even closed source
stuff can be "destruction tested" with artificial scenariaos.
But unnecessesary. The fields for POTS entries is fine.
huh??? I'm talking software, you seem to be discussing file formats?
We only WISH we had that many nodes in a net. <g>
2:5020 is pretty big (1423 nodes) and that breaks some software.
10000 is not IMO radically larger,
The rest is insignificant when using newer SW to read/write the info.
nope. it shows that the programmer wasn't following the specification. stuff shopuld be tested so it can be fixed before it gets abandoned.
It will require a short enrty for the POTS 1/2, and the expanded
enrty for the IP section...
huh? half... there is no pots half. pots is optional as is IP.
yes, or run a converter, preferably one tuned to their software type.
IE ione for current POTS software and a different one for current IP software
What kept you so long, Bill?
There's not a lot of point in my taking part in a discussion
unless I understand it, Jan. :-)
OTOH, I do understand Fido style nodelists. :-)
There's not a lot of point in my taking part in a discussion
unless I understand it, Jan. :-)
Never knew you to be so modest, Bill ;-)
OTOH, I do understand Fido style nodelists. :-)
That's really you again...
OK.. let me rephrase that: The rest /should/ be redundant. I'll
bet that once a clear and complete set of standards are arrived
at, the programmers remaining will be happy to meet the challenge.
An abbreviated entry in the POTS section will tell my POTS mailer
to route mail to an IP node, while the actual expanded listing in
the IP section gives all the data needed to connect betewwn IP's.
yes, or run a converter, preferably one tuned to their software
type. IE ione for current POTS software and a different one for
current IP software
Steps that need mot be required, if this is done right.
Bye <=-
OK.. let me rephrase that: The rest /should/ be redundant. I'll
bet that once a clear and complete set of standards are arrived
at, the programmers remaining will be happy to meet the challenge.
it doesn't work like that... for example try sending a 100K meg netmail som time... too mnay programmers see "unlimited" and then just set the limit wherever they find convenient...
Steps that need mot be required, if this is done right.
what's the right way then?
I'm attempting to get some examples from Mark and Jan (Hi guys!).
Let's see what they come up with... :)
I'm attempting to get some examples from Mark and Jan (Hi guys!).
Hi yerself, Bob!
Let's see what they come up with... :)
I'm afraid I won't make it for today as I promised; with Christmas so near and my help being needed... oh well, you're understand.
But that bit of gray matter I have is still working on it ;-)
OK.. let me rephrase that: The rest /should/ be redundant. I'll
bet that once a clear and complete set of standards are arrived
at, the programmers remaining will be happy to meet the challenge.
it doesn't work like that... for example try sending a 100K
meg netmail some time... too mnay programmers see "unlimited"
and then just set the limit wherever they find convenient...
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,049 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 52:52:23 |
| Calls: | 236,052 |
| Files: | 60,364 |
| D/L today: |
25 files (8,007K bytes) |
| Messages: | 289,618 |