ml> why? why not just allow the the current set plus those above 127? i   
    ml> don't recall the nodelist being specified as CP437 but traditionally,   
    ml> that is what it has been...   
      
    AL> The current version of FTS5000 specifies the 7-bit ASCII character   
    AL> set, with only CR (0x0D), LF (0x0A), and EOF (0x1A) control   
    AL> characters permitted.    
      
   while that may be true, i've already pointed out (more than once in several   
   areas) that the software and usage determine the specs that get documented...   
   not the other way around... especially since the FTSC documents (current)   
   practise... this is quite contrary to the way the internet works, BTW...   
      
    MvdV>> Correctly in what character encoding scheme?   
      
    ml> ewww... that's gonna be a very ugly can-o-worms :/   
      
    AL> You can say that again!   
      
    MvdV>> So... /if/ we allow non ASCII in the nodleist, it will have to   
    MvdV>> be encoded as UTF-8.   
      
    ml> don't want to go there... it'll be almost the same "argument" that   
    ml> there was years ago about other changes in the nodelist... perhaps it   
    ml> would be better to have two formats... the traditional one opened up   
    ml> somewhat for characters above 127 and another one using utf-8 or so?   
      
    AL> Since the nodelist defines FidoNet, I don't think we can really do   
    AL> that without a mechanism for resolving differences between the two   
    AL> formats.    
      
   what mechanism is needed? you either install the normal st louis nodelist or   
   you install the modified whatever format nodelist... this is no different than   
   using the nodelist or the binkd.txt "nodelist" for one's FTN mail transfer   
   agent...   
      
   )\/(ark   
      
   ---    
    * Origin:  (1:3634/12.42)