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. The other profiles verify that the result is idempotent and raise a DISALLOWED/not_idempotent error if this is violated. I do not believe there are legal inputs for Usernames which violate the idempotency requirement, so this is purely defensive. On Sat, Dec 9, 2017 at 2:27 PM, Christian Schudt <[email protected]> wrote: > 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 apply the > „3-times“-rule for FreeformClass. > > > >> Am 09.12.2017 um 20:34 schrieb William Fisher <[email protected]>: >> >> 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 >> <[email protected]> wrote: >>> 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 the rules >>> repeatedly until the output string is stable >>> >>> >>> I could imagine these sentences refer to code points of the „Unstable“ >>> category, but this category is unused. >>> >>> Are there any concrete code points or input strings which show this >>> unstable behaviour? >>> I am asking for some test vectors, i.e. an input string, which doesn’t have >>> the expected output string after the first rule application, but after the >>> second one. >>> >>> Thanks, >>> — Christian >>> _______________________________________________ >>> precis mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/precis > _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
