FV> Well... My thought was that since the person operating the
 FV> conversion program decides which fields to put in what
 FV> order in the old style list, it would be hard to make the
 FV> old style list incorrect (wrong).

that's an incorrent assumption to start with...

[trim]

 FV> Of course, nothing is fool proof. :-))

of course... there's always a "better" fool... that's why it is
the developers who will determine the format and the conversion rules...

[trim]

 FV> Ah ha! I think I see what you mean. The new style list
 FV> would have two or three lines for each Node. The first
 FV> line would always be the "basic" Node information. The
 FV> next line(s) would depend on the type of connection
 FV> capabilities and be designated by either the POTS or IP
 FV> flag, or both, as needed?  If I got this thought my
 FV> thick head right?

hummm... that's sounding like my 2nd proposal...

[trim]

 FV> I was thinking that the *Cs would be the ones running
 FV> the conversion program to generate the old style list
 FV> for distribution along with the new list... IE:

no need for the *Cs to be involved in the conversion process at all... only
those with machines incapable of executing the conversion software would
need _someone_ to convert the new list to the old list for them...

)\/(ark