[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: Paul Hoffman / IMC <phoffman@imc.org>, idn@ops.ietf.org
- Subject: Re: [APTLD iname 24] Re: [idn] Proposed suggestions from Asia Pacific Top LevelDomain meeting
- From: Harald Tveit Alvestrand <Harald@Alvestrand.no>
- Date: Sat, 04 Mar 2000 08:52:16 +0100
- Delivery-date: Fri, 03 Mar 2000 23:58:31 -0800
- Envelope-to: idn-data@psg.com
At 16:57 03.03.00 -0800, Paul Hoffman / IMC wrote:
>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 big question is "for what".
Adding @ to legal domain names used in email addresses would be VERY
disruptive. So would adding : to domain names used in URLs.
Depending on our decisions about normalization, 0xFF1A FULLWIDTH COLON
might be disruptive to URLs, because it is compatibility-mapped to straight
COLON.
>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.
Indeed. OTOH, every *allowed* character or range creates one more piece
that has to be analyzed for interference with the places where they are
used. Same argument, opposite direction.
Harald
--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no