Re: [APTLD iname 24] Re: [idn] Proposed suggestions from AsiaPacific Top LevelDomain meeting

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

Paul Hoffman / IMC wrote:
> 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.

Speaking as an implementor, you are right :) It would take *more* step to
ensure that non-alphanumeric ASCII is effectively ignored.

But considering the principle, policy and layer 8, it is definately easiler if
we dont do everything all at once.

I am sure some AT&T would be very happy if this is allowed of cos. 

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

Rather conflicting paragraphs dont you think?

If some characters are disallowed, then it does not matter how much (or
little) we have in the list. The algorithm is the same, only diff is how big
the list/table is.

As far as I concern, there are two way out:

1. Let everything thru and lets forget this whole thing, non-alphanumeric
   ASCII, punctation, symbols, psuedo-space whatever; or

2. If we are defining a list of rejects, then lets make sure lets do it 
   properly.

-James Seng