Re: [precis] Applying the rules three times to get a stable output string?

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 <william.w.fisher@gmail.com>:
> 
> 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
> <christian.schudt@gmx.de> 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
>> precis@ietf.org
>> https://www.ietf.org/mailman/listinfo/precis