FV>> 8. FV> The phone number if POTS capable. If not,
 FV>> -Unpublished-.
 FV>> JB>> or you copuld just leave it blank... the
 FV>> JB>> tranalstion software could insert that word

 FV> Good point. The commas would still need to be there, though.

yup...

 FV>> 9. Modem speed. 300 if IP node?
 JB>> for converting it may be enought to just determine
 JB>> the modem speed from the modem flags modem flags...

 FV> Possible, I guess. Although I had a 2400 baud modem
 FV> that could do error correction.

thank you...

 JB>>  10. Modem flags. If IP only, make something
 FV>> up for the "old style" list.
 JB>> nah leave them out if there's no modem. I don't think
 JB>> any software will choke on a line with no flags...

 FV> I have no idea on this. Some Guru that is better versed is
 FV> needed.

modem capability flags are needed IF there is a modem answering the line...
if it is telnet or some other network protocol, then other flags may be
needed but not modem flags... unless we develop some "dual
meaning" flags... one thing if modem, another if a certain network
protocol...

 FV>> Ok. You can add all the bs you want after this. Why, I
 FV>> don't know. Doesn't seem to make any sense or be needed,
 FV>> but who knows.
 FV>> JB>> yeah it's gotta be open ended, that way new
 FV>> JB>> development can be added.

 FV> The important thing is to have the order. The current
 FV> Nodelist has the major flaw or being disorganized at the
 FV> end. It's ok at the first... as you read the current list,
 FV> you know that field one is "A", two is "B",
three is "C",
 FV> four is "D" and co on. Then you get to the flags and it
 FV> falls apart. If a Node is CM, but not MO, the order is
 FV> all messed up and hard to translate.... at least to me.

the thing to remember here is that the flags after the speed field are all
grouped together as a(nother) comma seperated field... and it is possible
(of course) to have an additional comma seperated field in there known as
U(ser) flags...

 FV>> Now, make a program that will read this new list and
 FV>> spit out an old style list. The new list is formatted
 FV>> in such a way that the fields are set and clear. The
 FV>> program would read the new list and know what needed
 FV>> to go where for the old list.
 JB>> reading FTS0005 I see that user flags could then can
 JB>> contain any printable characters except the comma and
 JB>> blank... (which could be a problem) FTS5001  calls the
 JB>> Tzz (hours of availability) flag a userflag but lits it
 JB>> in the main flags section... (I'm guessing that it has
 JB>> been promoted to the status of an availability flag and
 JB>> the word userflag in 5001 is an oversight. 5001 also
 JB>> lists a bunch of "system" userflags that don't apply to
 JB>> a single connection but to the fido node itself, (things
 JB>> like NEC)

 FV> User flags seem useless to me in most respects.

userflags were inteneded to be for testing of new flags... if they became
widespread in use, they were to be upgraded to "normal" flags...

 FV> I often laugh at the thought of putting a user flag in
 FV> like "U,I'm_the"biggest_stud_in_Fidonet_Prove_me_wrong"
 FV> :-))

yes, but that one shouldn't be allowed by the *C processing that segment
because it is frivilous and doesn't serve any technical function(s)...

[trim]

 FV> The conversion program could use a configuration file to
 FV> set what sections of the new list are used in what order
 FV> for the old list.

uggg... that leave too much open to go wrong... someone could adjust that
line in the config file and then that row or entire segment might be
dropped by the processing software due to something being invalid...

 FV> The "Nodelist updates" would only be for the new format.
 FV> The old style list would be made from the new list in the
 FV> proper order with the proper information in the proper
 FV> places. It couldn't be any other way... at least as I see
 FV> it.

right...

[trim]

 JB>> what I'm proposing is at the least a connection-type
 JB>> field that holts a indicator of what type of connecton
 JB>> is escribed after it, if the new-format mailer can't
 JB>> handle that type of connection it justs skips forwards
 JB>> three (or some other fixed nimber commas) and reads
 JB>> the next connection-type

 FV> If the flag IBN, ITN or some other "I" flag exists, the
 FV> node would be at least Internet capable.

