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

Re: Categorizing the types of variants

----- Original Message -----
From: "Erin Chen" <erin@xxxxxxxxxxxx>
>   What a generic framework should be? It had better have a general
> definition to fit every language IDN
> registration. So I think to define the type of variants is required.

Agreed.  This is the basic premise I had when thinking about a framework for
IDN operations for registries.  We need to define the possible types of
variants (technically) so that a generic mechanism could be expressed and

> These types refered here is satisfied the type describe in IDN Admine
> Guideline for CJK
> (draft-jseng-idn-admin) .

Could anyone think of other types of Reserved Variants and Zone Variants
that I might have missed?

> If the types of variants is complete, every language could decide which
> type(s) is needed base
> on the language requirment.


> As to lead the IDN consistent and decrease confussion,  for a certain
> language in different TLDs
> is strongly recommended to adopt the same variant table and
> administration guideline.

While I agree in the general statement, especially your use of the word
"guideline" instead of "policy", I understand that the "policy" for chinese
domains will possibly be slightly different between CNNIC and TWNIC, however
the variant table will be consistent.  This is why in my proposal, I
intentionally separated the variant table and the policy assignment.  I
agree that the variant tables for a certain language SHOULD be consistent,
so SHOULD the guidelines for operations be, but the specific "policies" may

Do you think that is an accurate way to describe what the framework should


> Erin Chen
> Edmon Chung wrote:
> >
> >----- Original Message -----
> >From: "JFC (Jefsey) Morfin" <jefsey@xxxxxxxxxx>
> >
> >>At 05:06 14/04/03, James Seng wrote:
> >>
> >>>I believe in a more strip down generic framework on handling of IDNs
> >>>
> >its
> >
> >>>variants (e.g. registration, deletion, transfer, etc). But the exact
> >>>algorithm to generate the variants should be defined per language.
> >>>
> >>Total agreement. This is why language working groups and cross-zone
> >>Managers are necessary (every "cn" zones across all the TLDs).
> >>
> >
> >While I agree and believe that each language will have their special
> >on management, however I there could still be a more comprehensive
> >that identifies the types of variants that could be categorized.  For
> >example, for any language (for a given registry/region), there could be
> >basic tables:
> >
> >1. Codepoints Inclusion table: all included codepoints (including
> >linguistic symbols)
> >2. Equivalence Set table: codepoint=>{variant set}
> >
> >>From there, for a zone administrator, there are 4 possible types of
> >variants generated by a primary domain:
> >[1] Normal Reserved Variants: blocked from registration, can be activated
> >into zonefiles
> >[2] Restricted Reserved Variants: blocked from registration and cannot be
> >activated
> >[3] Automatic Zone Variants: automatically included in zonefiles
> >[4] Suggested Reserved Variants: not blocked for registration, but
> >
> >by registry
> >
> >And for zone variants, there are further 3 possible types of management:
> >(1) Normal Zone Variants: treated as unique domains and can have their
> >delegtation NS and child hosts
> >(2) Same NS: must have same delegation NS as primary domain
> >(3) Alias Only: set as an alias to the primary domain at the registry
> >
> >The actual determination (or algorithm if you will) to generate the
> >resulting variant set for a particular registry/region/language may be
> >different, but the "types" of variants can be better categorized
> >to better create a standard provisioning protocol)... and I think these
> >the possibilities... can anyone think of any other types?
> >
> >Edmon
> >