Re: [idn] Re: An idn protocol for consideration in making the requirements

[Paul Hoffman / IMC <phoffman@imc.org>]

At 04:43 PM 2/9/00 +0900, Martin J. Duerst wrote:
>The main problem I have with this draft is that as far as I understand,
>it introduces some restrictions on the current DNS, and/or a flag day.

If it does, it is an error. The third paragraph of section 2.1 says:

Note that a zone administrator can still choose to use "ph6" at the
beginning of a domain part even if that part does not contain
internationalized characters. Zone administrators SHOULD NOT create
domain part names that begin with "ph6" unless those names are post-
converted names. Creating domain part names that begin with "ph6" but
that are not post-converted names may cause display systems that
conform to this document to display the name parts in a possibly-
confusing fashion to users. However, creating such names will not cause
any DNS resolution problems; it will only cause display problems (and
possibly entry problems) for some users.

No restrictions, no flag days.

>The problem is the 'ph6' prefix. Whatever the prefix, if we follow
>this proposal, before starting any deployment whatsoever, we have
>to nail the prefix down.

Correct.

> From there on, domain names with that prefix
>cannot be registered anymore.

Not correct. They are explicitly allowed and explained in that paragraph.

<snip>

>Based on the considerations above, I therefore propose to
>add a requirement, as follows:
>
>Internationalized domain names MUST NOT restrict the possibility
>for registration of any domain name that could currently be
>legally registered as an ASCII-only domain name, and MUST NOT
>restrict any functionality of any such registration, such
>as display or input.

The third to last word ("display") appears to be narrowly targeted towards 
preventing any ASCII-based encoding, and therefore seems bogus. The rest of 
the sentence would not prevent cidnuc or similar proposal from being chosen.

>Apart from the above, some minor comments:
>
>- The compression algorithm should not use a big-endian UTF-16
>   octet stream as input, but a stream of 16-bit values.

Can you explain why? The compression scheme is tailored for UTF-16 and 
could easily become an "expansion scheme" for arbitrary 16-bit input.

>- Table 2 is missing.

Nope, just hard to read because it only has one line in it.

Table 2: Ranges of the first octet of input that use two-octet mode
0x34 through 0xdf

>- In Base32, it's unclear why we need the 8 for padding.

Correct. I've removed it.

>- In 2.4 12), check whether you have a valid window.

Not sure what you mean here (maybe we can do this offline).

>- In 2.5.1 5), say how to pad

Good catch.

>- 3.2: There is no need to mention U+FFFD for displaying undisplayable
>   characters. That should be done by the display engine without changing
>   character codes.

I'll clarify this. It was also caught by Graham Klyne.

>- 3.3: I don't think we will see editors that work with cidnuc directly.

We've seen all sorts of tools developed by a variety of people for domain 
admins. Maybe it's premature to say which ones won't be developed.

--Paul Hoffman, Director
--Internet Mail Consortium