"Eric A. Hall" <[EMAIL PROTECTED]> wrote: > The i18n "domain name" specification needs to allow any valid UCS > character code,
You might be able to argue that it should allow all valid code points, but I don't see why it's *necessary*. Since IDNA will be the first specification to say anything about Unicode characters in domain names, later specifications will know exactly which code points they must live without. It's not as if IDNA's prohibitions will cause incompatibilites with existing IDN-related standards. New IDN-related standards will cause incompatibilities if they attempt to use code points prohibited by IDNA. > and must not be restricted to hostname characters. Domain names in IDNA are not restricted to host name characters. Only host names are. See step 3 of ToASCII. (If you're concerned about the ASCII control characters and space, which indeed are prohibited in the current Nameprep draft, then relax, we've seen the flaw, and those prohibitions are being removed.) > However, mailbox names are often stored in DNS labels, and under the > current arrangement, those mailbox names would be normalized and > lowercased as part of this process. This problem already exists to some extent with ASCII mailbox names. Sticking an ASCII mailbox name (which is allowed by RFC 822 to be case-sensitive) in a domain label (which is defined by RFC 1035 to be case-insensitive) is already a dubious proposition. > In essence, the rules which are currently provided impose restrictions > on any future mailbox name designs which the representative working > group may come up with in the future. The email working group has at least two options: They can either take IDNA (which was designed for domain labels) and apply it as-is to mailbox names (even though it wasn't designed for that) and live with the implications, or they can define their own way of representing internationalized mailbox names as ASCII strings (which might bear some resemblance to IDNA and might reuse components). Either way, they will interoperate with IDNA just as well (or as badly) as ASCII mailbox names interoperate with ASCII domain names today. > there should be a different stringprep profile for i18n "domain names" > than for "host names" There effectively is. Nameprep is the profile for domain names, and ToASCII adds a few more restrictions for host names. The case-folding of all domain names (not just host names) is consistent with the existing DNS, which uses case-insensitive matching for all domain names (not just host names). AMC
