Re: [idn] Mixed TC/SC (was Re: Layer 2 and "idn identities")

[David Hopwood <david.hopwood@zetnet.co.uk>]

-----BEGIN PGP SIGNED MESSAGE-----

Rick H Wesson wrote:
> On Fri, 7 Dec 2001, David Hopwood wrote:
> > liana Ye wrote:
> > > We are discussing how the registrars to "avoid registering mixed scripts
> > > 'names' ". Can you suggest any way of doing this, or any feasible
> > > guidelines?
> >
> > It's fairly trivial: define a formal syntax that registrars can check
> > against for domains that should exclude mixed names.
> >
> > The general form of that syntax would be:
> 
> The only entity that can define what is and is not allowed in domain names
> (not host names) is ICANN, and although they have done it before, it
> doesn't happen often.

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.

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).

> If you want to continue down this path I suggest you submit a proposal to
> the DNSO and that it is not a path we wish to take in this wg.

You speak for the whole WG, do you?

Another reason why an IDN standard will have to specify restrictions on the
hostname syntax, incidentally, is to disallow names for which the Unicode
bidirectional algorithm is not one-to-one. (I mention this only because I
don't want to have to go through exactly the same argument for that case.)

Scott Hollenbeck wrote:
> Rick,
> 
> I think I understand the point you're trying to make above, but can I check
> my understanding and expand on your point?
> 
> The responsibility and expertise to define domain and host name formats lies
> with the IETF.  The DNSO is responsible for determining the policy aspects
> of how those identifiers are used.  This implies that the IETF should strive
> to develop policy-neutral engineering solutions.
> 
> Is the issue of mixed TC and SC an engineering issue, or a policy issue?

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'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.

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.

- -- 
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPBFJWDkCAxeYt5gVAQHPVggAvRQVB2BBrjH+JWHGsvVtwGQhmtO4TMHd
LuiDep80i7OBx8NzB+6P4KNfpzrRWvSjjB/UQ+RQUhXMhUBMVUzbQp7mcmUnH3NH
tNVfI4rDfedkSA3Rf8epnV7jkBSkrE6w1ul6o0GVkQg5vRtiUpXF2Q5tRQX2UDKB
5slt+1uozb2rU5pAXKhNh5R3Cc6oGoVUN8qgCWzOHkKShf8eMDHtULpx6AvdLL7q
yef0iF/p2XfGKpZyN0YscjRDzvBPBOOrilYrOpzlgBzYdQudXZyMLYoJQF3F3BXu
PY+iJZ+aVC/We79aW0rToduYWmvxAbrqO8QKyCTCvQ+u9+G7+BvEwQ==
=R8VL
-----END PGP SIGNATURE-----