TID: FMail-W32 2.1.3.7-B20170919   
   TZUTC: 0200   
   CHRS: UTF-8 4   
   PID: GED+W32 1.1.5-b20170303   
   MSGID: 2:280/5555 6266a87e   
   REPLY: 2:240/1120.29 3affbc07   
   Hello Tim,   
      
   On Friday February 25 2022 20:21, you wrote to Carlos Navarro:   
      
    CN>> FTS-5003 considers IBMPC obsolete (see sections 4 and 5).   
      
    TS> Correct.   
      
   So why not follow FTS-5003? Trying to outsmart the FTSC is not really such a   
   smart idea.   
      
    CN>> If I'm not mistaken most modern FTN software uses CP437 instead.   
      
    TS> Since there exists software that only works with IBMPC and all   
    TS> software using CP437 is probably supporting IBMPC is well, it makes   
    TS> most sense to write IBMPC to the kludge to maximize compatibility.   
      
   Your logic is flawed for several reasons:   
      
   1) That there exists software that only supports IBMPC is an assumption and   
   assumptions often are wrong. I do not know of such software still being in   
   use, but of course I do not know everything.   
      
   2) The assumption that all software that supports CP437 also supports IBMPC is   
   incorrect. Golded for example does not support IBMPC without the user   
   explicitly configuring it. And since the FTSC lists IBMPC as obsolete and   
   deprecated, some will not configure it.   
      
   3) On top of that the follow up assumption that all software that supports   
   both IBMPC and CP437 treats IBMPC it as an eqaivalent of CP437 is definitely   
   incorrect.   
      
   From FTS-5003:   
      
   5. Obsolete indentifiers   
   ------------------------   
      
     These indentifiers must not be used when creating new messages.   
     The following only applies to processing messages that were   
     created using old software.   
      
     Since the "IBMPC" identifier, initially used to indicate IBM   
     codepage 437, eventually evolved into identifying "any IBM   
     codepage", there exists in some implementations an additional   
     control line, "CODEPAGE", identifying the messages codepage:   
      
            "^ACODEPAGE: xxx   
      
     This use is deprecated in favour of the "CPxxx" identifiers   
     defined above. If found in incoming messages, however, it should   
     be used as an override of the "CHRS: IBMPC" identifier.   
      
   The key words here are:  'eventually evolved into identifying "any IBM   
   codepage"'. IOW the IBMPC identifier does not uniquely identify the encoding   
   method. It could be used as an alias of CP437, but it may just as well mean   
   CP850 or even CP866. Would you not say that for this reason alone the FTSC has   
   very good reason to depricate the use of IBMPC in new messages?   
      
    TS> Why would anyone want to move to a less compatible alternative to feel   
    TS> better about standards that are intended to describe the current   
    TS> technical practice?   
      
   Indeed, why would anyone want to go back to the less compatible alternative of   
   the ambigueos IBMPC identifier instead of just following the FTSC standard   
   that has unique identifiers for each encoding scheme?   
      
    TS> For the fun of it: What would be the benefit of writing CP437 instead   
    TS> of IBMPC?   
      
   Uniquely identifying the encoding method?   
      
      
   Cheers, Michiel   
      
   --- Fmail, Binkd, Golded   
    * Origin: he.net certified sage (2:280/5555)   
   SEEN-BY: 15/0 106/201 124/5016 129/331 153/757 7715 203/0 218/700   
   SEEN-BY: 221/0 229/110 111 317 426 428 470 664 700 240/1120 266/512   
   SEEN-BY: 280/464 5003 5555 282/1038 292/854 8125 301/1 310/31 317/3   
   SEEN-BY: 320/219 341/234 396/45 460/58 712/848 770/1 2452/250   
   PATH: 280/5555 464 712/848 229/426