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

Re: [idn] homograph attacks

could we for once call a cat a cat?

As noted in an earlier mail, we are neither speaking of language, script, countries: we are speaking of tables, and therefore of IDN tabtags. Whatever the reason a sovereign ccTLD Manager has to enter a code into a table, the code is in the table. So please stop arguing on the possible reasons, etc. A computer only considers the bits you put into a format, not your reasons.

There are three technical layers involved (internationalization, multilingualization and vernacularization) plus ccTLD's usual societal, economical and political considerations as in every other internet governance issue. If you want to advize them, just fine. But IETF is only concerned by the provision of the tools they needs. Today the IDNA solution is not addressing their needs, but it is here. No other solution will be provided by the IETF, however some refinements can be brought, at least through RFC for information to avoid a total fragmentation of the Internet between Lagacy and NGN. Among them:

1. a BCP commenting the RFC 3490 introduction to permit ITLDs (not the best and correct solution, but the only one permitted in this DNS current incoherence).

2. a better doctrine concerning the DNS virtual zones management to take into account tabtags in the NIC organization, since they were not permitted to be real zones.

3. a better relation between tables and lingual and vernacular aspects, with probably more general tabtags (ex. an extended European Latin table for all the characters European people understand as different).

The rest will be most probably addressed as usual by an open grassroots process, a "Language P2P like" process, part of the necessary technology evolution. Outside of the IETF virtual and of the W3C private worlds. The only result of all this will have been another 10 years wasted.

jfc


At 06:21 18/02/2005, Martin Duerst wrote: 
Hello James,

Many thanks for your private answer. I'd preferred to have this
discussion in some public forum, so please feel free to forward
this to one of the lists where I'm involved.

At 02:53 05/02/18, James Seng wrote:
>when we do idn, we talk about unicode and scripts. afterall, unicode is a script based encoding so it is silly to think in language.

Very good point.

>but when you deal with end-users, lay-person who wants their idn, they thinking of names. they want names in their own languages. script? what's the different.

They want the names in their own characters. Some, maybe quite
a lot, of users may think about it in terms of language, but
there is no need to stress the language aspect more than
necessary.

Also, if the average user gets that policy, but Verisign doesn't,
that's much more damaging than the other way round.


>that's the gap between the two. that's why in rfc3743, we talk about how to do chinese idn, japanese idn and korean idn and not han ideograph idn.

For rfc3743, that's fine, because that's dealing with language and
using language to address problems. Or actually, to be more precise,
it's not fine, because the main concern of rfc3743 isn't maybe
so much necessarily language as different ways to write the same
language. Simplified and traditional Chinese are not two different
languages, at least as I understand.

Another problem is that in different parts of the world, the issues
are diffenent. Switzerland is a good example, they didn't publish a
German table, a French table, and so on, for very good reasons.
It shouldn't look like they violate the ICANN policy, but at
the moment, it does look like they violate the policy because of
the way the policy is written. If that's by design, it's bad
design.

I'm not asking to remove all instances of 'language' from that
policy, but having 'language' 19 times and 'script' 0 times
in that document gives completely the wrong impression.

Regards,    Martin.

>james
>
>On 17-Feb-05, at PM 08:39, Martin Duerst wrote:
>
>> Hello James,
>>
>> If using 'language' only, and never mentioning 'script',
>> is by design, then would you mind pointing me to that
>> design, or explaining it to me?
>>
>> Regards, Martin.
>>
>>
>> At 19:05 05/02/17, James Seng wrote:
>> >the choice of words of using language (instead of script) in ICANN community is by design.
>> >
>> >james
>> >
>> >On 17-Feb-05, at PM 04:55, Martin Duerst wrote:
>> >
>> >> At 14:06 05/02/17, Erik van der Poel wrote:
>> >> >Michel Suignard wrote:
>> >> >> It is much more challenging for a worlwide TLD such as .com to
>> >> >> establish registration rules. Typically script is a much better
>> >> >> selector than language to establish those tables and associated
>> >> >> rules.
>> >> >
>> >> >"Typically"? You make it sound like you've "been there, done that". :-)
>> >> >
>> >> >Seriously, would you please elaborate on your ideas for .com? I would really like to know what you have in mind, specifically, to combat the homograph problem.
>> >>
>> >> Hello Eric,
>> >>
>> >> I can't answer fro Michel. But I just had a look at the ICANN guidelines,
>> >> and they use the word 'language' 19 times (hope I counted correctly),
>> >> and the word 'script' not a single time.
>> >>
>> >> However, there are at least as much 'script' aspects as there are
>> >> 'language' aspects in the current problem, and if you look at actual
>> >> implementation in ccTLD registries that have deployed IDNs, it's
>> >> also quite a bit about 'script'. As an example, .ch has published
>> >> a single table although they are very clearly working with three
>> >> or four languages.
>> >>
>> >> Too much emphasis on 'language' rather than 'script' also has lead
>> >> to strange claims such as that creating IDN TLDs is impossible
>> >> because we cannot create 6000 versions of .com. Again, looking
>> >> at this as a script problem is much more appropriate, after
>> >> all, neither "com" nor any ccTLD nor most of the gTLDs are
>> >> associated with any single language.
>> >>
>> >> Regards, Martin.
>> >>
>> >
>>
>