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