Re: [idn] Re: An idn protocol for consideration in making therequirements

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

At 09:57 00/02/09 -0800, Paul Hoffman / IMC wrote:
> 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.

So you mean that if a 'real' domain name starts with 'ph6', it
will be converted according to the rules to something (longer)
that also starts with 'ph6'? That would make sense, but could
be said clearer in the draft.

One main problem here is that it's very difficult to see whether
something starting with ph6 is pre- or postconverted. Much
more definitely than with =????=. Maybe that can be improved.
And the chance that you have something with  ph6 is much higher
than having to encode something with =????=. 


> > From there on, domain names with that prefix
> >cannot be registered anymore.
> 
> Not correct. They are explicitly allowed and explained in that paragraph.

Okay, they can be registered, but not used the same way any
other registration could unless all the infrastructure is deployed. 


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

Well, if somebody plans a marketing strategy and a web site with
the name ph6.com, and finds out a day after the launch of the
product that nobody is able to reach the site because the DNS
has it as ph6xxxxx.com, and the tools that could do the conversion
are not deployed yet, I wouldn't want to stand in for the damages.

Anyway, if 'display' is a problem for you, then 'input' is a problem,
too; it works both ways. And being able to input a domain name and
get where you want is what people are first and formost interested in.


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

Sorry, I should have written 'but a stream of UTF-16 16-bit values'.
It doesn't make sense to describe an algorithm in terms of bytes
if this just complicates things and implementation will use 16-bit
units anyway.


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

Then don't call it a table. And after a first check, I suggest
to start at 0x32, not 0x34. I don't know how that affects
the rest of the algorithm, but the 0x32 and 0x33 areas are not
really appearing in sequence, if they appear at all.

One problem with the compression scheme is of course that
Japanese hiragana crosses a block boundary.


> >- In 2.4 12), check whether you have a valid window.
> 
> Not sure what you mean here (maybe we can do this offline).

I don't have the draft, but I think I meant that if the window
doesn't conform to table 2, reject.


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

Well, yes, everything is of course possible. But the probabilities
clearly point against cidnuc, and for utf-8, in this case.


Regards,    Martin.


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