[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Re: [JET-member 469] Re: Fw: Re: new members invitation
James,
It wasn't my intention to misrepresent you. Please represent yourself.
Why is SC/TC "economic" and not "technical"?
What is "pure technical" and how does it relate to technical?
As L.M.Tseng has asked similar questions [1] being the most recent in this
same thread, an answer to him might be an answer to me.
In a seperate thread (RE: [idn] An ignorant question about TC<-> SC), in a
reply to Scott Hollenbeck <shollenbeck@verisign.com>, Kenny Huang wrote to
a similar point in [2]. This thread isn't cc'd to the jet-member@nic.ad.jp
list.
In that same thread, Deng Xiang wrote [4] that "the registration solution
isn't a solution", having previously made the a similar scaling observation,
here in a reply to Patrik Faltstrom, an IDNA co-author, who replied "multiple
registrations is a solution to the problem, and the recommended one by [the]
Unicode Consortium for the SC/TC issue".
Again, an anwer to one (L.M.Tseng, Kenny Huang, Deng, ...) may be an answer
to all. I appreciate that you may find it difficult to write to me.
Eric
[1] <001101c1604b$0a2b2d20$f006738c@ncu.edu.tw>
[2] <IHELIFNJKJLDFEMBCENDCEHGCIAA.huangk@alum.sinica.edu>
[3] Mon, 29 Oct 2001 12:20:06 +0100
[4] <006d01c16061$55b60150$4407e29f@deng>
P.S. My comment [5] on the utility of the UTC's participation in the technical
question (SC/TC in "the protocol" or in "the zonefile") read:
In this one note I'm troubled to see the UTC presume to know
better than the sources available to the authors of tsconv,
and to know better than the authors of some eventual STANDARD
and/or BCP track APPS or DNS IDs.
[5] <200109030113.VAA19923@nic-naa.net>