Subj : Easier solution?
To   : All
From : Charles Cruden
Date : Mon Dec 30 2002 11:15 pm

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.

---
* Origin: Xanadu: an odd little spot in Edmonton, Alberta (1:342/806)