[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Internet Draft on registering IDNs




At 17:11 03/04/03 -0800, Paul Hoffman / IMC wrote:


At 6:35 PM -0500 4/2/03, Martin Duerst wrote:
I often see 'JET document' in this discussion. Is this
draft-jseng-idn-admin, or something else?

That is the one.

Thanks. Any explanation for the name 'JET'?



I have been thinking about 'Framework' quite a bit. Is this draft
a framework? It seems to be a definition of a table format with
some associated algorithm(s), and a recommendation to use this
table format/algorithms. And the recommendation isn't very clear:
Should all registries use this table format/algorithm? Or is it
just one of potentially many formats/algorithms, and registries
can choose?

Sorry, I don't see how your questions apply to the word "framework". Could you suggest alternative wording?

Okay, let me try again. On a very high level, I'm suspicious of documents with the word "framework" in the title, because this seems to be used more for buzword compatibility than anything else.

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 think the question of whether ASCII is allowed or not is a very
special one, which should be considered separately. There may
be cases where ASCII is already allowed; there is a good argument
for always allowing ASCII, in particular if the higher-level
domains are all ASCII; there is a good argument to not allow
ASCII if the higher-level domains are all non-ASCII.
These arguments are rather different from arguments about
allowing a few more or less characters.

I don't see why ASCII should be special. A registry decides which characters are allowed in the IDN labels, regardless of the scripts. Why does it seems special?

For ASCII, as for any other script, there is the question of whether some of these characters are part of the language or not. However, there are also other questions specific to ASCII, because all current domain names are in ASCII. These are not linguistic questions, but very much operational questions. One could imagine for example that we/somebody make/s a recommendation that every host reachable by an IDN is also reachable by an ASCII-only domain name. One could then imagine that in many cases, this is done most easily by allowing ASCII in the same zone. Also, there is the question of constructing tables for zones that already allow ASCII (and maybe already have ASCII entries).

I think all these questions should be discussed in a BCP, even
if it's only as "you may want to think about".


what about tables that don't have the same base character twice,
but may map to the same character? E.g.:

U+00E8|U+0065
U+00E9|U+0065

Or where a base character also appears as a variant

U+00E8|U+0065
U+0065

Or where a base character appears as part of a variant:

U+00FC|U+0075U+0065
U+0075
U+0065

I'm not sure what you mean by "what about" here.

My question was: Are these allowed or not?



All of what you list is just fine. There is nothing anywhere that prohibits those possibilities.

In another mail, you wrote:


>>>>
I will add text saying that they cannot overlap, and add steps in the process to check for that.
>>>>


So it seems that what you are saying is that by definition according
to the table, bundles can overlap, but you will add checks so that
once a label is taken by a certain bundle, it cannot be taken anymore
by another bundle, and therefore effectively they cannot overlap.


Are you proposing that I add examples with all these in them?

Yes, please add examples like these.



Regards, Martin.