Message-Id: <6.1.2.0.2.20050217134801.030d9870@mail.jefsey.com>
Date: Thu, 17 Feb 2005 16:21:30 +0100
To: idn@ops.ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: [idn] Tabtags and IDN tabtag Drafts and open mailing lists? (was RE:
  [idn] homograph attacks)
In-Reply-To: <FD16260E2EDF204E80A22FB904A425C30BD0A2D6@WIN-MSG-10.wingro
 up.windeploy.ntdev.microsoft.com>
References: <FD16260E2EDF204E80A22FB904A425C30BD0A2D6@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On 07:55 17/02/2005, Michel Suignard said:
> > From: Erik van der Poel [mailto:erik@vanderpoel.org]
> >
> > 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.
> >
>
>Like many of you this is also a learning phase for me, although I have 
>been involved around IDN and IRI issues for quite a while now, and 
>Unicode/10646 much longer. I still think that the best approach is a 
>collective effort probably through the Unicode Consortium with some input 
>from W3C and IETF experts. This was discussed at the last week Unicode 
>Technical Committee (UTC) meeting where many participants wanted to 
>contribute on this topic.
>
>My personal opinion is that gTLDs such as .com can for sure look for ideas 
>in current ccTLD policies but they have different customers and will 
>typically have to be more liberal. This is why I think the script based 
>approach is more practical.

Dear Michel,
you, Martin and Erik point out the main problem: a matter which is of the 
TLD (Registry) Manager and users' sovereign authority is discussed in 
closed various unrelated fora, like here: as John pointed it out,  IETF 
does not want to get involved.

1. what are we talking about?

Users wants consistent language (actually, a vernacular) support. Tables 
are only a part of the response. The word "language" (different 
understandings in different languages) is misleading and blocks innovative 
thinking. An IETF WG-Language would be a bad idea. 
ietf-languages@alvestrand.no is a private list.

We talk of IDN Tables Tags (tabtags) as a crossroad for language ISO 693, 
Unicode, TLD (there can be other descriptors).

2. where do we want tabtags?

IANA tables/files call for creative thinking over tabtags IDN could benefit 
from. I introduced near Applications IADs the proposition of a WG-Tags. 
Involved issues are IANA, format, scope, distribution, inheritances, 
updates, authorities, registry/registrars, functions, applications, etc. 
etc. I prepare a Draft to push for it. Anyone interested welcome. Its 
mailing list could show the interest of a WG, in the IETF or not.

3. how do we want to manage them?

IDN tabtags are parts of a TLD/PAD namespace policy. Experience in 
international naming shows that only a grassroots attitude can achieve 
something. We therefore need an IDN tabtags mailing list, with a clear 
charter targeting a TLD/PAD IDN BCP and related RFCs for encountered 
technical administration and application needs. It should be at the same 
time operational (TLD Managers, PAD Administrators), societal (users), 
technical (for applied and validated solutions) and political (to respect 
everyone sovereignty, innovation, privacy).

ICANN tried several time, in the proper direction. But by nature it is 
divisive. ASCII is part of ML, the DNS is part of the global naming. Not 
the other way around. . ICANN has no and does not claim any legitimacy 
outside of the RFC 920 scope (cf. ICP-3). So PADs, international keywords, 
numeric addresses and numbers, RFIDs, OID, handles, etc. are no part of its 
scope.

ICANN is welcome with a "get real, grassroots attitude", in a NRO's/ITU 
fashion: we do not know if ICANN will still be around in three years time, 
its strategic plans does not cover our issues while this naming started 28 
years ago and will certainly outlive all of us.

To make things moving my intent is to propose a framework Draft on the 
issue. Its discussion could show if there is a need.

jfc

PS.

1. PAD stands for Private Alias Directory. This is the personal vision of 
the namespace that users can build or buy from PAD Administrators and use 
on their own resolver. PADs are obviously fully ML.ML and multisystem.

2. the IDN Tables debate forgets issues like virtual zone management, table 
updates, that it does not scale: FQDN include lower level phishing car use 
(YAH00.secure.com). Babel names are good candidates (I did not check if 
that one works): "emergency@xn--bankofamerica.com" will retain people 
attention.