Comments / criticisms welcome....
Why not simply replace the phone number of an IP node with its IP
address or FQDN? After all, a phone number is the "contact address"
for a node in Fidonet, same as the IP / FQDN is for an IP node. For
Why not simply replace the phone number of an IP node with its IP
address or FQDN?
address to send mail to. Nodes which have multiple contact addresses simply have multiple listings, same as multi-node BBSs had before, and
- May break older software.
* The extent of the breakage is debatable. If it means an older maile contact that particular node, so much the better: it can't do IP anywa
it does letter->number translation, that causes more of a problem, but
IP# prefix should let the entries be screened out easily enough. Node segment processing software may complain about illegal characters in t field: that would need to be fixed. There are any number of other thi
that probably should be fixed at the same time though.
Comments / criticisms welcome....
Why not simply replace the phone number of an IP node with its IP
address or FQDN? After all, a phone number is the "contact address"
for a node in Fidonet, same as the IP / FQDN is for an IP node.
For an email only node, the phone number can be replaced with the
email address to send mail to.
Nodes which have multiple contact addresses simply have multiple
listings, same as multi-node BBSs had before, and for pretty much
the same reasons.
Multiple IP contact methods at the same address can be easily resolved
by flying the appropriate flags for the appropriate entry, and adding
new entries as required for the additional listings, if that person
really feels the additional listings are necessary.
IPs/FQDNs can be prefaced by IP# for easy processing by nodelist compilers.
Advantages:
- Flags can be applied to individual contact methods. Txy, Pvt,
FREQ flags, etc. can be varied for each contact address.
- BBSs keep the relevant information for other fields constant, so
IONs can list their sysop name and BBS name.
- There is no predetermined limit on the length of the phone number
field, so it can accomodate any length of FQDN and any type of IP
address, IPv4 or IPv6.
- With the IP# prefix, IP nodes are easily identifiable so they can be processed by nodelist compilers, mailers, etc. Older mailers /
compilers may well reject letters in the number out of hand: so much
the better, as they won't then be able to reach the number anyway.
- Keeps nodelist in a recognizable format.
- Current IP flags don't need to change to be applied correctly.
- Reasonably extensible: changes the function of the phone number
field from phone number to contact address. As new contact methods
are implemented, a defined place for them already exists: all that
needs be done is interpret the field correctly.
Disadvantages:
- Multiple listings for a single node could lead to "nodelist stuffing".
* At this point, nodelist size is hardly an issue. Multiple votes in elections is as much an issue with IP nodes as it was with multi-line BBSs: i.e. none if the election co-ordinator is doing the job properly.
- Means reconfiguration of current / future IP software.
* No more so than any other proposition for extending the nodelist,
and this requires less change in processing to deal with a new format.
- May break older software.
* The extent of the breakage is debatable. If it means an older
mailer can't contact that particular node, so much the better:
it can't do IP anyway.
If it does letter->number translation, that causes more of a problem,
but the IP# prefix should let the entries be screened out easily enough.
Nodelist segment processing software may complain about illegal
characters in the field: that would need to be fixed.
There are any number of other things that probably should be fixed
at the same time though.
- BBSs keep the relevant information for other fields constant, so
IONs can list their sysop name and BBS name.
You have a point there. It is to be seen, tho, how many would really need that with the number of real BBSes left in the net.
This is the biggest problem so far with the idea. We don't have any automated software for the RC/ZC levels to use (who need that due to their bigger job) which can handle this.
Next up would be seeing if popular mailers can support it. That would be mostly POTS types affected I think.
2) The IP address may be dynamic
3) Text other than -Unpublished- is likely to cause issues with nodelist processors
4) IP addresses require a prefix, currently 000 which could bring a visit from the cops for Aus people who have their systems misconfigured
Multiple listings would require some method for software to recognise them as the one physical system, otherwise routing has to be manual.
Sending direct mail in reply to a message can become cumbersome if you write from your email only address and and I have only PSTN. I need to look up your PSTN number in the nodelist before I can even start to write my message to you or change the address later when finding out that it never left my system because of incombatible access modes.
That could be an advantage as far as software makes use of it (I do not known of software that makes use of Txy flags - FrontDoor users could set that up, in a rather complicated way).
Right. But there is a predefined length of the entire record (line, if you wish), originated by a bug in makenl but by now hardcoded in a lot of mailer software, the most of which is of the legacy kind.
- With the IP# prefix, IP nodes are easily identifiable so they can be processed by nodelist compilers, mailers, etc. Older mailers / compilers may well reject letters in the number out of hand: so much
the better, as they won't then be able to reach the number anyway.
How will this help me: I have a PSTN, ISDN and ADSL. I can use the
phone field either for the PSTN and ISDN number as they are the same, or
for the ADSL ip number. I want no second node number if I can avoid it, not because I do not like braids on my jacket, but because I think it is bad service for those who want to contact me.
After all that is what a node number is for: help them contact you.
There are more ways than one.
a large number of systems have more than one contact address.
- May break older software.
Indeed. We should tread softly, whichever way we go.
I'm not entirely shure. Know FrontDoor?
If the software knows about that. But I advocated already to stay away from the phone number field. Dual purpose for the same field in a record is never advisable.
Many of the complaints will come from unfixable software, if it is not hidden from them (at least in the phone field).
Comments / criticisms welcome....
Why not simply replace the phone number of an IP node with its IP
address or FQDN?
Nodes which have multiple contact addresses simply have multiple
listings, same as multi-node BBSs had before, and for pretty much the
same reasons.
Advantages: - Flags can be applied to individual contact methods.
Txy, Pvt, FREQ flags, etc. can be varied for each contact address.
- BBSs keep the relevant information for other fields constant, so
IONs can list their sysop name and BBS name. - There is no
predetermined limit on the length of the phone number field, so it
can accomodate any length of FQDN and any type of IP address, IPv4
or IPv6. - With the IP# prefix, IP nodes are easily identifiable
so they can be processed by nodelist compilers, mailers, etc.
Older mailers / compilers may well reject letters in the number
out of hand: so much the better, as they won't then be able to
reach the number anyway. - Keeps nodelist in a recognizable
format. - Current IP flags don't need to change to be applied
correctly. - Reasonably extensible: changes the function of the
phone number field from phone number to contact address. As new
contact methods are implemented, a defined place for them already
exists: all that needs be done is interpret the field correctly.
Disadvantages: - Multiple listings for a single node could lead to "nodelist stuffing". * At this point, nodelist size is hardly an
issue.
Multiple votes in elections is as much an issue with IP
nodes as it was with multi-line BBSs: i.e. none if the election co-ordinator is doing the job properly. - Means reconfiguration of
current / future IP software.
* No more so than any other
proposition for extending the nodelist, and this requires less
change in processing to deal with a new format. - May break older software. * The extent of the breakage is debatable. If it means
an older mailer can't contact that particular node, so much the
better: it can't do IP anyway.
If it does letter->number
translation, that causes more of a problem, but the IP# prefix
should let the entries be screened out easily enough.
Nodelist segment processing software may complain about illegal
characters in the field: that would need to be fixed.
There are any number of other things that probably should be fixed at
the same time though.
Bye <=-
Copied from FTSC_PUBLIC by Frank Vest (1:124/6308.1)========================================================================
On (30 Dec 02) Charles Cruden wrote to All...
Hello Charles,
Comments / criticisms welcome....
Why not simply replace the phone number of an IP node with its IP
address or FQDN? After all, a phone number is the "contact
address" for a node in Fidonet, same as the IP / FQDN is for an
IP node. For
I'd really rather not be known as 1:124/6308 /and/ 1:124/8308 :)
However, that may be the best way to do this.
FWIW: Many, if not all, of the ideas agrued and passed around here
have merit. The problem is going to be getting one of them into
operation /without/ making a dozen new "standards" to follow. To
do this, IMHO, will require the joint efforts of the *C structure
and the FTSC.
Bye <=-
G'Day Jan,
Just sticking my 2c worth here. Most currently running active BBS
systems are in actual fact internet connected. From where I sit
there are a large number of BBS's available via telnet that cater
mainly for things like games and a few files.
Next up would be seeing if popular mailers can support it. That would be mostly POTS types affected I think.
I can volunteer to test FD here.... :)
Just sticking my 2c worth here. Most currently running active BBS
systems are in actual fact internet connected. From where I sit
there are a large number of BBS's available via telnet that cater
mainly for things like games and a few files.
That's looking at it from Down Under, Rick. In Up Yonder it might
well be a tad different...
A dual capacity BBS may still have a lot of pots points and users
and we want to care for those too.
I tried a few entries with nlmake here, and it didn't seem to
complain, nor did FDNC. (Mind you, FD/FDNC has some accounting for IP nodes, so that probably helped.) For nodelist compilers in general,
I'd imagine the worst it would do would be to reject that node, which given it's an IP node to begin with would exactly be a bad thing. For segment compilers it becomes more of a problem. OTOH, there are fewer segment compilers to worry about....
I suggested the IP# heading, but if something can be found that all
agree on, it can be pretty much anything.
end up at the same spot. Then you just choose which address you want
to use based on the contact method you want to use.
A dual capacity BBS may still have a lot of pots points and users
and we want to care for those too.
That seems a little different then the original statement of yours
I replied to where you said:
"It is to be seen, tho, how many would really need that with the number of real BBSes left in the net."
Nodes which have multiple contact addresses simply have multiple
listings, same as multi-node BBSs had before, and for pretty much
the same reasons.
Sending direct mail in reply to a message can become
cumbersome if you write from your email only address and
and I have only PSTN. I need to look up your PSTN number in
the nodelist before I can even start to write my message to
you or change the address later when finding out that it
never left my system because of incombatible access modes.
How will this help me: I have a PSTN, ISDN and ADSL. I
can use the phone field either for the PSTN and ISDN number
as they are the same, or for the ADSL ip number. I want no
second node number if I can avoid it, not because I do not
like braids on my jacket, but because I think it is bad
service for those who want to contact me.
After all that is what a node number is for: help them
contact you.
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,050 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 71:51:41 |
| Calls: | 236,055 |
| Calls today: | 3 |
| Files: | 60,364 |
| D/L today: |
55 files (55,266K bytes) |
| Messages: | 289,765 |