I just wrote a Java test, which checks the idempotency for all code points (0 -
0X10) for all 4 profiles (opaque, username, username preserved, nickname).
The result is as you suspected:
Only the Nickname profile requires additional application of the rules in order
to stabilize the output
I did not come across any code points where IdentifierClass/Usernames
required multiple passes to make the result idempotent. Only the
Nickname profile is affected, due to the interaction between NFKC and
the case/space rules.
My implementation applies an extra iteration for the Nickname profile.
Great, thanks! These code points revealed some bugs :-). They should have been
included in the Examples.
Are there any known code points for the IdentifierClass / Usernames as well?
Seems like all these code points are disallowed anyway.
If not, implementations could save 1-2 iterations and only
Where it makes a difference for NicknameCaseMapped:
"\u210c"
"\u20a8"
Where it makes a difference for Nickname due to spaces:
"\u00a8"
"\u02dc"
On Sat, Dec 9, 2017 at 8:37 AM, Christian Schudt
wrote:
> Hi,
>
> RFC 8264 introduced these new sentences:
>
>under certain circumstances, such a
Hi,
RFC 8264 introduced these new sentences:
under certain circumstances, such as when Unicode
Normalization Form KC is used, performing Unicode normalization after
case mapping can still yield uppercase characters for certain code
points
Therefore, an implementation SHOULD apply
>
> Sigh.
>
> I'm sorry that we failed to make things clear and consistent.
>
> I agree with Bill that implementations should follow the order of rules
> in Section 7 of RFC 8264.
>
> Let me think about how we can clarify things. That might involve filing
> an erratum against RFC 8265.
>
> Pe
