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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 7 Dec 2001 07:13:34 -0500

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Friday, December 07, 2001 1:48 AM
> To: David Hopwood
> Cc: liana Ye; [email-masked]
> Subject: Re: [idn] Mixed TC/SC (was Re: Layer 2 and "idn identities")
>
>
> The only entity that can define what is and is not allowed in domain names
> (not host names) is ICANN and although they have doen it before, it
> doesn't happen often.
> 
> 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.

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?  I
haven't seen much on this thread to suggest that an engineering issue
exists.  If registrar or registry guidelines are being described as the way
to resolve the issue, Rick is probably right about this not being an IETF
issue, but a DNSO issue.

-Scott-

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Dec 2001 10:04:09 -0500

--On Friday, 07 December, 2001 07:13 -0500 "Hollenbeck, Scott"
<[email-masked]> wrote:

> Is the issue of mixed TC and SC an engineering issue, or a
> policy issue?  I haven't seen much on this thread to suggest
> that an engineering issue exists.  If registrar or registry
> guidelines are being described as the way to resolve the
> issue, Rick is probably right about this not being an IETF
> issue, but a DNSO issue.

Scott,

FWIW, I think there are significant engineering issues in TC/SC, 
"mixed" or otherwise.  Clearly some of the possible "solutions"
are policy-only.  E.g., to ban registration of "mixed", or of a
[label containing a] TC character when a corresponding SC
character exists, etc., would be policy decisions.   Other
approaches, including most mapping approaches and the boundaries
to their effectiveness, are engineering problems.

While the locus for decisions about recommendations is different
(see my earlier note about what either IETF or ICANN can
compel), some of these are inexorably intertwined and, IMO, we
either create confusion or abdicate responsibility if we try to
draw hard lines.  I believe that we have some responsibility to
define and explain to the policy people what the alternatives
actually are and what boundaries and constraints exist around
various solutions.   That is particularly important if we come
up with an engineering proposal that is workable only if
specific policy decisions are made.  E.g., if we had a solution
for TC/SC that would work iff registration of names containing a
mix of TC and SC characters were banned, I think we would be
obligated to be sure that ICANN and the various domain
administrators were aware of that restriction and of what would
happen if it were violated (that requirement would be even
stronger if we had to ban labels containing a mix of Chinese and
non-Han characters).

Indeed, my personal belief is that we would need to go further
than that.  IETF standards are based on, and ultimately credible
and accepted only if they obtain, community consensus.  That
"community" is usually defined as "within the IETF", but that is
because we believe that we have all of the interested parties
participating in the process (or deciding to not participate).
But, where a protocol requires, for its proper implementation
and interoperable deployment, that particular policy decisions
be made, I think our consensus process has to extend out enough
to the policy people to be sure they consider those restrictions
reasonable.   

We cannot, responsibly, I think, say "this protocol will work
acceptably only if pigs fly" and then standardize the protocol
any more than we think ICANN (or some other body) can,
responsibly, say "we are going to adopt this policy, which will
work well only if the laws of physics don't apply".

Of course, none of this addresses the question of whether any of
this is appropriately on the IDN WG agenda.  That is a separate
issue.

     john

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 07 Dec 2001 10:44:39 -0500

[Warning! Contributor humor follows!]

> work well only if the laws of physics don't apply".

and

>                 Unicode Transformation Format Seventeen
>                          draft-whistler-utf17-00.txt
> ...
> 
> Whistler & McGowan      Expires December 20, 2001               [Page 4]
> 
> Internet-Draft                   UTF-17                        June 2001
> 
> 
> 4. Benefits of UTF-17
> 
>    ...
> 
>    UTF-17 is compatible with ASCII, as long as you avoid digits in your
>    ASCII text.
> 
>    ...
> 
>    seamlessly with most Internet protocols.  For example, UTF-17 could
>    be used immediately to solve the IDN problem -- at least for domain
>    names no longer than 8 characters in length.
> 
>    ...

I came across this gem yesterday.

Eric

---

From: David Hopwood <[email-masked]>
Date: Fri, 07 Dec 2001 22:58:06 +0000

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

> 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:
> 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 <[email-masked]>

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

---

From: Rick H Wesson <[email-masked]>
Date: Fri, 7 Dec 2001 15:51:38 -0800 (PST)

David,

a silly question:

  how are companies listed in phonebooks in countries that use TC and/or
  SC?

-rick

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 8 Dec 2001 11:21:18 +0800

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

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

> 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 would be ugly to have to hard-code particular domains (in layer 2,
not in

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.

> 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

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 8 Dec 2001 11:27:10 +0800

hmm, just thought of something interesting :-)

if dns = phonebooks and
   registry = yellow page company
then
   ietf ~= printing company/printing machine

Q: should a printing company tells the yellow page company, "sorry, our
printers can only takes TC or SC but not mixed TC-SC for your company
names".

-James Seng