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

Re: [idn] opting out of SC/TC equivalence



Dar Adam,

"Adam M. Costello" ¼g¤J¡G

> ben <ben@cc-www.com> wrote:
>
> > The solution to delivering the 3 benefits explained above is a
> > Chinese domain name system that uses language script TLDs- a TLD of
> > <.traditional> for traditional CDNs (defined here as a CDN that uses
> > all traditional characters) and a TLD of <.simplified> for simplified
> > CDNs (defined here as a CDN that uses all simplified characters).

<.traditional> and <.simplified> maybe not the only one and not the
best one method of manage CDN. But it really could reduce the size
of the zone file. Because which is no more need to reserve the all possible

mixed TC/SC CDN for equivalent match .

If existing ccTLD or a new possible IDNccTLD could imply particular
scripe, then it do not necessary have the additional <.traditional> nor
<.simplified>

> This would limit people's choice of registration authority.

Certainly, we should consider carefully  not to limit people's choice when
they register CDN. But, how if the people live in PRC, Taiwan, Hongkong,
Macao and the Chinese some other where they do not use Chinese in the
way of mixed TC/SC ? In such case, that is not limit the piople, it should
be fit the people.

Maybe people may ask how if some of the people they do not familar
Chinese culture and custom might to use the CND in mixed TC/SC ?
Fine, nameprep it as case folding before send the request to resolver as
defined in IDNA. Or some intelligent match service could help things like
that.

> > The same techniques documented in this draft can also be applied
> > to the current gTLD and ccTLD registries by using SLDs.  In order
> > to be fair, everyone must agree to this system and make it a
> > standard.  In addition, every registry must change their current
> > registered second level domains to third level domains (ie.
> > <whatever>.<traditional>.TLD, <whatever>.<simplified>.TLD)

If the TLD could imply certain scripe, it does can provide the registration

of <certain scripe IDN>.TLD(imply certain scripe)

> I don't think there's any need to require that all domains containing
> Chinese characters follow this convention.  It could be left up
> to each registrant whether they want to include <traditional> or
> <simplified> in their domain name.  It needn't be at the second
> level either.  The convention could be that clients with the added
> Chinese support would be suspicious of simplified characters
> anywhere to the left of .<traditional>. (wherever it appears) and
> be suspicious of traditional characters anywhere to the left of
> >.<simplified>. (wherever it appears).  This would allow things
> like <FOO>.<traditional>.ac.uk.  It could be recommended (but
> probably not required) that registration authorities never allow
> <traditional> or <simplified> to be registered under any zone, but
> rather require registrants to register <something>.<traditional> or
> <something>.<simplified>.  It could be recommended (but probably not
> required) that registrars register such names in pairs.

In TWNIC testbed, when the registrants register an TCDN.tw we let them
to use the corresponding one SCDN.tw . We makes such names in pairs.

> One nice thing about your proposal is that it appears to be orthogonal
> to IDNA.  Clients without the added Chinese support can still access
> all domain names, they just won't provide the extra hints when mistyped
> names fail.
>
> AMC

After the fight of IDNA-NAMEPREP-ACE solution, hope the IDN WG would
face  forward to consider about mutilayer resolution,  a new Class. It
would not
be treat as orthogonal to IDNA, it could be the expansion.

Erin Chen