[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [APTLD iname 24] Re: [idn] Proposed suggestions from Asia Pacific Top LevelDomain meeting
- To: idn@ops.ietf.org
- Subject: Re: [APTLD iname 24] Re: [idn] Proposed suggestions from Asia Pacific Top LevelDomain meeting
- From: Paul Hoffman / IMC <phoffman@imc.org>
- Date: Fri, 03 Mar 2000 16:57:39 -0800
- Delivery-date: Fri, 03 Mar 2000 16:57:26 -0800
- Envelope-to: idn-data@psg.com
At 08:38 AM 3/4/00 +0800, James Seng wrote:
>The conclusion of the discussion is that IDN is very complicated in itself. We
>should not create more complication for IDN by dealing with non-alphanumeric
>ASCII too.
The latter sentence doesn't make sense to me. In all three encodings
proposed so far (UTF-8, UTF-5, cidnuc), it would take *extra steps* to
exclude non-alphanumeric ASCII. Thus you are adding, not reducing,
complication with this restriction.
This doesn't mean we necessarily want to allow non-alphanumeric ASCII; we
cannot say we are doing so to reduce complication. The same argument goes
for "punctuation" as was discussed last week. If we say "only alphabetic
characters, not punctuation", we add more complexity than saying "any
character".
Certainly, some characters should be disallowed. ISO 10646 includes many
formatting characters, for instance; those should not be allowed because a
user seeing a domain name would never know to enter them. Spacing
characters should be disallowed because they would bring in deep confusion
for someone viewing a domain name.
There is a meta-requirement that the IDN be as simple to implement as
possible. Every non-allowed character or character range fights against
that requirement, so we should have as few as possible.
--Paul Hoffman, Director
--Internet Mail Consortium