[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Internet Draft on registering IDNs
At 09:33 03/04/04 -0800, Paul Hoffman / IMC wrote:
At 11:36 AM -0500 4/4/03, Martin Duerst wrote:
On a lower level, I think your document contains two things:
1) the table format and the algorithm to use it (which is
basically a technical/protocol spec, and therefore doesn't
seem appropriate for BCP)
2) Some general recommendations for registries (think about
what languages you want to support, think about what
mappings/blockings to use, document your policies,
use the table format/algorithm where possible).
This kind of material seems to be adequate for a BCP.
So I guess my suggestion is that the draft be split in two,
which would then get rid of "framework" automatically.
I don't think the draft can be split into two because the whole idea of
allocations/blockings is tied quite tightly to the algorithm that creates
Blockings are clearly related to the tables. But there are recommendations
at a much higher level that aren't really related, such as the top
recommendation of "think things through before you start registering".
It might also be that we end up with two or more different tables/algorithms,
each suited for different kinds of (linguistic/orthographic/whatever)
situations. Each of these would then be described in its own document,
and there would be a BCP that would contain the general considerations.
But it is not clear to me from your current document whether you intend
this to be the only table/algorith, or whether you think there might
Having said that, and since I'm slogging through creating the -01 draft, I
will see what I can do to separate out the three parts (recommendations,
algorithm, format) better in the words in the document.
I think this is an excellent way to move forward.
For ASCII, as for any other script, there is the question of whether
some of these characters are part of the language or not.
Agree, but that is a concern for the person making the table.
However, there are also other questions specific to ASCII,
because all current domain names are in ASCII.
This document is only for IDNs. Non-IDN domain names are not relevant here.
I'm sorry, but I don't understand what you are saying.
As far as I understand, a zone can contain both ASCII-only and
IDN domain names. Also, in practice, there are a lot of cases
where there will be e.g. mappings from/to ASCII characters.
We already have seen many examples. The tables could easily
be used for a zone even if that zone only allowed ASCII,
or it could be specifically used to state that a zone contains
only ASCII. (ASCII always referring to what the user sees, because
obviously with IDNA, the actual zone data is pure ASCII anyway).
For example, an u-umlaut in German is often equated with 'ue'.
Now suppose that the German TLD wants to define tables to take
this into account, and apply these to the current ASCII registrations
in .de. Can they design the tables so that they don't have to take
away already registered domains from their owners? If they apply
the algorithm, in what sequence do they apply it to the registrations
they already have? Or, how do they design the tables so that there
is no difference in the result independent of what sequence they
apply it? These are all specific, real, questions. If there are
easy answers to them, it doesn't hurt to state them in the draft.
If these are unsolved questions, then we can state it so that we
can start trying to solve them.