This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.
Date/Time: Sun Mar 12 07:37:17 CDT 2023
ReportID: ID20230312073717
Name: Ray
Report Type: Error Report
Opt Subject: Confusables Sheet
Letter coptic vedi 'Ⲃ' is not listed as confusable. It is in fact confusable with latin B and its lookalike characters. This leads to unicode text normalization errors where presense of these characters fail to reduce the unicoded string to its ASCII form.
Feedback above this line was reviewed during or prior to UTC #175 in April, 2023
Date/Time: Mon Apr 17 16:44:35 CDT 2023
ReportID: ID20230417164435
Name: Peter G Constable
Report Type: Public Review Issue
Opt Subject: 463
In section 4 of PU UTS #39, there is a block of new text defining bidiSkeleton. The following is included in the steps to derive a bidiSkeleton: Apply rule L3 of the UBA: move combining marks after their base in Z; this yields the sequence R′. But "Z" has not been defined in the prior steps.
Date/Time: Thu May 25 18:27:09 CDT 2023
ReportID: ID20230525182709
Name: Asmus Freytag
Report Type: Public Review Issue
Opt Subject: 463
The statement of conformance for UTS #39 should be brought into better
alignment with the way conformance is stated in other UTSs and UAXs.
Currently:
C1 An implementation claiming to implement the General Profile for
Identifiers shall do so in accordance with the specifications in Section
3.1, General Security Profile for Identifiers.
Alternatively, it shall declare that it uses a modification, and provide
a precise list of characters that are added to or removed from the
profile.
C1.1 An implementation claiming to implement the IDN Security Profiles for
Identifiers shall do so in accordance with the specifications in Section
3.2, IDN Security Profiles for Identifiers.
Alternatively, it shall declare that it uses a modification, and provide
a precise list of characters that are added to or removed from the
profile.
C1.2 An implementation claiming to implement the Email Security Profiles for
Identifiers shall do so in accordance with the specifications in Section
3.3, Email Security Profiles for Identifiers.
Alternatively, it shall declare that it uses a modification, and provide
a precise list of characters that are added to or removed from the
profile.
(italics lost in plain text).
Note that the phrases starting with "Alternatively" are needlessly
repetitive. And, because of the term "Alternatively" they can be
interpreted as overriding the *entire* "shall" clause in the preceding
sentence, erasing any reference to Sections 3.1, 3.2 or 3.3, which cannot
be intended. Also, except for the use of italics, the presentation as a
separate indented paragraph fatally resembles the informative notes present
on so many definitions, rules and clauses elsewhere, and thus casting into
doubt the force and formal nature of these phrases.
It would be better to consolidate them into their own clause which
generically covers the conformance to a modified profile. And used the
phrase "in addition" to make sure that specifying the modifications alone
without reference to the underlying profile is not sufficient.
Finally, conformance without reference to version is meaningless for these
profiles, so a clause remedying that omission is also proposed.
While these proposals do not intend to make any effective changes to the
de-facto requirements for conformance, they clarify the language and
therefore preclude certain unintended interpretations. This means a formal
change to normative language and is therefore proposed here so it can be
reviewed by UTC.
PROPOSED: C1 An implementation claiming to implement the General Profile for
Identifiers shall do so in accordance with the specifications in Section
3.1, General Security Profile for Identifiers.
C1.1 An implementation claiming to implement the IDN Security Profiles for
Identifiers shall do so in accordance with the specifications in Section
3.2, IDN Security Profiles for Identifiers.
C1.2 An implementation claiming to implement the Email Security Profiles for
Identifiers shall do so in accordance with the specifications in Section
3.3, Email Security Profiles for Identifiers.
C1.3 An implementation claiming conformance according to the profiles in C1,
C1.1, or C1.2, but wishing to use a modification, shall additionally
provide a precise list of characters that are added to or removed from the
profile.
C1.4. An implementation that claims to conform to this specification must
reference the version it conforms to.
The version number of this document is synchronized with the version of
the Unicode Standard which specifies the repertoire covered. See also
The Unicode Standard, Section 3.1 Versions of the Unicode Standard.
(All but the very last paragraph in italics)
Another question that might be considered is whether to rename the "C"
clauses by a unique prefix "UTS39-", which would bring them more in line
with e.g. UTS10 or the UAXs.