Re: [I18ndir] [art] Just uploaded draft-bray-unichars-03

[Steffen Nurpmeso <[e-mail]>]

Tim Bray wrote in
 <CAHBU6iuixTeS=[e-mail]>:

i make a tit for tat short thing.

 |On Sep 9, 2023 at 9:58:43 AM, Steffen Nurpmeso <[e-mail]> wrote:
 ...
 |In 2.2.2.2 i would not say "legacy controls", and that they are
 |> "mostly obsolete".  ECMA-48 is very alive in at least the POSIX
 |> aka Linux world, for many purposes, for example terminal
 ...
 |So, in section 23.1 of [UNICODE] it says "There are 65 code points set
 |aside in the Unicode Standard for compatibility with the C0 and C1 control

Unicode's lower 256 is 1:1 ISO-8859-1.  Yes.

  ...
 |practices may survive in legacy systems but I am pretty sure they are not
 |relevant to any protocol or data format the IETF might work on. This
 |clearly feels like “legacy” and “mostly obsolete” to me. (For those who

To you maybe, but surely not for data that is passed around in
protocols.  Yes, those have the dedicated Cc character class.
But since you seem to address implementors of new protocols, why
does it matter, say?  They can give meaning just as they want.
You mutilate for no reason, and falsely.

The Unicode you quote also has the desire to push people away from
using old controls when they have better ones available, for
example to separate paragraphs in plain text.  This is an old
habit of elder programmers who lived in times when there was no
other possibility, *therefore* slapping "legacy" to force people
to look around seems like an understandable and laudable
reasoning.
It does not mean anything else in practice, as an incredible
amount of protocols makes use of those characters, terminals will
not work, and, in fact, new ones are invented in the OSC space.
Heck, you do not seem to read the Unicode mailing-lists even,
Kent Karlsson was (and likely still is) working on an inofficial
update on ECMA-48.  It was on unicode@, last in January 2023.
(I, mind you, said "whether it will fly .. who can tell".
He is on github, kent-karlsson.)

  ...
 |> No.  Not me.  Sorry .. we are talking string data?
 |> I mean, with your restriction one (possibly) cannot even generate
 |> a protocol that carries around Linux/POSIX path names?
 |
 |Which characters necessary for Linux/POSIX path names are being excluded?
 |I went looking for the appropriate specs but ended up getting lost in

You make a valid claim, as looking at the Wikipedia page revealed
that in the Microsoft world filenames can also contain almost any
byte value.  (But be aware of special names like "aux".*, and
there are others.)

 |opengroup.org pages.  I note that for 25 years, the lifetime of XML, the
 |exclusion of control codes with the exception of \r, \t, and \n, seems to
 |have worked fine.

Polemically speaking you refer to that <de-/humanized/ mutilated
SGML that was invented to allow for simpler and safer parsers and
a more secure network.  A goal that <was> achieved</>.
XML is as sensitive as JSON, interesting exactly you mention it.
I in turn note that you refer to a data format but speak about
a protocol.
It seems to me, for me, it is rather useless to say anything.

I for one strongly protest against _any_ byte being excluded from
about anything.  Because why should you.  But treating the
existence of some bytes as "programming error"s is beyond my
understanding.
In text data: not even a replacement character, not even BOM, not
even what-not?  No.

Thank you.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)