Hello mark,   
      
   On Thursday January 10 2013 14:47, you wrote to me:   
      
    MvdV>> I am all for lifting the ASCII only limitation for the   
    MvdV>> nodelist. Seo Andrew how about an option:   
      
    MvdV>> AllowNonAscii 0|1    ??   
      
    ml> why? why not just allow the the current set plus those above 127?   
      
   That's exactly what it is supposed to do! Should I have called it   
   AllowHighAscii to make it more clear for you? ;-)   
      
    ml>  i don't recall the nodelist being specified as CP437 but   
    ml> traditionally, that is what it has been...   
      
   Certainly not! The nodelist is and never was CP437. It is and always has been   
   plain ASCII. In all the history of Fidonet there never was a global nodelist   
   published with characters > 127. Not thet I know of anyway.   
      
    MvdV>> Correctly in what character encoding scheme?   
      
    ml> ewww... that's gonna be a very ugly can-o-worms :/   
      
   One that has to be addressed nonetheless. If we allow characters > 127 in the   
   nodelist, we shall have to agree on a common encoding scheme. And CP437 won't   
   do.   
      
    MvdV>> Because here is where I see an issue. If 7 bit only was forced   
    MvdV>> on us by what now is a majority, we do not want to do the same   
    MvdV>> unto others do we? I strongly suspect that you used an 8 bit   
    MvdV>> character set for your Umlaut experiment. Like CP850 or   
    MvdV>> Latin-1. That is fine for us Western Europeans who need umlauts   
    MvdV>> and accnets.  But not so fine for what is now the majority:   
    MvdV>> those who use a cyrillic character set for their native   
    MvdV>> languages. It is them that are the majority now. They need   
    MvdV>> CP866 or KOI8R...   
      
    ml> so from a human aspect, if one cannot read cryllic, how is one   
    ml> supposed to address messages to someone using cryllic glyphs? address   
    ml> numbering aside, how can they tell they are choosing the proper entry   
    ml> from the nodelist?   
      
   Maybe that question can be answered by looking at it from the other side. How   
   can someone who was born and raised in Russia and wo can not read English   
   address a message to someone using the latin glyphs? How can they tell they   
   choose the proper entry fro the nodelist?   
      
   Think about it.   
      
    MvdV>> Surely we do not want to force CP850 or Latin-1 one onto them   
    MvdV>> do we?   
      
    ml> what are they using now for communicating with the rest of the   
    ml> network?   
      
   Messages origintaing from the cyrillic countries are usually encoded in CP866   
      
    MvdV>> Unfortunately I see no practical way to swicth charactere   
    MvdV>> encoding on the fly in the nodelist. Also unfortunately there   
    MvdV>> is no 8 bit character set that covers both umlauts, accents AND   
    MvdV>> cyrillic.   
      
    ml> agreed... the nodelist is the glue that holds the network together...   
    ml> as such, there must be a baseline that all systems and participants   
    ml> can use, IM(H)O...   
      
   The primary function of the nodelist is to provide connection information to   
   machines. The machines do not care if a string of bytes in the fields that   
   carry names of syspos or places is human readable, for them it is just a   
   string of bytes.   
      
    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...   
      
   Then you just stick with ASCII and stay behind....   
      
    ml> it'll be almost the same "argument" that there was years ago about   
    ml> other changes in the nodelist... perhaps it would be better to have   
    ml> two formats... the traditional one opened up somewhat for characters   
    ml> above 127 and another one using utf-8 or so?   
      
   You are mixing layers. If the nodelist processing software passes characters   
   above  127 "as is" instead of replacing them with a question mark, it opens   
   the door to any encoding scheme, including UTF-8. From the transport layer's   
   POV, UTF-8 is just a string of bytes, none other than any other encoding like   
   CP437 or CP866.   
      
      
   Cheers, Michiel   
      
   --- GoldED+/W32-MINGW 1.1.5-b20110320   
    * Origin: http://www.vlist.eu (2:280/5555)