 Relationships |
|
| Anonymous | Login | 2024-09-07 15:25 UTC |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Category | Severity | Type | Date Submitted | Last Update | ||||||||
| 0001793 | [1003.1(2016/18)/Issue7+TC2] Front Matter | Editorial | Enhancement Request | 2023-12-19 02:02 | 2024-01-29 16:23 | ||||||||
| Reporter | steffen | View Status | public | ||||||||||
| Assigned To | |||||||||||||
| Priority | normal | Resolution | Accepted As Marked | ||||||||||
| Status | Resolved | ||||||||||||
| Name | steffen | ||||||||||||
| Organization | |||||||||||||
| User Reference | |||||||||||||
| Section | many | ||||||||||||
| Page Number | many | ||||||||||||
| Line Number | many | ||||||||||||
| Interp Status | --- | ||||||||||||
| Final Accepted Text | Note: 0006646 | ||||||||||||
| Summary | 0001793: Streamline US-ASCII character set name | ||||||||||||
| Description |
It is a bit over the top maybe, but the standard uses the alias "ASCII" to denote ANSI_X3.4-1968. This is of course ok as "ASCII" is an official alias. There are occurrences of "US ASCII", however, which is not: the real alias IANA alias name is "US-ASCII". |
||||||||||||
| Desired Action |
- change occurrences of "US ASCII" with either "ASCII" or "US-ASCII". - i personally would create a roff string/macro and use that everywhere instead of ASCII or "US ASCII". - maybe describe somewhere in the preamble where many ANSI things are clarified that "ASCII" really means ANSI_X3.4-1968 of the IANA character set database. |
||||||||||||
| Tags | tc1-2024 | ||||||||||||
| Attached Files | |||||||||||||
|
|
|||||||||||||
|
Relationships |
|
|
Notes |
|
|
(0006613) shware_systems (reporter) 2024-01-04 16:05 |
The standard references ASCII in its pre-ISO-2021 versions of the 1960s, as overridden by the C standard. Afaik US-ASCII is a synonym for the current version of ISO-646, which defers to ISO-2021, not POSIX or C, for how control codes are expected to function. As such references to US-ASCII should probably be shortened to just ASCII. |
|
(0006615) steffen (reporter) 2024-01-04 22:02 |
Ooooh, careful with that axe -- greetings to the big apple!!! I quote art(at)ietf.org and John C. Klensin, he will excuse this. (And point out that _i_ do not follow him.) Starting with IANA and copying the charsets list, as Martin suggests, is almost certainly a good step at this stage (I'm copying IANS on this note to avoid possible confusion). However, to fill in the historical blank: the omission was almost certainly deliberate (I vaguely recall being part of the discussion). While I found the idea of "US-ASCII" obnoxious (and still do -- after all, the "A" in ASCII does not stand for "Antarctic" or a variety of other options), it was very common practice in the 1990s to use the term "ASCII" to refer to a variety of character sets that used the high order bit of an octet (including ISO 8859 -- the omission of "-1" is deliberate) and even used "ASCII" to refer to assorted national language variations and national variations on ISO 646. So "ASCII" was avoided because it was seriously ambiguous. There is evidence that the confusion continues: the definition of IBM CP 367 ("IBM367" and "cp367" in the IANA registry) [1] as a synonym for "US-ASCII" is incorrect or at least sketchy because it lists iso-646.irv:1983 as another synonym and ISO 646 IRV did not match ASCII until 1991 [2] because, prior to that, the "international currency symbol" was used instead of ASCII's dollar sign. That isn't proof but does suggest that the confusion we say in the 1990s has not completely disappeared. So, coming back to Steffen's suggestion, I strongly recommend against adding "ASCII" to the alias list without an explanation and warning about the ambiguity. And the current registry arrangement does not allow for that sort of note although maybe it should. |
|
(0006636) shware_systems (reporter) 2024-01-22 17:44 edited on: 2024-01-22 17:45 |
Re: 6615 Agreed, there still might be confusion. An alternative is changing all those instances to "PSX-ASCII", or "POSIX-ASCII", and add to XBD3 a definition that specifies how C overloaded <NUL> and <LF> as string terminator and end-of-line, along with making <SI>, <SO>, and <ESC> as having no defined function. This could even be a new IANA registration, I suspect, outside the range reserved to ISO-IR registrations. |
|
(0006637) steffen (reporter) 2024-01-23 00:12 |
(I have no opinion on that. I am in strong favour of readding the ASCII alias that got lost to the IANA database. This issue is because later ones may stumble over the ASCII as IANA is the "official thing", and it has its opinion that i do not understand.) |
|
(0006646) geoffclare (manager) 2024-01-29 16:21 |
Change the three occurrences of "US ASCII" to "ASCII". Add a definition to XBD chapter 3: 3.xxx ASCIIThe character encoding specified by the International Reference Version (IRV) of the ISO/IEC 646: 1991 standard. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2023-12-19 02:02 | steffen | New Issue | |
| 2023-12-19 02:02 | steffen | Name | => steffen |
| 2023-12-19 02:02 | steffen | Section | => many |
| 2023-12-19 02:02 | steffen | Page Number | => many |
| 2023-12-19 02:02 | steffen | Line Number | => many |
| 2024-01-04 16:05 | shware_systems | Note Added: 0006613 | |
| 2024-01-04 22:02 | steffen | Note Added: 0006615 | |
| 2024-01-22 17:44 | shware_systems | Note Added: 0006636 | |
| 2024-01-22 17:45 | shware_systems | Note Edited: 0006636 | |
| 2024-01-23 00:12 | steffen | Note Added: 0006637 | |
| 2024-01-29 16:21 | geoffclare | Note Added: 0006646 | |
| 2024-01-29 16:23 | geoffclare | Interp Status | => --- |
| 2024-01-29 16:23 | geoffclare | Final Accepted Text | => Note: 0006646 |
| 2024-01-29 16:23 | geoffclare | Status | New => Resolved |
| 2024-01-29 16:23 | geoffclare | Resolution | Open => Accepted As Marked |
| 2024-01-29 16:23 | geoffclare | Tag Attached: tc1-2024 | |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
