> 1. stringprep and nameprep should be rejoined to a > hostnameprep. They are only about host name preparation, > not any other name preparation. Similar preparations > may still take advantage of the hostnameprep document, > by declaring "deltas", small changes that may be needed > for other (Internet, DNS) names. That would likely > minimise the size of the "reuse" documents.
Kent, There is work going you in other WGs to use stringprep (that you might not be aware of). Is the high-order bit of this comment that you'd like nameprep be renamed hostnameprep? > 6. Hangul syllables (with conjoining characters, not > non-conjoining compatiblity characters) that represent > the same syllable must be mapped to the same representation. > Due to unfortunate historic reasons, this does no longer > happen automatically with NFKC (though for drafts for > NFKC it did). Mappings should be added so that "syllabically" > equivalent Hangul conjoning characters are mapped to a common > representation. Hangul compatibility letters should be > prohibited though. Correctly mapping those is more complicated > than can be expressed in the (current form of) (host)nameprep > mappings. Hangul compatibility letters should instead be > prohibited. (Mapping table for Jamos, and prohibition table for > Hangul compatibility characters, are available upon request.) > Future keyboard, e.g., input may generate only single letter > Jamos, rather than any "cluster letter" Jamos or precomposed > Hangul syllable characters. At the very least, hostnameprep > should not prevent such a development. This sounds like you are proposing to fix/change a decision made by the Unicode consortium. Why is that in scope? > 9. User interfaces that encounter mixed script hostname *parts* > should be recommended to "flag" them (ballon warning, color > differentiate, make blinking, bounce automatic registratations, ...). By "*parts*" do you mean labels or something else? Erik
