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,> 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) .