that might be possible but it could also be restricting in the future...
better to have a complete new field similar to my proposal of an additional
leading field containing the connection type for the row...

 JB>>  all you'd need to add is a type field before each
 JB>> address-flags pair. then you could even list multiple
 JB>> telephone lines in one nodelist entry.  eg,
 JB>>                                           ||
 JB>>                                           \/
 JB>>  ,6308,Some_BBS_Name,Some_Town,Some_Sysop,IP,IP.or.url.com,
 JB>>   CM_MO_LO_IBN_ITN,POTS,> unlisted>,33600_V34_V42b_CM_XA                    /\
 JB>>                    ||

 JB>>  Here I've grouped all the flags for each connection into
 JB>> a single field  and put the modem speed in there too.

 FV> That would work. Like I said, the format of the new list is
 FV> not a problem and is expandable. The old list is generated
 FV> from the new list and has no way to be wrong... if the
 FV> conversion program is done right. The new list could have a
 FV> flag at position 11 that indicated the type of connection..
 FV> IE: ION for Internet only - no POTS. IPN for Internet and
 FV> POTS. Then the other flags could tell what "protocol" is
 FV> available at that Node. IE: IBN for binkp and so on.

my proposal doesn't need to get that detailed... its quite simple... if
there is a POTS field, then there is POTS capability and that POTS row
contains the data to use for a POTS connection... if there is an IP field,
then there is IP capability and that IP row, blended with the POTS row,
contains the data to be used for an IP connection... if there is no POTS
row, then the IP row contains all the needed data... same goes with a row
that contains an (as yet uninvented) LASER field for some futuristic
lightbeam methodology or even SUBSPACE42 for communication on subspace
channel 42 or the like...

 JB>> probablly the system flags shoulf go before the firrst
 JB>> connection.

 FV> The order of the fields isn't all that important in the
 FV> new list. I'd suggest that the fields that are for
 FV> Internet connection be before the fields for the POTS
 FV> system in the new list simply because that is why we are
 FV> doing a new list. :-)

i don't agree... we are doing a new list format simply because the old SLF
doesn't cover today's needed options...

 FV> The important thing is that there be order in the new list.
 FV> IE: field 1 is for this and field 2 is for that and so on.
 FV> That way we have each field defined. Also, do not make a
 FV> field that "might be used in by this node, but not by
 FV> another node"... IE: the flags field should have been
 FV> grouped together in the old style list. If they had been,
 FV> we would not be having so much trouble with the darn thing
 FV> now IMHO. :-)

the flags are grouped together... they just happen to consist of possibly
two comma delimited lists of flags in any order...

 JB>>  It won't be quite as simple to translate into an
 JB>> old-stype nodelist because the correct answer depends on
 JB>> what the target sysytem is capable  of...

 FV> The old nodelist is generated from the new list. I'm not
 FV> sure what you mean here. I'm probably not understanding
 FV> properly.

take a POTS system converting the new style list to an old style list...
he's thinking of how would a IP or IPonly system be listed... i say it
doesn't really matter... it is either listed as PVT unpublished (for
software that insists on verification in the list before allowing message
creation or contact) or it is skipped altogether is fido systems become
more like internet systems in that they use "smarthosts"... in
other words, it doesn't matter what system you are sending mail to, just
create it and send it to your smarthost... if it cannot determine where to
send it next and bounces it back to you, ok then... internet UUCP and even
today's email all works like this...

 JB>>  but that needn't be a bad thing, because the sysop can
 JB>> have a mailer that  is better behaved without neeing to
 JB>> upgrade it...

 FV> I think that with the old nodelist being generated from
 FV> the new list, there will be a lot of problems solved. :-)

maybe... once all the logistics are worked out and a firm set of rules are
put in place... once that happens, then a hardcoded util can be written to
do the job...

 FV>> No matter what format we use; comma delimited, data base,
 FV>> magic wand or ???, the format will need to be changed in
 FV>> time to allow different protocols, communication methods
 FV>> and other advancements that come along.

 JB>> if the format is designed in the right way it can be made
 JB>> extendable with causing the headaches current nodelist
 JB>> format problems cause...

 FV> Yup. As long as there are no fields that are used by one
 FV> node, but not by others. Such fields should be grouped
 FV> and not given an individual section. Otherwise, the
 FV> structure of any list falls apart.

i don't know that i can agree completely with the first line... as long as
a POTS node remains in fidonet, there will be field that others will not
use... as for the grouping, remember, this is a technical network... it is
very easy for me, as a programmers, to write a program that reads a line of
test and seperates it into 8 fields with the last field containing
additional comma seperated fields... remember also, the nodelist was not
formatted for human consumption... it was formatted for machine comsumption
and anything one tried to do that wasn't in the nodelist, the software that
interfaced would let the human know about... all we're supposed to do is
communicate...

)\/(ark