We have a small piece of GNU libidn embedded in monotone, and it appears that the only thing we use it for is to put a handful of things in the database in IDN encoding: cert names, keypair ids, and database variable domains. [It also gives us a slightly nicer interface to iconv() but there is no reason we couldn't keep that one function, or reimplement it ourselves.] I am wondering if this is actually necessary -- why not just store them in UTF-8? As far as I can tell, nothing actually depends on them being punycoded: the revision cert names and db_var domains that have meaning to the program are all pure ASCII, and key IDs are treated as opaque (but comparable) strings.
There are, however, a couple of potential problems with a conversion. First, keypair ids and cert names do go over the wire; assuming that a database exists with one of these in it for which the IDNA transformation is not a no-op, that's a flag day. I *think* it's just a case of having to increment the epoch on any branch carrying certs whose names or signer ids changed; I don't think we would have to re-issue those certs. (Because, as far as I can tell, the signer id is not part of the data signed.) Second, part of what IDNA conversion does for us is the "nameprep" operation, which converts the string to NFKC plus places some other constraints. I have argued strenuously for Unicode normalization in other contexts, but in this case I don't really see it as necessary; if a hypothetical user tries to refer to their public key by two different but unified-under-NFKC strings, it just won't work; nothing terrible will happen. (I could be wrong.) Thoughts? I should emphasise that I'm not suggesting this for the release Richard wants to make Thursday. That would be entirely too risky. Also, as a data point, neither the Monotone nor the Pidgin databases contain any strings that would be changed by this proposal. zw _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
