AΑА Αbsurdity of Unicode

[MasterInQuestion]

    Up: https://github.com/MasterInQuestion/Markup/blob/main/AAA.htm

    [ Quote verdy-p @ CE 2023-05-29 18:34:28 UTC:
https://github.com/notofonts/latin-greek-cyrillic/issues/234#issuecomment-1567414459
    Unicode/ISO/IEC 10646 does not encode glyphs, but characters for their semantics and fundamental properties. ]
<^>    Exactly how things end up with such AAA Capital Extraordinariness.
    .
    https://www.bing.com/images/search?view=detailv2&iss=SBI&sim=10&q=imgurl:https://github.com/MasterInQuestion/attach/raw/main/MasterInQuestion/talk/4/Sight-Exam.webp
    Confusables usable..?

    [ Quote (previous):
    Confusable characters that belong to very different alphabets, this also sort differently in multilingual sequences (with primary differences), and that were disunified everywhere (including in ISO 15924) have a real sense. ]
<^>    Real sense that hardly makes any sense.
    Sorting itself would whatsoever give undeterministic result in general. (because of the undeterministic sorting weight)
    Disunified mostly for backward compatibility (during conversion): courtesy of illy designed legacy encodings that invented the ideological "E".

    "... whole specifications about how to detect confusables ..."
<^>    Whole awkward and poorly extensible.

    "alphabets do not necessarily supprot the same variations of glyph styles."
<^>    Another Absurdity: identical representation for distinct definitions.

    "... i18n domain names ..."
<^>    Speaking of IDN, I've always found it quite like a joke:
[[

http://	Latin
ηττπ://	Greek
нттп://	Cyrillic

http://
ηττρ://
нттp://

]]
    Either way absurd; and interoperability havoc.

[verdy-p]

    [ Quote (previous):     ... i18n domain names ... ] <^>    Speaking of IDN, I've always found it quite like a joke: [[

http://	Latin
ηττπ://	Greek
нттп://	Cyrillic

http://
ηττρ://
нттp://

]]     Either way absurd; and interoperability havoc.

IDN never internationalizes protocol schemes. They are NOT domain names. The same is true for path parts in URIs.

Please so not confuse URIs with IDNs. URIs are specified in completely independant RFCs (and not all URI schemes allow internationatilization, e.g. UUIDs, URNs, "tel:" for phone numbers, etc...

Some URI schemes may embed an IDN, but URIs won't alter at all the contained IDN.

Standard URI schemes are registered in separate registries (and many of them are defined privately for apps and are not even interoperable across systems; standard URI schemes are only valid as specified in their relevant standard RFC, if there's one).

[MasterInQuestion]

    I perfectly aware that the mentioned example is a joke. (as mentioned, though not very explicitly)
    Contrived based on exactly the same rationale that caused IDN:
https://unicode.org/reports/tr46/#Introduction
    “... restricted to ASCII characters ... significant burden on people using other characters.”

    It feels you are confused and didn't manage to see the essence. (or probably just refuse to?..)

----

[ verdy-p @ CE 2024-01-10 14:16:46 UTC:
https://github.com/notofonts/latin-greek-cyrillic/issues/234#issuecomment-1576516761
    Look at the reply I've made there.
    You are making confusions between URI and IDN:
    They are specified completely independantly, even if some "URI schemes" allow embedding 1 or more IDN in a single URI.

    URI use an encoding scheme (restricted in its charset specified for each URI part), which is completely independant from the encoding scheme in IDN:
    Specified using Punycode, based on DNS restrictions, plus registrar-specific restrictions for their permitted subset.

    Each registrar for each specific domain or sub-domain may forbid or permit confusable characters in labels.
    But it's not their job to "canonicalize" characters they consider equivalent.
    And they are not required to make such remapping: even if they apply some restrictions, where all confusable domain labels are reserved at the same time.
    They are not required to however implement CNAME aliasing.

    And generally using CNAME is a bad practice notably for secured domain names [1], unless:
    |*| PKI certificates for a given domain are enumerating all their possible CNAME aliases implemented by the registry.
    |*| Or are using wildcard entries which are also known to be security issues.
    (that's why DNS providers disable wildcards by default, for all domains they are hosting)
    .
[1] Almost mandatory now for URL on the web: as many more web browsers are blocking or suppressing support for unsecured HTTP and FTP.


    Please read RFC carefully: this is not something you can guess with insufficient assumptions.
    This is absolutely not "absurdity".
    And all this is completely independant of Unicode ISO/IEC 10646 standards.

    What would be "absurd", would be to make false assumptions, because you understand those topics only superficially.
    These restrictions and specifications are very important: for all users everywhere in the world and for all apps, for interoperability and security.

    And AAAA records in DNS are not specific to Unicode: they are for IPv6 (absolutely needed today by many millions users).
    But IPv4 and IPv6 are also fully independant of character encodings used in labels for domain names:
    .
    The same domain name:
    Whether its labels are internationalized using Punycode:
    Or restricted to the small ASCII subset, with only Basic Latin letters, single dashes or digits:
    Can be registered to provide resolution for both IPv4 and IPv6 with A and AAAA records. ]

----

    You must be making a confusion of the entire topic...

    I've seen enough havocs the various standards wreaked.
    And the IPv6 non-sense... The only use I find with it is tracking and surveillance.

[MasterInQuestion]

    Even specifically having the realm restricted to domain names:
    |*| "github.com"
    |*| "叽特哈.亢亩"
    ; localized anyhow unlike domain names and violates the general expectation.

    Such is also the predicament that circumscribed the multi-lingual support for CLI and programming languages.