Subj : Easier solution?
To : Charles Cruden
From : Jan Vermeulen
Date : Thu Jan 02 2003 01:34 am
Quoting Charles Cruden on Mon 30 Dec 2002 23:15 to All:
cc> Comments / criticisms welcome....
OK, here we go ;-)
cc> Why not simply replace the phone number of an IP node with its IP
cc> address or FQDN? After all, a phone number is the "contact address"
cc> for a node in Fidonet, same as the IP / FQDN is for an IP node.
cc> For an email only node, the phone number can be replaced with the
cc> email address to send mail to.
cc> Nodes which have multiple contact addresses simply have multiple
cc> listings, same as multi-node BBSs had before, and for pretty much
cc> 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.
We have had that problem in Europe 9 years ago, when sysops of one region,
which shall stay unnamed, started requesting and obtaining special nodenumbers
for their ISDN lines where no such numbers were really needed (standard ISDN
equipment knows how to divert analog calls to a different port).
cc> Multiple IP contact methods at the same address can be easily resolved
cc> by flying the appropriate flags for the appropriate entry, and adding
cc> new entries as required for the additional listings, if that person
cc> really feels the additional listings are necessary.
That is indeed not a problem, but it should not be done if it can be
avoided - listed nodes should be contacted easily without complicated nodelist
lookups by human 'personnel'.
cc> IPs/FQDNs can be prefaced by IP# for easy processing by nodelist
cc> compilers.
See above.
cc> Advantages:
cc> - Flags can be applied to individual contact methods. Txy, Pvt,
cc> FREQ flags, etc. can be varied for each contact address.
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).
cc> - BBSs keep the relevant information for other fields constant, so
cc> 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.
cc> - There is no predetermined limit on the length of the phone number
cc> field, so it can accomodate any length of FQDN and any type of IP
cc> address, IPv4 or IPv6.
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.
cc> - With the IP# prefix, IP nodes are easily identifiable so they can be
cc> processed by nodelist compilers, mailers, etc. Older mailers /
cc> compilers may well reject letters in the number out of hand: so much
cc> 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.
cc> - Keeps nodelist in a recognizable format.
There are more ways than one.
cc> - Current IP flags don't need to change to be applied correctly.
There are more ways to handle this, still without flag changes.
cc> - Reasonably extensible: changes the function of the phone number
cc> field from phone number to contact address. As new contact methods
cc> are implemented, a defined place for them already exists: all that
cc> needs be done is interpret the field correctly.
You can store only one contact address in the contact address field. A
large number of systems have more than one contact address.
cc> Disadvantages:
Lets hear them ;-)
cc> - Multiple listings for a single node could lead to "nodelist stuffing".
Right.
cc> * At this point, nodelist size is hardly an issue. Multiple votes in
cc> elections is as much an issue with IP nodes as it was with multi-line
cc> BBSs: i.e. none if the election co-ordinator is doing the job properly.
Sure. Been there, did it, had no complaints.
cc> - Means reconfiguration of current / future IP software.
Very probably. The good thing is that there is less legacy around than with
POTS.
cc> * No more so than any other proposition for extending the nodelist,
cc> and this requires less change in processing to deal with a new format.
Right,
cc> - May break older software.
Indeed. We should tread softly, whichever way we go.
cc> * The extent of the breakage is debatable. If it means an older
cc> mailer can't contact that particular node, so much the better:
cc> it can't do IP anyway.
I'm not entirely shure. Know FrontDoor?
cc> If it does letter->number translation, that causes more of a problem,
cc> but the IP# prefix should let the entries be screened out easily enough.
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.
cc> Nodelist segment processing software may complain about illegal
cc> characters in the field: that would need to be fixed.
Many of the complaints will come from unfixable software, if it is not
hidden from them (at least in the phone field).
cc> There are any number of other things that probably should be fixed
cc> at the same time though.
You can bet your ****s on that ;-)
Thank you for this clear statement, Charles. I will be back later this week
with an expos� on my viewes and the ELFS proposal.
-=<[ JV ]>=-
* Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
