Re: [idn] Zone rules (was: wg milestones update)

[sun@pier.cnnic.net.cn (Sun Guonian)]

sorry, about -05 [30] maybe I don't express my point clear.

if the zone managers could define the equivalence rules respectively, users could
be confusing between different zones.

for chinese user, the TC-SC equivalence rule is just alike the case-folding rule.
I'd like to show an example followed using the case-folding rule.

under zone .COM, if manager defines upper case characters equal to lower case
characters. users could access IBM' domain with ibm.com, IBm.com, ... in any
case.

in another hand, under zone .NET, if manager defines upper case characters DON'T
equal to lower case characters. then ibm.net , IBm.net, iBM.net, ... will be
eight different domains, (without considering the TLD .net, such as .NET, .Net),
and, if the .NET-registry do the equivalence in their policy, they must put 8
records in their zone. if they don't, users will get the different experience
between .COM and .NET .

So I think the TC-SC equivalence rule SHOULD be consistent anywhere .

regards,
sun guonian

Eric Brunner-Williams in Portland Maine wrote:

> Jony,
>
> My first comment is that requirement 35 has been in the requirements document
> for several drafts. A one line expressions of preference is under motivating.
>
> My second comment is that any mechanism which allows non-degenerate scope,
> and for which a policy of specific consistency between two or more instances
> of scope, requires a  mechanism to obtain consistency. The notion that
>         "[e]ither we are consistent or we are inconsistent, but we cannot
>         have it once one way and once the other."
> presumes that consistency is a global, binary property. Is this consistency
> loose and converging or strict and atemporal?
>
> My third comment is in response to your example. Could you provide one with
> specific code-points and two distinct equivalence rules and restate the core
> issue?
>
> Incidently, since you happened to mention digits, Wabanakis in New England,
> Quebec, and the Canadian Maritimes define "8" as an equivalent to "ou", as
> the "w" character was not present in French when that writing system was
> adopted. There are UNICODE code points for the characters, but North American
> keyboards have the digit "8", which is used.
>
> So, without stepping outside of the LDH code points, the manager of a zone
> could create a rule that treats a 0x38 as 0x4f followed by 0x55, assuming
> the "8" appeared within an alpha string as the first, or as 0x6f followed
> by 0x75, for an in-fix character, and 0x38 if as a terminal, and, as 0x57
> or 0x77, using the same first-or-infix rule. This could "suit the purpose
> of the zone".
>
> I'd appreciate clarification if this is or isn't an instance of the practice
> (depricated in your note) referred in in requirement 35. I could be lacking
> a clue.
>
> Finally, what do you propose as rewording of requirement 35?
>
> Eric
>
> References:
> U+0222  LATIN CAPITAL LETTER OU
> U+0223  LATIN SMALL LETTER OU

--
*****************************************************
* China Internet Network Information Center (CNNIC) *
*   Sun Guonian                    No.4, S.4 Street *
*                                  Zhong Guan Cun   *
* Phone: 86-10-62553604            Haidian District *
* Email: sun@cnnic.net.cn          Beijing          *
* http://drop.cnnic.net.cn/~sun/   P.O.Box: 100080  *
*****************************************************
* 中国互联网络信息中心    孙国念                    *
*****************************************************

begin:vcard 
n:Sun;Guonian
tel;fax:+10 62559892
tel;work:+10 62619750-3016
x-mozilla-html:FALSE
org:CNNIC
adr:;;;Beijing;;100080;China
version:2.1
email;internet:sun@cnnic.net.cn
fn:Sun Guonian
end:vcard