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?   
      
    MvdV> That's exactly what it is supposed to do! Should I have called it   
    MvdV> AllowHighAscii to make it more clear for you? ;-)   
      
   or perhaps you misunderstood me? bj”rn's patched makenl (2.51??) already   
   allowed this years ago when he let it out for everyone to use... automatically   
   and no config verbs or similar...   
      
    ml>  i don't recall the nodelist being specified as CP437 but   
    ml> traditionally, that is what it has been...   
      
    MvdV> Certainly not! The nodelist is and never was CP437. It is and   
    MvdV> always has been plain ASCII.   
      
   pedantry bites again :( DOS machines have uses CP437 as their base default   
   since way back when... fidonet was created in the US where the St. Louis   
   nodelist format was created... the US used CP437 as the default back then...   
   so, when creating a text file on a DOS machine, what codepage do you suppose   
   is/was used?? forgive me for trying to be more accurate but it never seems to   
   be right in someone's eyes...   
      
    MvdV> In all the history of Fidonet there never was a global nodelist    
    MvdV> published with characters > 127. Not thet I know of anyway.   
      
   then you've not been paying attention... unless i'm mistaken, bj”rn's patched   
   makenl allowed for such and he did post his segment with such at one time...   
   however, if others up the line refused to use that patched makenl (ie: Z2)   
   then that's a "local" or "regional" problem... this could have been being done   
   years ago... at least since 1999 IIRC...   
      
    MvdV>> Correctly in what character encoding scheme?   
      
    ml> ewww... that's gonna be a very ugly can-o-worms :/   
      
    MvdV> One that has to be addressed nonetheless. If we allow characters   
    MvdV> > 127 in the nodelist, we shall have to agree on a common   
    MvdV> encoding scheme. And CP437 won't do.   
      
   it has worked for years within limits... until things can be worked out, it is   
   better than nothing and better than the current 7bit limitation in some folks'   
   eyes...   
      
   but whatever... i'm not here to argue with you or anyone else... i was only   
   offering a solution that already existed with no modifications to the control   
   files...   
      
   [trim]   
      
    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...   
      
    MvdV> Then you just stick with ASCII and stay behind....   
      
   you really need to not be so damned myopic, michiel... my comment was about   
   not getting involved in yet another (stupid??) (heated??) argument with those   
   that think they know better than anyone else no matter who they are...   
      
    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?   
      
    MvdV> You are mixing layers.    
      
   sorry, but no... where were you years ago when the discussions about the XML   
   nodelist format stuff were raging on and on? this would be back when Dale Ross   
   was a member of the network and a big proponent of such...   
      
    MvdV> If the nodelist processing software passes characters above  127    
    MvdV> "as is" instead of replacing them with a question mark, it opens    
    MvdV> the door to any encoding scheme,   
      
   it hasn't so far and it has been available since at least 1999...   
      
    MvdV> including UTF-8. From the transport layer's POV, UTF-8 is just a   
    MvdV> string of bytes, none other than any other encoding like CP437 or   
    MvdV> CP866.   
      
   why are you confusing the transport layer with this? the transport layer has   
   nothing to do with this... we're talking about a text file residing on storage   
   media read by software and humans used as a phone book of all systems in the   
   network... this isn't rocket science, man...   
      
   )\/(ark   
      
   ---    
    * Origin:  (1:3634/12.42)