TIP: Click on subject to list as thread! ANSI
echo: net_dev
to: All
from: Charles Cruden
date: 2002-12-30 23:15:46
subject: Easier solution?

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)
SEEN-BY: 633/267 270
@PATH: 342/806 123/500 106/1 379/1 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.