Message-Id: <6.1.2.0.2.20050225185646.030e9900@mail.jefsey.com>
Date: Sat, 26 Feb 2005 02:20:06 +0100
To: Erik van der Poel <erik@vanderpoel.org>, idn@ops.ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [idn] process
In-Reply-To: <421EA0C9.1010500@vanderpoel.org>
References: <421B8484.3070802@vanderpoel.org>
 <20050223072837.GA21463~@nicemice.net>
 <D872CCF059514053ECF8A198@scan.jck.com>
 <421D8411.9030006@vanderpoel.org>
 <p06210208be4390618c81@[192.168.0.101]>
 <421E0D0C.2000309@vanderpoel.org>
 <p06210202be43c3888991@[192.168.0.101]>
 <E07CE813AD23B2D95DA0C740@scan.jck.com>
 <421E30F2.1040408@vanderpoel.org>
 <0E7F74C71945B923C52211F3@scan.jck.com>
 <421EA0C9.1010500@vanderpoel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Erik,
I will try to respond that with caution. Based upon real world situation. 
Trying not to hurt anyone.

At 04:51 25/02/2005, Erik van der Poel wrote:
>1. Is this the right time to start working on Internet Drafts leading up 
>to new version(s) of the IDNA RFC(s)? If not, when?

The IDNA solution as well described by John Klensin, has IMHO low chances 
to commercially take off. I suppose it will progressively be replaced by 
different grassroots solutions in non-Latin countries at lease, as this has 
started. Due to this progressive evolution, we may suppose these solutions 
will still use punycode, so the experience acquired will remain of real 
interest. nameprep.org is OK.

I may be wrong but the solution will most probably be based on simple 
principles:
- respect of the DNS. Either with lingual TLD (extension of the root or PAD 
[private alias directory]) or with .lingual_sld.tld and conversion.
- language homogeneity for the whole URL
- reduced number of authorized characters as decided by the TLD/PAD Manager.

This will probably supported by local ISPs and by plug in (lingual names 
are probably to be of different usage, much more like DNs were used in the 
sole USA in 1984). The "plug in functions" will probably be extended and 
made part of the OS once stabilized. This will result from a grassroots 
effort, documented further on as RFCs for information. So there is no need 
for a WG no one wants to reopen, for ICANN which has no impact (2 mails on 
the ICANN IDNA mailing list in one year), etc. but for relations with TLDs, 
Govs, Users Reps, Cultural organizations.

>2. Am I stepping on someone's toes by creating nameprep.org? Feel free to 
>respond publicly or privately.

Certainly not. You may accumulate an experience which will be precious to 
everyone. But understand no one is really happy with the IDNA. The imposed 
terms by "Powers Above" were unworkable. There has been a lot of 
efforts.Everyone tried his best. There is still the IRI to fully 
understand. There is e-mail to support. There are the babel names. There 
are the PADs to come.

>3. If this is the right time to start work on drafts, who would like to 
>write some prose?

Frankly I think this time it should be carried the other way around. To 
understand the real world. Then to put a solution together. To test it. 
Then once it starts working to document for information.

But in the meanwhile we should do everything to keep a good image to IDNs. 
I do think that a multicolored URI support Draft could help in providing a 
way out from the current concern, and restoring credibility give a 
credibility to a new team.

>4. Do we need to revive the IDN WG?

Certainly not!

Then what else? There are different point of views. Mine is that the real 
need is to consider the whole matter of the multilingual internet. Once the 
framework has been clearly understood, ML.ML DNs will be far easier to 
understand and discuss. But the IETF/IAB is obviously not interested 
(yet?). As RFC 3869 shows it.

I had started writing a Draft on Multilingual Internet. My idea was to 
document how the existing Internet standard process can document the 
Multilingual Internet. The idea was to use RFC 3066 and the work of Paul 
Hoffman as a basis, adding a mutilingual considerations part in every RFC 
(like the security consideration, cf. RFC 3066), to extend the concepts in 
extending and structuring Paul Hoffman"s definitions lists, and to build an 
MLTF as there is a TFIPv6. To gather the concerned people and 
organizations. Its purpose would be to share into the standard process 
comment period, to help a culture to develop. The first thing was to 
document questions for an IAB guidance over the architectural aspects 
called by a MI.

The recent saga of the RFC 3066 bis shown there is still work ahead before 
this can be considered. Your initiative could help to prepare the ground.

>5. Any other process questions?

Why not to work on practical functions and on real tools testing? You have 
seemingly good developer skills, we could help?

jfc