> ICANN has absolutely nothing to do with defining what is allowed in domain > names; that is specified by RFC 2181 (which says that type 00 labels are > strings of between 1 and 63 arbitrary *octets*), and is an IETF protocol > issue, not a policy issue.
I can agree that it is an IETF protocol issues to define domain names. That seem appropriate at the minimual. > In any case, we're talking about host names, not domain names. The syntax > of host names is also an IETF protocol issue, currently specified in RFC 1123. > One of the main tasks of this WG is to change that syntax. IDNA and IDNS, > for example, propose to change it to the syntax defined by nameprep (or > something close to nameprep). We have to ask ourselves is whether we have the knowledge and capable the answer questions which deals policy of what scripts is allowed or disallowed for *ALL* scripts we dealing with. When RFC1123 is defined, the scope of ALL script is limited to LDH. Now we dealing with a completely different beast. The group may have some folk who has experience in han scripts and probably able to give a good idea what the policy their registeries will adopt, are you ready to expand to other scripts, say arabic? cyrillic? etc? Let think over this seriously... > Both. It's an engineering issue because if mixed TC/SC is disallowed, it > becomes possible to do conversion of mixed names to unmixed names at a > layer just above DNS (e.g. John Klensin's layer 2). If mixed TC/SC is not > disallowed, then such conversion would risk "hiding" valid names (which the > owners of those names would obviously find unacceptable, at least in the > case where they don't also own the corresponding all-TC and all-SC names). It is best not to second-guess what JL2 will look like, not until we see it. But I certainly hope it wont be "look-like domain names but not domain names" as you kind of hinted above. > It's also a policy issue because the operators of some domains, in particular > ccTLDs for countries/areas that use *both* traditional and simplified Han > characters (.hk, .jp, .kp, .kr, .mo, .my, and .vn, possibly?), might not want > to prohibit mixed TC/SC. Whether they do or not is a policy decision for each > of those operators (e.g. JPNIC, KRNIC, etc., not ICANN or DNSO). The technical > approach described above, of TC/SC conversion at a layer just above DNS, still > works as long as the domains that don't prohibit mixed TC/SC are well-known. > It would be ugly to have to hard-code particular domains (in layer 2, not in > DNS), but it would work. My view is our job here is to defined a "policy-neutral" protocol. If X registry say they dont allowed this script or this combination of script, our protocol must be able to work for them. If Y registry say they want to allow, it must be able to work for them too. And there are more to domain names then what we engineers thinks...or can ever imaging what others thinks of domain names. Just listen to some folk from WIPO. > In any case, a precise definition of what a mixed TC/SC name is, is certainly > useful independently of where in the DNS namespace they are prohibited, and > is well within the scope of this WG. It would make sense to delegate to JET > and the authors of tsconv the task of specifying the sets of characters SCONLY > and TCONLY, since they've already done work closely related to this. Erm, please dont use the word "delegate"...but I think I know what you mean. Anyway, my question is: May I know who can deal with all the other scripts beyond han? -James Seng
