"Adam M. Costello" <[EMAIL PROTECTED]> writes: > +-----------------------------------+ > | internationalized labels | > | | > | +---------------------------+ | > | | effectively ASCII labels | | > | | | | > | | +--------------+ | | > | | | ASCII labels | | | > | | | | | | > | | | +-----------+----+ | | > | | | | ACE labels | | | > | | | | | | | | > | | | | | | | | > | | | +-----------+----+ | | > | | +--------------+ | | > | +---------------------------+ | > +-----------------------------------+ > > > Unfortunately, the picture is starting to look daunting. The exact > subset relationships between every pair of the various sets is not so > important, as long as you know these two: > > * The ASCII labels are a subset of the internationalized labels. > * The ACE labels are a subset of the internationalized labels. > > The other things you need to know to make sense of the model, which are > not easily depicted, are: > > * For every internationalized label, there is an equivalent ASCII > label. ToASCII can compute it. You need ASCII labels for old or > IDN-unaware protocols. > > * For every internationalized label, there is an equivalent non-ACE > label. ToUnicode can compute it. You want non-ACE labels for > display to users.
Having a larger box called "Unicode strings" outside all of those boxes would be useful too. I think the picture, and your discussion of it, helps alot for the understanding of IDNA. A daunting picture conveys the information that IDNA isn't trivial, which is a good mind set to have when implementing it.
