On Tue, Nov 10, 2009 at 10:39:17AM -0600, Nicolas Williams wrote: > - I've not made up my mind re: compatibility mappings. Evidently new > compatibility mappings can be added at any time (or so I'm told), > which complicates Unicode version agility, which argues against using > them. > > But use of K mappings removes some confusables, thus seems likely to > be worthwhile (though, to be sure, we'll never have zero > confusables). Hmmm, a thought occurs re: K mappings: - For _some_ protocols it may be appropriate to have the use of K mappings be configurable, for storage strings, except where clients must hash them (e.g., passwords), in which case the use/non-use of K mappings must be specified. I.e., it could be left up to an administrator whether SCRAM usernames can contain characters that would otherwise be mapped to other ones by K mappings. But for SCRAM passwords the use/non-use of K mappings must be specified and hard-coded. - More generally, I think requiring K mapping is a good idea only if confusable characters are an issue -- if a user must pick an object by name from a directory, then K mappings help. But requiring K mappings for strings that need not be picked but entered (e.g., passwords), is not helpful for the same reason, though it may be helpful for input method reasons (?). For protocols such as SCRAM, therefore, I lean against K mappings altogether. Nico --
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.