I wrote: > I have reviewed and understood the changes to Stringprep, and approve > of them...
I forgot about one minor technical issue that I starting discussing with the authors a while back, but that discussion fizzled out. One of the changes to Stringprep is the addition of two new prohibited characters, U+0340 and U+0341 (combining grave/acute tone marks). These characters are prohibited because they are deprecated, and for no other reason. The previous draft of Stringprep also prohibited deprecated characters, but the reason for their prohibition was something else (they "change display properties"), and the fact that they were deprecated was incidental. I see no real harm in prohibiting these two characters, and no real need to prohibit them either. But Nameprep (or any other profile) will not be able to follow this precedent of prohibiting deprecated characters in the future. If subsequent versions of Unicode deprecate more characters, Nameprep will not be able to prohibit them, because section 7.1 forbids later versions of a profile from prohibiting characters that were allowed in earlier versions of the profile. Why start down a path that you can't stay on? Perhaps deprecation alone should not be considered sufficient reason for including a character in the prohibition lists. As I said, this is a minor issue. I don't think it really matters whether these two characters are prohibited or not, I just think they might end up looking like anomalies in the future. There is a related issue that is purely editorial, not technical. If these two characters are prohibited, I don't see why the categories "change display properties" and "deprecated" should be merged into a single section, as they are in the current draft. They have nothing to do with each other, except that there happen to be some characters that could fall into either category. This is not the only instance of overlap. The "change display properties" category overlaps with the "control characters" category, and yet those two are not merged. Similarly, the "inappropriate for plain text" category overlaps with the "control characters" category, and those two are not merged. For consistency, I think the "deprecated" category, if it is retained, should get its own section. AMC
