[idn] Re: WG Review: Internationalized Domain Names in Applications (idna)

[JFC Morfin <[e-mail]>]

At 18:57 26/02/2008, The IESG wrote:
>A new IETF working group has been proposed in the Applications Area.  The
>IESG has not made any determination as yet.  The following draft charter
>was submitted, and is provided for informational purposes only.  Please
>send your comments to the IESG mailing list ([e-mail]) by March 4,
>2008.

Dear Friends,
A few years ago the same scenario developed when introducing the RFC 
3066bis failed Draft, but without an initial consensus check.

I explained several times that the choice for some Gov/Private/Civil 
Society interests was to get it corrected or aborted (then at the 
risk of the whole IETF). The decision was to get it corrected in 
consideration of its probable mandatory usage by IBM/MS customers. I 
accepted to carry the job after the WG-IDNA's poor results where it 
was that I became accustomed to the IETF. It was also due to 
architecturally erroneous (IMHO) RFC 3935.

This was pure mail-combat in what Economic Intelligence calls 
"knowledge war" and the DoD calls "shaping the world". This was a 
nice exchange for no one, but it did preserve interoperability with 
other referential systems, RFC 4646 was not adopted by the IESG 
before the very day it could be accepted, and its 
"internationalization" doctrine was further defeated at ISO TC46. As 
a result, I was the only one to be PR-acted and the IETF was not hurt 
(except by the IESG not respecting its RFC 4646 obligations, what RFC 
4646bis has now to take care of)..

This time, the DNS in the Multilingual Internet is certainly just as 
important as langtags are but is more visible. It also represents 
much more money and is led now by Google/Yahoo!. Harald Alvestrand, 
this time, has also prepared his plans better: he banned me first 
from his IDN proprietary list (the best way to obtain consensus). 
This has clarified things, relieving me from any moral obligation to 
cooperate with the IETF. It was fortunate since the target is no 
longer to maintain interoperability from inside the RFCs, because 
IDNA is not operable at all. However, this is something now for the 
future to show.

So, I suggest:

1. to follow Harald in transforming his proprietary mailing list into 
an IETF WG, with Martin Dürst and Mark Davis as co-chairs. With 
Harald, Patrick, and John, _IF_ IDNA has a chance, it will be well 
supported. I will not interfere with the process before proofing the 
deliverables. My projects will have several lurkers who may elect to 
give their opinion if a consensus is not met, or if there is an 
attempt to word any exclusive solution in violation of RFC 1958 
principle of constant change. So, the only remaining confusion I see 
would be to call this WG a WG-IDN when it is only allowed to be a 
WG-IDNA. This might create some confusion with the actions I engage 
for six months now, within the IGF framework (an emergent IDN Dynamic 
Coalition which may/may not chose to support IDNA).

2. to follow John Klensin's draft-klensin-idna-alternatives-00.txt. 
For those interested: I answered his call and proposed the 
[e-mail] mailing list to that end. I agree with John that 
if IDNA does not work prefectly, http://idnalt.org will be useful to 
document why it was the best solution. Anyone can subscribe to this 
list and contribute. I do not plan to post there except to raise some 
missing point if any. I can also transfer the list control to whoever 
would like it. This list should be one of the sources of the 
http://wikidna.org site.

As far as I am concerned, I said that I was working on my own 
Multilingual Internet solution. This solution will need to be tested 
without interfering with the ccNSO's Fast Crack project, so that it 
calls first for its own test-bed to be dealt with. Then, it calls for 
the solution to be documented, software to be developed, and tables 
to be stabilized. This involves issues that have been delayed by the 
RFC 4646 saga (one of missing concern I observe in the IETF is 
lingual consistency, may be because all this is handled at the 
application layer with some confusion between languages and 
scripts?). I certainly understand the urgency of an IETF move in 
order to match the ICANN Paris announcements. Even if I would love to 
present a working solution in Paris, my priority is to introduce a 
good general solution that works and that is able to work with the 
semantic addressing and multilingual distributed registry system 
projects I explained.

I note that all the IETF IDNA propositions so far have not addressed 
many issues including 3LD phishing, babel names (when the ADE is 
xn--a-registered-TM), and cannot even support French language off-the-shelves.

Good luck!
jfc