JB>> why noty use the extensions to reduce size of the fixed component
 JB>> to the essentials.

 ml> i just see no need to go to that level... plain ASCII text is fine
 ml> and we don't really need to go adding 's to
everything,
 ml> do we

I was just describing my proposal.... with 6 fixed fileds and then 3*n
optional fileds... each 3 fileds describing a connection method,
I wasn't suggesting XML style tags... I 've given up on them.

 ml>>> then you loose the placeholders... they are needed if they are
 ml>>> the first row for that entry, too..

 JB>> what I meant was by putting POTS into the extension there's no
 JB>> need for empty fields, on non-pots systems.

 ml> won't be any empty fields, i don't believe...

how do you represent a private node?

 JB>> if is there's a flag on the first row that you don't want on the
 JB>> second row, what do you do...

 ml> redefine that flag sequence on the subsequent row(s)

huh?

 JB>> put it last on the fisrs row and use fewer commas on the second
 JB>> row? (could work but could trap many programmers)

 ml> no, the flags section is a comma seperated list just like the
 ml> row... kinda like an OOP object as a data item in another OOP
 ml> object..

huh? do you mean the flags section is treated like a single field?
so if there are any flags on a line all the flags from the line above are
ingnored for the current line?

 -=> Bye <=-

---