A couple of draft documents you should look at

[bramiozo]

I put the tables in excel;
http://www.idntools.com/download/idnaTable.xls

[261275]

What do you make of:

" As discussed elsewhere in this document, the IDNA2008 model removes
all of these mappings and interpretations, including the equivalence
of different forms of dots, from the protocol, leaving such mappings
to local processing. This should not be taken to imply that local
processing is optional or can be avoided entirely. Instead, unless
the program context is such that it is known that any IDNs that
appear will be either U-labels or A-labels, some local processing of
apparent domain name strings will be required, both to maintain
compatibility with IDNA2003 and to prevent user astonishment. Such
local processing, while not specified in this document or the
associated ones, will generally take one of two forms:

o Generic Preprocessing.
When the context in which the program or system that processes
domain names operates is global, a reasonable balance must be
found that is sensitive to the broad range of local needs and
assumptions while, at the same time, not sacrificing the needs of
one language, script, or user population to those of another.

For this case, the best practice will usually be to apply NFKC and
case-mapping (or, perhaps better yet, Stringprep itself), plus
dot-mapping where appropriate, to the domain name string prior to
applying IDNA. That practice will not only yield a reasonable
compromise of user experience with protocol requirements but will
be almost completely compatible with the various forms permitted
by IDNA2003.

o Highly Localized Preprocessing.
Unlike the case above, there will be some situations in which
software will be highly localized for a particular environment and
carefully adapted to the expectations of users in that
environment. The many discussions about using the Internet to
preserve and support local cultures suggest that these cases may
be more common in the future than they have been so far.

In these cases, we should avoid trying to tell implementers what
they should do, if only because they are quite likely (and for
good reason) to ignore us. We would assume that they would map
characters that the intuitions of their users would suggest be
mapped. One can imagine switches about whether some sorts of
mappings occur, warnings before applying them or, in a slightly
more extreme version of the approach taken in Internet Explorer
version 7 (IE7), utterly refuse to handle "strange" characters at
all if they appear in U-label form. None of those local decisions
are a threat to interoperability as long as (i) only U-labels and
A-labels are used in interchange with systems outside the local
environment, (ii) no character that would be valid in a U-label as
itself is mapped to something else, (iii) any local mappings are
applied as a preprocessing step (or, for conversions from U-labels
or A-labels to presentation forms, postprocessing), not as part of
IDNA processing proper, and (iv) appropriate consideration is
given to labels that might have entered the environment in
conformance to IDNA2003. [[anchor31: Placeholder: there have been
suggestions that this text be removed entirely. Comments (or
improved text) welcome.]]"

[261275]

In addition:

" IDNA procedures themselves should neither require such mapping nor
expect them when they are not natural to the localized environment." ?

[mulligan]

Originally Posted by bramiozo

All currency SIGNS are disallowed

These are still allowed since they are simply part of the CJK Ideograph characterset
元 20803 元 5143 [Yuan, in China]
円 20870 円 5186 [Yen]

Are they saying disallowed characters will be deleted?
I can't seem to see where / if it says this

So .. the £.com guy is screwed?

(Looks like my 元.net is safe .. whew! )

[bramiozo]

It's about the treatment of the dot (and similar marks) for domains in running texts., it's up to the local user how to map it, if at all. Not important for normal use if you just stick to UTF-8 and the dot as we know it '.' .

[bramiozo]

Originally Posted by mulligan

Are they saying disallowed characters will be deleted?
I can't seem to see where / if it says this

So .. the £.com guy is screwed?

(Looks like my 元.net is safe .. whew! )

Yes he is screwed, unfortunately it will not resolve to punycode after the implementation.

[IDNer]

Originally Posted by mulligan

Are they saying disallowed characters will be deleted?
I can't seem to see where / if it says this

So .. the £.com guy is screwed?

(Looks like my 元.net is safe .. whew! )

I don't believe that they will delete the disallowed characters -
they may discontinue registration after these 'disallowed symbol IDNs' droped.

There still have very few 1 character dot com (ASCii) alive on the internet, isn't it?

[bramiozo]

...come to think of it, the punycode remains registered and the conversion takes place at the browser level, so unless they block characters at the dns-level the names will still resolve.
I actually doubt whether they can block individual characters purely from the punycode when dealing with multiple characters, they will defacto need a punyconversion at the dns-level for doing that and I think it was agreed that doing that would demand to many resources.

I think you're right...sorry (£.com man, if you're reading this...)

[bramiozo]

..however, once the browsers are up to speed with this upcoming IETF it could still be blocked.

[Rubber Duck]

Originally Posted by bramiozo

...come to think of it, the punycode remains registered and the conversion takes place at the browser level, so unless they block characters at the dns-level the names will still resolve.
I actually doubt whether they can block individual characters purely from the punycode when dealing with multiple characters, they will defacto need a punyconversion at the dns-level for doing that and I think it was agreed that doing that would demand to many resources.

I think you're right...sorry (£.com man, if you're reading this...)

I think you will find that they will be screwed at the Nameprep level in the browser.

Nothing different will happen in the DNS.

ICANN can of course force registrars to delete disalllowed strings, but this probably won't be necessary as they won't resolve anyway.

No apology necessary!