Not a high priority issue, but I suggest you change the IBMPC charset identifier to CP437.
See "5. Obsolete identifiers" in FTS-5003 for more info. http://ftsc.org/docs/fts-5003.001

Carlos

--- WinPoint 389.0
* Origin: Original *WinPoint* Origin (2:341/234.5)

//Hello Carlos,//

on *19.01.22* at *20:42:50* You wrote in rea *WINPOINT*
to *Tim Schattkowsky* about *"IBMPC vs CP437"*.

Not a high priority issue, but I suggest you change the IBMPC charset identifier to CP437. See "5. Obsolete identifiers" in FTS-5003 for more info. http://ftsc.org/docs/fts-5003.001

Nope. I think IBMPC is more compatible. Still, WP itself recognizes both.

Regards,
Tim
--- WinPoint 393.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

19 Jan 2022 22:23, you wrote to me:

Not a high priority issue, but I suggest you change the IBMPC
charset identifier to CP437. See "5. Obsolete identifiers" in
FTS-5003 for more info. http://ftsc.org/docs/fts-5003.001

Nope. I think IBMPC is more compatible. Still, WP itself recognizes
both.

FTS-5003 considers IBMPC obsolete (see sections 4 and 5). If I'm not mistaken most /modern/ FTN software uses CP437 instead.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

//Hello Carlos,//

on *25.02.22* at *18:31:48* You wrote in Area *WINPOINT*
to *Tim Schattkowsky* about *"IBMPC vs CP437"*.

FTS-5003 considers IBMPC obsolete (see sections 4 and 5).

Correct.

If I'm not mistaken most modern FTN software uses CP437 instead.

Since there exists software that only works with IBMPC and all software using CP437 is probably supporting IBMPC is well, it makes most sense to write IBMPC to the kludge to maximize compatibility. Why would anyone want to move to a less compatible alternative to feel better about standards that are intended to describe the current technical practice?

For the fun of it: What would be the benefit of writing CP437 instead of IBMPC?

Regards,
Tim

--- WinPoint 400.3
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hello Tim,

On Friday February 25 2022 20:21, you wrote to Carlos Navarro:

FTS-5003 considers IBMPC obsolete (see sections 4 and 5).

Correct.

So why not follow FTS-5003? Trying to outsmart the FTSC is not really such a smart idea.

If I'm not mistaken most modern FTN software uses CP437 instead.

Since there exists software that only works with IBMPC and all
software using CP437 is probably supporting IBMPC is well, it makes
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?

Why would anyone want to move to a less compatible alternative to feel better about standards that are intended to describe the current
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?

For the fun of it: What would be the benefit of writing CP437 instead
of IBMPC?

Uniquely identifying the encoding method?


Cheers, Michiel

--- Fmail, Binkd, Golded
* Origin: he.net certified sage (2:280/5555)