[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comparison of hoffman-idn-reg and jseng-idn-admin
On Wed, 2 Apr 2003, Adam M. Costello wrote:
> Roozbeh Pournader <roozbeh@xxxxxxxxxx> wrote:
> > 1. Mandatory equivalences as opposed to secondary/variant
> > equivalences. This feature is necessary for defining equivalences
> > between European and Arabic-Indic digit shapes in Arabic labels, for
> > example.
> > This is some feature that *all* Arabic script zones *require*
> I'm not sure what you mean by "mandatory" and "require".
Well, neither am I. ;)
> Suppose I create the names <ArabicTextX>.nicemice.net and
> <ArabicTextY>.nicemice.net on the DNS server for nicemice.net (which I
> control), and suppose these two names are the same except that one uses
> ASCII digits and the other uses the corresponding Arabic-Indic digits,
> and suppose I associate different resource records with these names.
> Should there be a standard that prohibits me from doing this?
No. But the standard should allow you to do otherwise (define them to be
the same thing as a general policy in your zone) automatically.
Actually, I'm not worried a lot about these two referring to different
resources, or how they are handled in web servers, mail servers, etc. I'm
worried about these two being owned by different persons/entities.
> What would you think of this model: The Arabic-speaking community
> develops a best-practice recommendation regarding equivalences of
> names that should resolve to the same resource records, and TLDs can
> opt to support those equivalences, and can advertise their voluntary
> conformance in order to attract Arabic registrants.
That is very similiar to the model I'm thinking about. But TLDs, when
opting to support those, should be able to do it automatically. This
is best to be specified in IDN administration files.
> The whole point of having bundles is so that two registered labels
> cannot be variants of each other. Whichever one was registered first
> blocks the other from being registered.
I was talking about variants that are shared between two different labels
(that are not variants of each other), which *will* happen in zones, since
we can't define the equivalence tables to be 'equivalence classes' (in