<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div>
<br>
</div>
<blockquote type="cite">
<div>
On 17/08/2022 12:49 Asmus Freytag via Unicode <unicode@corp.unicode.org> wrote:
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div class="moz-cite-prefix">
A process <em><strong>may </strong></em>treat two canonically equivalent sequences differently. For example when determining how to allocate buffers, any length difference matters and may, at some point, surface to the user, if not intentionally.
</div>
<div class="moz-cite-prefix">
<br>
</div>
<div class="moz-cite-prefix">
This case seems somewhat equivalent.
</div>
<div class="moz-cite-prefix"></div>
</blockquote>
<div>
Not really. Different treatment seems actually to be the preferred outcome. There are actually weak cases for disunification.
</div>
<blockquote type="cite">
<div class="moz-cite-prefix">
What the conformance clause intends is that processes (and protocols for that matter) don't intentionally rely on the differences in encoding. (However, for example, a protocol may require a particular normalization form, while rejecting unnormalized data).
</div>
<div class="moz-cite-prefix">
<br>
</div>
<div class="moz-cite-prefix">
[If people feel that this is forbidden by the current conformance clause, we would have serious troubles with protocols like IDNA2008 which enforce Normalization Form NFC for representation of data at certain interfaces.]
<br>
</div>
<div class="moz-cite-prefix"></div>
</blockquote>
<div>
Why? The protocol’s simply non-compliant with C6. It’s not as though Microsoft renderers are compliant with C6, unless that has changed since Windows 10. (The dotted circles on some Tibetan canonical equivalents are very much an active design choice, while Uniscribe and USE attacks on NFD Sinhalese may be C6-compliant cost-cutting rather than deliberate.) UTS #18 Regular Expressions has despaired of regular expression engines complying with the spirit of C6, and has suggested a rather manual work-around. UAX #14 Unicode Line Breaking Algorithm countenances a tailoring with the algorithm violating C6 for characters with Line_break=Ambiguous.
</div>
<blockquote type="cite">
<div class="moz-cite-prefix">
A minor infidelity in script run parsing doesn't appear to rise to the level of concern that was the focus of the conformance clause about treating different normalizations differently.
</div>
<div class="moz-cite-prefix">
<br>
</div>
<div class="moz-cite-prefix">
That said, it's strongly preferable to design properties with closure under normalization, but edge cases like this need to be handled with some understanding of what the costs and benefits are of trying to implement such a guarantee.
</div>
<div class="moz-cite-prefix"></div>
</blockquote>
<div>
I can see why some properties are not closed under normalisation, and I’m not asking for changes.
</div>
<div class="default-style">
<br>
</div>
<div class="default-style">
So, are C6 and compliance with Requirement UTS#18 RL1.2 Properties compatible? At least RL2.1 Canonical Equivalents is empty enough for compliance to be claimed whatever. RL2.7 Full Properties requires properties that by design are not closed under normalisation, such as NFC_Quick_Check.
</div>
<div class="default-style">
<br>
</div>
<div class="default-style">
Richard.
</div>
<blockquote type="cite">
<div class="moz-cite-prefix"></div>
<div class="moz-cite-prefix">
<br>
</div>
<div class="moz-cite-prefix">
<br>
</div>
<div class="moz-cite-prefix">
<br>
</div>
<div class="moz-cite-prefix">
On 8/16/2022 1:10 AM, Richard Wordingham via Unicode wrote:
<br>
</div>
<blockquote type="cite">
<pre class="moz-quote-pre">On Mon, 15 Aug 2022 11:38:24 -0700
Markus Scherer via Unicode <a href="mailto:unicode@corp.unicode.org" class="moz-txt-link-rfc2396E"><unicode@corp.unicode.org></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre">... and which
value you think we should change to what other value.
</pre>
</blockquote>
<pre class="moz-quote-pre">I wasn't suggesting that values may be changed, though my question may
constitute evidence that some values should be changed. My question
was as to how we should handle the anomalies while complying with
conformance requirement C6 in TUS Section 3.2. Perhaps some
Unicode properties are simply inconsistent with that requirement. If
anything should be changed, perhaps it is the guidance on regular
expressions.
Richard.
</pre>
</blockquote>
<p><br></p>
</blockquote>
</body>
</html>