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

["James Seng/Personal" <jseng@pobox.org.sg>]

> 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