domob wrote:I'm also for IDN. If there are security concerns, the browser should handle them adequately (disallowing mixed script or even displaying the xn-- literally in case of paranoid users). I have no opinion on the draft apart from that, since I'm not a DNS or d/ expert.
@Daniel, you should look at the "import" part of the spec, as it differs from the spec that we partially implemented for NMControl (and it has an effect on the id/ namespace, specifically saying that "import" is no longer namespace-agnostic).
@Hugo, a few more comments:
I would like the "import" spec description to include some more non-normative examples, particularly of the subdomain selector.
Also, I would like to see an optional third argument to an import, which consists of an array of the fields being imported. E.g. ["ip", "ip6"] would restrict the import to just those two fields (after applying the "import" fields in the imported name) rather than also importing things like TLS fingerprints. A value of ["*"] would be the default, and would import everything.
Finally, we should consider whether we should (possibly as a future revision) limit the "tor" and "i2p" fields to only be permitted to point to Tor and I2P domains that have authorized the d/ name in question (e.g. by signing the d/ name with the .onion key). Both Fabio from GlobaLeaks and Jesse from OnioNS think that this is a highly useful property. I don't want to delay approval of this spec while we figure out the format for such a signature, but if it's something that we even might do in the future, there should be a note in the spec saying that users of "tor" and "i2p" should be aware that the spec may change in a way that will require changes to existing name configurations.