On 12/11/14, 7:13 PM, Peter Saint-Andre - &yet wrote:
On 12/11/14, 4:53 PM, Patrik Fältström wrote:
On 11 dec 2014, at 17:43, Peter Saint-Andre - &yet <[email protected]>
wrote:
On 12/10/14, 11:22 PM, Patrik Fältström wrote:
On 11 dec 2014, at 05:36, Peter Saint-Andre - &yet
<[email protected]> wrote:
Are you saying that there are code points that match, say, the
LetterDigits category ("A") and the IgnorableProperties category
("C") and the OldHangulJamo category ("I")?
Yes. There are in fact two codepoints that matches all of A, C and I
at the same time. U+115F and U+1160.
Hope this below give you some data. The file allcodepoints.txt is one
I have produced with one of the software packages I have written as
part of my role as appointed expert re. IANA and IDNA. The file is in
this example generated for Unicode 7.0.0.
That's great, thank you.
Although it's good to know about this overlap, I am wondering if in
practice it matters because in both IDNA2008 and PRECIS we specify
the order of operations. Do you think we need to have an
informational note about this in the framework, though?
Not as long as the _result_ of the actions you suggest leads to a
stable result.
I.e. either your rules are stable (and leads to stable result) or not.
Clarifying language that explain is not what you need in this case.
Either the rules are clean or not.
Indeed.
You highlight the following possibilities:
AB ABC ABF AC ACI AD AE AF AI
In PRECIS, we don't use categories B, C, D, and E.
Thus if we have concerns, they would be over AF (LetterDigits and
Exceptions) and AI (LetterDigits and OldHangulJamo).
Yet the algorithm seems definitive:
If .cp. .in. Exceptions Then Exceptions(cp);
Else If .cp. .in. BackwardCompatible Then BackwardCompatible(cp);
Else If .cp. .in. Unassigned Then UNASSIGNED;
Else If .cp. .in. ASCII7 Then PVALID;
Else If .cp. .in. JoinControl Then CONTEXTJ;
Else If .cp. .in. OldHangulJamo Then DISALLOWED;
Else If .cp. .in. PrecisIgnorableProperties Then DISALLOWED;
Else If .cp. .in. Controls Then DISALLOWED;
Else If .cp. .in. HasCompat Then ID_DIS or FREE_PVAL;
Else If .cp. .in. LetterDigits Then PVALID;
Else If .cp. .in. OtherLetterDigits Then ID_DIS or FREE_PVAL;
Else If .cp. .in. Spaces Then ID_DIS or FREE_PVAL;
Else If .cp. .in. Symbols Then ID_DIS or FREE_PVAL;
Else If .cp. .in. Punctuation Then ID_DIS or FREE_PVAL;
Else DISALLOWED;
The PRECIS framework doesn't allow classes or profiles or applications
to change the order of operations within the algorithm. However, we
could add normative language about that in the spec (which doesn't
currently say that you MUST NOT change the order).
That is, I would propose this change in Section 8...
OLD
The algorithm to calculate the value of the derived property is as
follows:
NEW
The algorithm to calculate the value of the derived property is as
follows (implementations MUST NOT modify the order of operations
within this algorithm, since doing so would cause inconsistent
results across implementations):
Peter
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
