> ToASCII doesn't convert to ACE. It converts to ASCII (in particular, > if the string contains only ASCII characters, the result will not be ACE).
It depends how you define ACE right? :-) (I think that was not defined anywhere yet ever since the term was coined by Dan Occarson.) I could defined ASCII string as a subset of ACE, therefore, ASCII is also an ACE. e.g. An ACE without ACE tag is a valid ACE which decodes to ASCII range And subsequently, an ACE with an ACE tag that decodes to ASCII is invalid ACE. > > # ToASCII consists of the following steps: > > # > > # 1. If all code points in the sequence are in the ASCII range (0..7F) > > # then skip to step 3. > > > > Step 1 seem to be optimization, but not a required step. > > It is required. Why is it required? Step 4 repeat its again. Step 2 [NAMEPREP] only effect on ASCII input is case folding. > Is there any particular reason to reserve the possibility of this being > a suffix? The space of names with "xx--" prefixes has already been reserved, > in the sense of warning registrars that it may be used for IDN. Is there a reason that it *must* be in the form of prefix "xx--"? Why not suffix --xx or a "x-" prefix followed by "-x" suffix? What if we cant find an common "xx--" prefix according to aceid process? I feel that the selection of a final ACE tag is an IANA decision. Technically, prefix or suffix, it works as well. > I don't think this is a good way of handling zone files, but I do think > that the zone file format is entirely within the scope of an IDN proposal > (as a format for zone transfers and for interoperability between different > server implementations, not as the required representation of a zone). > This is how IDNA-04 handles it - by requiring ACE in zone files. It is a mistake to standardized zone file format in the first place. What if I am using a DNS server which do not have a zonefile but it is stored in database? -James Seng
