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
