finally have some time to comment on the comments and offer some
"rebuttal"...

 ml>> then again, i dunno... whatever we come up with must be extensible...
 ml>> the above will run into a linelength problem, i'm sure... we could do
 ml>> a multiline format... off the top of my head, maybe something like
 ml>> this... again with the //wrapping

 ml>> POTS,Host,3634,Fayetteville_Net_(039),Sanford_NC,Mark_Lewis,//
 ml>> 1-919-774-5930,33600,CM,XA,V32b,V42b,H16,V32t,V34
 ml>> IP,,,,,,000-012-146-166-242,,CM,XA,ITN,IVM,
 ml>> IP,,,,,,,,MO,CM,XX,IBN

 ml>> POTS,Node,12,Waldo's_Place_USA,central_north_carolina_usa,//
 ml>> mark_lewis,1-919-774-5930,33600,CM,XA,V32b,V42b,H16,V32t,V34
 ml>> IP,,,bbs.wpusa.dynip.com,,,000-012-146-242,,CM,XA,ITN,IVM,IBN
 ml>> IP,,,,,,,,LO,MO,CM,XX,IBN


 FV> All this is good and fine. I'd put it forth that the first
 FV> thing to do is look at our current Nodelist format to see
 FV> what can be done to make it more workable with regards to
 FV> POTS and IP.

that's already been done several times... the current solution is raising
complaints from some corners and there is a need for an extensible nodelist
format that won't fall into the problems that the current one has...

 FV> As a thought, What flags do we actually need in the
 FV> Nodelist?? As an example, do we need the v.32, v.34, HST
 FV> and other flags?

yes, all the flags that are currently listed are needed... one never knows
when they may need to contact or be contacted by a system with an old PEP
modem or some such that someone has on the shelf for emergencies and
such...

 FV> In the past, we did need these because modems didn't all
 FV> handle certain settings and such. Today, I'd think that
 FV> many of these flags are outdated and obsolete. Couldn't we
 FV> get by with simply;

 FV> CM - Continuous Mail
 FV> MO - No BBS, Mail Only
 FV> X* - Type of Mailer

we could except for the problems of modems not wanting to connect due to
some incompatibility that the modem flags show...

 FV> This would remove some length from the listings.

sure, it would but is that really the complaint today? somehow i don't think so...

 FV> U(ser) flags could be looked at as well. What do we actually
 FV> need? Is
 FV> "U,Joe_Bob's_Big_Service_Center_At_the_end_of_the_road" really
 FV> needed?
 FV> :-)

user flags are experimental and are only to be used for a short time... the
definition of "short time" is left as a excercise for others to
figure out...

 FV> At any rate, to use my listing as an example (maybe a poor
 FV> example,
 FV> but...)

 FV> ,6308,Collin_County_Station,Mc
 FV> Kinney_TX,Frank_Vest,1-972-562-8064 //
 FV> ,33600,CM,XA,V34,V42b,IBN:web-idiot.d2g.com,URVIA:1:3830/9

 FV> I could probably drop the V32,V42b, stuff. I'll admit that
 FV> this isn't a lot, but could make some difference.

i'd only drop the modem flags if you don't use a modem on that system...
however, since you do show a POTS number, the modem flags are required...

 FV> As is now, the allowed flags are, in part:

 FV> ;S          V21       CCITT V.21     300 bps   full duplex
 FV> ;S          V22       CCITT V.22     1200 bps  full duplex
 FV> ;S          V29       CCITT V.29     9600 bps  half duplex
 FV> ;S          V32       CCITT V.32     9600 bps  full duplex
 FV> ;S          V32b      ITU-T V.32 bis 14400 bps full duplex
 FV> ;S          V32T      V.32 Terbo
 FV> ;S          V33       CCITT V.33
 FV> ;S          V34       CCITT V.34
 FV> ;S          HST       USR Courier HST
 FV> ;S          H14       USR Courier HST 14.4
 FV> ;S          H16       USR Courier HST 16.8
 FV> ;S          H96       Hayes V9600
 FV> ;S          MAX       Microcom AX/96xx series
 FV> ;S          PEP       Packet Ensemble Protocol
 FV> ;S          CSP       Compucom Speedmodem
 FV> ;S          ZYX       Zyxel series
 FV> ;S          VFC       V.Fast Class
 FV> ;S          Z19       Zyxel 19,200 modem protocol
 FV> ;S          V90C      ITU-T V.90 modem Client
 FV> ;S          V90S      ITU-T V.90 Server.
 FV> ;S          X2C       US Robotics x2 client.
 FV> ;S          X2S       US Robotics x2 server.

 FV> How many of these are really needed?

all of them... each details what it covers and include below it... not all
include all below...

 FV> Maybe this wouldn't make much, or enough, difference,
 FV> but that would depend on the line limits for the Nodelist.

 FV> Anyway, just some thoughts. Since in the, not so distant,
 FV> future, there will probably be few, if any, POTS systems
 FV> left, the current format of the Nodelist could be used
 FV> with software designed to accommodate the new information.
 FV> IE: the former phone field could be the IP address. Of
 FV> course, as I said, the software would need be changed, but
 FV> without POTS to worry about, it would work.

my main reason for do the additional multiline format was to remain as
compatible with the current format and offer the needed additional
capabilities... the nice thing about the multiline format that i laid out
is that it is simple enough for a util to grab just the POTS lines and
create a SLF nodelist directly simply by walking thru the file, grabbing
the entire line of each POTS id'd line and writting that line out to a new
file without the POTS, field... a util could also create a IP only nodelist
by grabbing the data from any possible POTS entries for that node and
overridding with the changes from the first IP row... any subsequent IP
rows would modify further but also denote multiple entries... this is
something (multiple entries for one address) that we currently can't do...
IP based mailers, because they are still under development, can easily
handle this new feature and because it (the feature) is not restricted, it
is possible that POTS mailers could also acquire the same capability...

in any case, my main goal is/was to retain as much compatibility with what
we currently have and to simply expand a bit and make the current format a
subset of the new...

)\/(ark