JB>>> yeah... gruping flags together like that makes sense

 FV>> Thank you.

 JB> I have got to proofread better than I have been...
 JB> everyone's being so nice, ignoring it. :)

>

 JB>>> or you copuld just leave it blank... the tranalstion
 JB>>> software could insert that word

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

 JB> yup, can't have a blank filed without commas.

thus the format of my (second) proposal...

 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.

 JB> Hmm, there's no V22B flag for 2400 bps modems.
 JB> error correction would be MNP or V42  flags

right! that's why 2400,MNP or 2400,V42 was/is a valid flag... actually, i
think V42B instead of V42... this is one of those "confusing"
flags set by the ITUT (if i got those letters correct)... one of the V42
entries is speed/compression capability and the other (V42B) is error
correction...

 JB> (did they produce any MNP ot V42 modems incapable
 JB> of 2400bps ? - maybe the MNP flag would be enough)

nope... the MNP flag means one thing... V42 means another... in fact, as i
recall, V42 was a speed and V42B is/was error corrections

[trim]

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

 JB> yeah, each flag has to be read and then translated
 JB> separeately but having them continue to the end of
 JB> the line cases problems making it hard to add further
 JB> ordered fields.

true, if one is adding fields to the end of the row...

[trim]

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

 JB> some people may find them useful, ad flagging at
 JB> bot the node and connection level should be allowed.
 JB> maybe using a space for a flag separator instead of
 JB> an underbar would solve that problem.

the thing to remember is that the nodelist is machine parsable... it is not
and never was intended to me for raw human consumption... unless, like some
programmers, you can read HEX in the raw >

[trim]

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

 JB> yeah, there's no way to extraact a system named from a
 JB> sustem that uses that field for something else etc...

right... this is why i personally want to be able to list my system with
its system name and domain name... in fact, i kinda can see a method of
further "compaction" of IP and POTS nodes by reassigning some of
the fixed fields when they appear in an IP row... however, this would
complicate my simple replacement of existing data for subsequent lines
proposal...

[trim]

 FV>> That would work. Like I said, the format of the new
 FV>> list is not a problem and is expandable. The old list
 FV>> is generated from the new list and has no way to be
 FV>> wrong...

 JB> depends what you mean by "wrong"... a certain zone 1
 JB> sysop who I meantioned earlier has some ususual ideas
 JB> about what comprises a valid nodelist entry.

if that's sysop is who i think it is, he tends to push the envelope on many
things... reasoning is something like "if its not explicitly
disallowed, it must be allowed"...

 FV>> if the conversion program is done right. The new list
 FV>> could have a flag at position 11 that indicated the
 FV>> type of connection.. IE: ION for Internet only - no
 FV>> POTS. IPN for Internet and POTS. Then the other flags
 FV>> could tell what "protocol" is available at that Node.
 FV>> IE: IBN for binkp and so on.

 JB> no. that's not what I mean at all. one connectio-type
 JB> flag per connection. if they're posts only they start
 JB> with a pots connection-type flag and omit the IP flag,
 JB> if they're IP only then they omit the POTS connection.

my (2nd) proposal allows for just this... the 1st one does too but it's
harder to add additional capabilities to...

 JB>  ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
 JB>    IP,IP.or.url.com,CM_MO_LO_IBN_ITN,
 JB>    POTS,,33600_V34_V42b_CM_XA

 JB>  ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
 JB>    POTS,,33600_V34_V42b_CM_XA

 JB>  ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
 JB>    IP,IP.or.url.com,CM_MO_LO_IBN_ITN,

why not just put the indicator at the beginning of the row and
"meld" the info that is the same from the previous lines??

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

 JB> we're doing the new list because the existing list it
 JB> not easily extensible to a new type of connection while
 JB> trmaining compatible with existing software, I'm not in
 JB> favour of replacing it with something that still can't
 JB> take a new connection type.

my second proposal allows for future connection types... all it takes is
defining the indicator for the new type and then adding a row with the
specific (and altered from the previous row(s)) data needed for the
connection type...

 FV>> The important thing is that there be order in the new
 FV>> list.

 JB> no, doing that encourages people to read the list a line
 JB> at a time. that leads to problems if they don't allow
 JB> enough space for their line.

uh, you still have to read the list a line at the time... the only space
problem is with current nodelist processing utils... the spec and future
utils would (have to!) allow or specifically state what the limits are... i
see no problems (currently) with limiting line lengths to 255 characters in
the new format as long as conversion utils handled the >158 (i think it
was) limit of any utils currently in use... makenl being the main culprit,
TTBOMK...

 FV>> IE: field 1 is for this and field 2 is for that

 JB> my way theres' 6 fixed fileds, then the rest come in
 JB> groups of 3 - field n is the address type (currently
 JB> POTS, ISDN, or IP) filed n+1 is the address (as
 JB> aproprtiate for the address type) field n+2 is flags
 JB> pertaining to that connection filed n+3 (if present)
 JB> indicates another connection is listed so you do n=n+3

still have some problems with this format, i'm positive... however, i
cannot think of anything other than linelength parsing at the moment...

 JB> POTS and ISDN could be combined but it's hard to pick which
 JB> ISDN nodes don't handle POTS modems,

for those systems, a simple ISDN indicator (falls into my second proposal)
would suffice... if there is POTS and ISDN rows, then both are accepted...
otherwise, one or the other...

 JB> the fact that you can't fit all the information from this
 JB> into a regular nodelist isn't a problem. users of the
 JB> conversion software would set up some rules about which
 JB> connection types they prefer and the software would
 JB> examine the fileds and spit out a SLF nodeline with the
 JB> most suitable connection type listed (or possibly PVT etc
 JB> if nothing was suitable)

i disagree with the initial portion... _developers_ would set up the
rulesets... the users may select the rulesets their systems can handle...

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

 JB> grouping it makes it easier to scan in some languages (you
 JB> could use a string searching function)

agreed but then coding for this stuff wouldn't be much "fun"
>

[trim]

)\/(ark