Subj : proposed new nodelist
To : Frank Vest
From : mark lewis
Date : Tue Jul 23 2002 12:01 am
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,<phone number or
JB>> 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
* Origin: (1:3634/12)
--- SBBSecho/Win32 v2.00
* Origin: Baddog BBS (1:218/903)
