Re: Categorizing the types of variants

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

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

 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.


 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 and
> > >       
> >       
> 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 policy
> on management, however I there could still be a more comprehensive framework
> that identifies the types of variants that could be categorized.  For
> example, for any language (for a given registry/region), there could be two
> basic tables:
>
> 1. Codepoints Inclusion table: all included codepoints (including necessary
> linguistic symbols)
> 2. Equivalence Set table: codepoint=>{variant set}
>
> >From there, for a zone administrator, there are 4 possible types of reserved
> 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 suggested
>
>
> 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 own
> 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 (especially
> to better create a standard provisioning protocol)... and I think these are
> the possibilities... can anyone think of any other types?
>
> Edmon
>
>