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

["Martin J. Duerst" <duerst@w3.org>]

At 11:58 00/01/31 -0800, Paul Hoffman / IMC wrote:

> The new draft has the ungainly name of CIDNUC (Compatible Internationalized 
> Domain Names Using Compression); I chose this so that no one could accuse 
> me of trying to market it. :-) You can find the draft at 
> <http://www.ietf.org/internet-drafts/draft-hoffman-idn-cidnuc-00.txt>. I 
> hope this helps focus the requirements discussion.

I had a look at this draft.

Some pretty detailled work, probably rather too much than not enough.

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.

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. From there on, domain names with that prefix
cannot be registered anymore.

Now assume that somebody creates a new company/brand called ph6,
and wants to register it. It just won't work. And it won't work
even thought all years long, it would have worked. Who is going
to explain to the registrant that s/he just draw the short straw?
And why should we disallow some ASCII domain names? Our goal is
to allow all kinds of non-ASCII domain names, and it would be
strange to do that by restricting ASCII.

Of course you could say that whenever a 'real' domain name
starts with ph6, it is converted. But the converted name
also will start with ph6, and this will cause endless confusion.

You can of course argue that the probability is small. And you
could make it smaller by making the prefix longer. But it doesn't
change anything. And there is a potential that somebody wants
to register a name starting with the prefix just because a lot
of domain names will start with the prefix, and in an intermediate
period, a lot of these will actually be seen. For examle, what
about somebody trying to register the domain name ph6help, to
provide explanations and tools about all these names starting
with ph6?

While the chances for such registration conflicts are smaller
than the chances for non-working domain names in the initial
phase e.g. with an implementation based on UTF-8, I would
much rather tell somebody 'well, this Japanese domain name
is something new, and not all software supports it yet, so
please use this other one if it doesn't' rather than saying
'Well, ph6? Bad luck, we thought never ever somebody would
register such a thing.'. With international domain names,
we are providing something new, and we know that whatever
the proposal, they won't work from day one everywhere.
Explaining that is not too difficult. Taking away from
the current infrastructure is a completely different
thing.



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.


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.

- Table 2 is missing.

- In Base32, it's unclear why we need the 8 for padding. If the
  string is terminated externally (e.g. with a dot in a spelled-
  out domain name, or by the length byte for a transmitted label),
  on decoding one can just discard any non-complete octet.
  So either the 8 is there to end the string, or it's not needed
  at all. Currently, it's just added when padding occurs, which
  is confusing, at least to me.

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

- In 2.5.1 5), say how to pad

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

- 3.3: I don't think we will see editors that work with cidnuc directly.
  Having to convert back and forth for each edit of a zone file will
  be a major pain. For UTF-8 or similar, that would be much easier.
  UTF-8 can be edited today e.g. with Mule (+Mule-UCS) or MS Word,
  just to name two.

  I propose to add the following requirement:

  It SHOULD be possible to edit internationalized domain names in
  zone files or similar data with widely available text editors.


Regards,   Martin.


#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org