2009/3/2 Erik van der Poel <erikv@google.com>

>> The current DNS does not allow ecole.fr and Ecole.fr to resolve to
>> different IP addresses. So you will have to encode these somehow. = This
>> means that you need a prefix. You cannot use xn-- because that is = for
>> Punycode. You cannot use Punycode because it does not encode ASCII= . It
>> just copies the ASCII characters directly into the output. For
>> example, fran=E7ais is encoded as franais-xxa. Note the directly c= opied
>> ASCII characters "franais". Appendix A of Punycode (RFC = 3492) allows
>> you to encode upper/lower case. So you might have xn--Franais-xxa.= fr,
>> but this would resolve to the same IP address as xn--franais-xxa.fr.
>> So you need something other than Punycode that does not copy ASCII=
>> characters directly to the output.
>

> No. If I include bigtitles as TEMPORARY (c= f. my other suggestion),
> "Fran=E7ais" would become "xx--ranais-bfcdq.fr" but "fran= =E7ais" would be
> "xx-franai= s-xxa.fr".

I see. Does this use an assigned Unicode code point for the big F?

yes.=A0

Good luck with your proposal. Do other French-speakers agree with this prop= osal?

This is not a proposal. This is a pro= blem we (French speakers) have to address; and it is a solution.=A0

The problem will be addressed anyway, within IDNA or no= t.=A0The target we (france@large) have is that it keeps a maximum compatibi= lity/interoperability with IDNA.=A0

jfc
--001636c5b1c71aff55046425c06c-- From jefsey@gmail.com Mon Mar 2 09:05:41 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCD528C228 for ; Mon, 2 Mar 2009 09:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZo-Kwahl6li for ; Mon, 2 Mar 2009 09:05:40 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 2AC143A6B23 for ; Mon, 2 Mar 2009 09:05:39 -0800 (PST) Received: by bwz26 with SMTP id 26so2015877bwz.37 for ; Mon, 02 Mar 2009 09:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=cYKi2UTHGy0F3z7IPa8p9wjGD7+LYIrsPGdrG6llzMo=; b=Nn/KYX/pA+34GRI7rylrgF2wuNuF62yAfgGlNI4M3YAfvJDY02CEZUxVJEGE9DJPpn LAcZhbzm4obvVe9RpoVnpkDwt4WOLBF0sVH6jr7cdy8AKGhfh5CTCBBDtQlixHCgLfYZ TD3dt+F5XNiYEfHUdYd7XrSHmCwDSaUUv4adI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=xX1jijx/UkN0+hfMlkBgSEE3EYhj74isOKS0HJAtVp+FY2AGvh7c8+dIa26Yb4cAGa fGDRDeKxLTyxxrjFsh5zeGRFiKsZz3y+WoXyJlw0RbMrMU/8W7XUhMfuB5EfvTBd0WX1 316Xrh1NiSh9SP4c3QlF7ybkjgTAZYeU8ZN/0= MIME-Version: 1.0 Sender: jefsey@gmail.com Received: by 10.223.126.10 with SMTP id a10mr4937271fas.17.1236013565410; Mon, 02 Mar 2009 09:06:05 -0800 (PST) In-Reply-To: <20090302162614.GA21099@nic.fr> References: <30b660a20902270727k4408b2ebpedd18397c4f89b3a@mail.gmail.com> <30b660a20902271459g3900814dg3751b14be45490e4@mail.gmail.com> <75CEA76DBBC28EBD6623F4B1@PST.JCK.COM> <20090301225546.uvl~@nicemice.net> <20090302162614.GA21099@nic.fr> Date: Mon, 2 Mar 2009 18:06:05 +0100 X-Google-Sender-Auth: 6bb1e28b88feed3f Message-ID: <1f9674ed0903020906k67aa609bu2e59fb69e49f9f47@mail.gmail.com> From: JFC Morfin To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=001636c5ab4080fcd4046425d560 Cc: listegenerale@franceatlarge.org, IDNA update work , iucg@ietf.org Subject: Re: [iucg] New version of strawman for IDNAv2 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:05:41 -0000 --001636c5ab4080fcd4046425d560 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit traceroute wants to be compatible with domain names (as entered in the DNS), not with usage names (as entered by the users). So, if traceroots supports IDNA, would it not be an application as any other one, which will strip off the IGNORED characters before its lookup? jfc 2009/3/2 Stephane Bortzmeyer > On Sun, Mar 01, 2009 at 10:59:33PM +0000, > Adam M. Costello wrote > a message of 26 lines which said: > > > How common is it for applications to display domain names obtained > > from DNS? I'm not aware that this ever happens except for > > logging/debugging purposes. > > traceroute ? Yes, it is a debugging tool but it is very common. > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --001636c5ab4080fcd4046425d560 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
traceroute wants to be compatible with domain names (as entered in the= DNS), not with usage names (as entered by the users). So, if traceroots su= pports IDNA, would it not be an application as any other one, which will st= rip off the IGNORED characters before its lookup?=A0

jfc

2009/3/2 Stephane Bor= tzmeyer <bortzmey= er@nic.fr>
On Sun, Mar 01, 2009 at 10:59:33PM +0000,
=A0Adam M. Costello <idna-update.amc+0+@nicemice.net.RemoveThisWord> = wrote

=A0a message of 26 lines which said:

> How common is it for applications to display domain names obtained
> from DNS? =A0I'm not aware that this ever happens except for
> logging/debugging purposes.

traceroute ? Yes, it is a debugging tool but it is very common.

_______________________________________________
Idna-update mailing list
Idna-update@alvestrand.no<= br> http://www.alvestrand.no/mailman/listinfo/idna-update

--001636c5ab4080fcd4046425d560-- From jefsey@gmail.com Tue Mar 3 16:26:25 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42F63A67B4 for ; Tue, 3 Mar 2009 16:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Wt3AkIvMymE for ; Tue, 3 Mar 2009 16:26:25 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id C4E513A6814 for ; Tue, 3 Mar 2009 16:26:24 -0800 (PST) Received: by bwz26 with SMTP id 26so2604094bwz.37 for ; Tue, 03 Mar 2009 16:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LYNOQxUsCkL+dLr15psJHskNYIDLrDNHwJfq1Jl9w50=; b=KEdGi5kaaE/K/LcP55A94s5u6tXx8xIuzUr4gC23PCOs7cqEkMr6Z6IlJviZCG0it4 PD1j2TX2Vgw0EDQB3DbbZloLzBJK7+6XYw+3qH3cd+jqHU01leBwfrp0BVXxHG4APn3S pzQuflpr3JJowmHh0AGRs9UoCpxZjOSEweNNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=ao2ql18aT46N3d3PbDGtINR8UxVF+kx07OJhUduli5GcScn2IE727qeL/kpVl4AbAe o9XxOVXeDL74t3OoTC+Dg4wN8Vissz9wM5PVzsJuzEQ5rVkUo9fNczWy6iJawwMyuRzn xEl12D1EzL6yZCq5P61yBDT0YI4n/UXiu90Po= MIME-Version: 1.0 Sender: jefsey@gmail.com Received: by 10.223.122.70 with SMTP id k6mr6386161far.26.1236126411526; Tue, 03 Mar 2009 16:26:51 -0800 (PST) Date: Wed, 4 Mar 2009 01:26:51 +0100 X-Google-Sender-Auth: 39623b4306487bbb Message-ID: <1f9674ed0903031626g1189730w2aed10feef6e741b@mail.gmail.com> From: JFC Morfin To: IDNA update work Content-Type: multipart/alternative; boundary=0016368e2087a811210464401b5b Cc: listegenerale@franceatlarge.org, iucg@ietf.org Subject: [iucg] French summary X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:26:26 -0000 --0016368e2087a811210464401b5b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit http://iucg.org/wiki/IDNA:_Internationalized_Domain_Names_in_Applications#What_about_accents_in_French_domain_names_-_Louis_Pouzin gives a position of Louis Pouzin. It is part of the following page: http://iucg.org/wiki/IDNA:_Internationalized_Domain_Names_in_Applications which includes the positions of other French language experts and authorities. It gives the highlights of the French language related issues and investigates a joint exploration based upon france@large's initial propositions I documented here. jfc --0016368e2087a811210464401b5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable http://= iucg.org/wiki/IDNA:_Internationalized_Domain_Names_in_Applications#What_abo= ut_accents_in_French_domain_names_-_Louis_Pouzin

gives a position of Louis Pouzin.=A0It is part of the f= ollowing page:=A0http://iucg.org/wiki/IDNA:_Internationalized_Domain_Names_in_Appl= ications=A0which includes the positions of other French language expert= s and authorities.

It=A0gives the highlights of the French language relate= d issues and investigates a joint exploration based upon france@large's= initial propositions I documented here.

jfc
--0016368e2087a811210464401b5b-- From jefsey@jefsey.com Sun Mar 8 07:40:54 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88A328C177 for ; Sun, 8 Mar 2009 07:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, SARE_HEXOCTDWORD=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaZ1ZyB4OF1X for ; Sun, 8 Mar 2009 07:40:54 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 184A628C15B for ; Sun, 8 Mar 2009 07:40:53 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:2774 helo=asus.jefsey.com) by montage2.altserver.com with esmtp (Exim 4.69) (envelope-from ) id 1LgKBu-00089Q-SK; Sun, 08 Mar 2009 07:41:23 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 08 Mar 2009 15:41:30 +0100 To: Lyman Chapin From: JFC Morfin In-Reply-To: <6178A216-2DE0-4B06-BF89-7C3DC93C67E3@acm.org> References: <20090306221146.GQ12711@shinkuro.com> <6.0.0.20.2.20090307145844.0919f4c0@localhost> <6.0.0.20.2.20090307213256.064434d0@localhost> <2696A439-92F6-4D87-B669-17D07DE6DA83@acm.org> <6348C9E739626B10A6E5224C@PST.JCK.COM> <6178A216-2DE0-4B06-BF89-7C3DC93C67E3@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Pass-two: yes X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20090308144053.184A628C15B@core3.amsl.com> Cc: Andrew Sullivan , iucg@ietf.org Subject: Re: [iucg] draft-liman-tld-names-00.txt and bidi X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 14:40:54 -0000 At 02:38 08/03/2009, Lyman Chapin wrote: >John, >If you type "http://320.170.98.32" into an old version of Internet >Explorer (if I remember correctly, Windows 95 vintage), you'll get to >the main IETF web page as surely as if you had typed "http:// >64.170.98.32" (or "http://www.ietf.org" for that matter). This is >just an artifact of the way in which software interfaces interpret >what users enter, not an observation about the DNS or the encoding of >data fields - Must the retrocompatibility be with the RFCs, with the old IE practices or with the diversity of the users' expectations. that is the question. My answer is "with the users expectations", what calls for the support of diversity. That is a true paradigmatic change. But I do not think it necessarilly calls for a basic technology change. i.e. no STD but BCP changes. jfc From jefsey@gmail.com Mon Mar 9 11:04:56 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9443A6CFF for ; Mon, 9 Mar 2009 11:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLMTc7rehWnC for ; Mon, 9 Mar 2009 11:04:55 -0700 (PDT) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 99F203A6CF2 for ; Mon, 9 Mar 2009 11:04:54 -0700 (PDT) Received: by bwz26 with SMTP id 26so1304822bwz.37 for ; Mon, 09 Mar 2009 11:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=4KUdgFl8FfsFiaAdKc0LiVn46ND5ED5qIodmIv6Ed6U=; b=KMX+oId+o0holWlZ9RRHqLh3P2I0xy7qBq0k8WXQQ/Vk7/LPtkHEtbFhX6pwpBEetB S5KVlUQ39qN/2Gd/pUKC3uumYkbWnn6ncF8DxHz0A5PePOppDKj9e3OYAbZq7AB1s5xL bPZ/pZln1/v0/eW21iBwGa+sFql1RhCGfkp4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=PqtVvt5V89UgFgg7h/YP1AtWyndOFRgDMYq2ZUTlypVHMtJuL8qAN86wv9fAc6rUlB UNcSS7Sgy32GUUkQc/dSX1sdrIH++8dgvLJ3qPp7pgP24LAkOyEdcHK7mDDEFsAwBsVg 3lRBIAA0kLG1+fB+Qx+ecAUHWV7bUrYVM44Ts= MIME-Version: 1.0 Sender: jefsey@gmail.com Received: by 10.223.126.1 with SMTP id a1mr4724127fas.52.1236621927818; Mon, 09 Mar 2009 11:05:27 -0700 (PDT) In-Reply-To: <49B5515E.1090305@abenaki.wabanaki.net> References: <20090306221146.GQ12711@shinkuro.com> <6.0.0.20.2.20090307145844.0919f4c0@localhost> <6.0.0.20.2.20090307213256.064434d0@localhost> <2696A439-92F6-4D87-B669-17D07DE6DA83@acm.org> <6348C9E739626B10A6E5224C@PST.JCK.COM> <49B5515E.1090305@abenaki.wabanaki.net> Date: Mon, 9 Mar 2009 19:05:27 +0100 X-Google-Sender-Auth: 3712d113922ff182 Message-ID: <1f9674ed0903091105l18d6d564x30f212f52fe10719@mail.gmail.com> From: JFC Morfin To: Eric Brunner-Williams Content-Type: multipart/alternative; boundary=001636c5a537baa4730464b37a35 Cc: Lyman Chapin , Andrew Sullivan , idna-update@alvestrand.no, iucg@ietf.org, John C Klensin , Martin Duerst , Vint Cerf Subject: Re: [iucg] numeric (ascii) labels (was: Re: draft-liman-tld-names-00.txt and bidi) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:04:56 -0000 --001636c5a537baa4730464b37a35 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you for this clear and refreshing KISS wording.This certainly reflects the common lead user understanding. jfc 2009/3/9 Eric Brunner-Williams > My personal view is that broken code that isn't a defacto specification > of the DNS, or broken specifications of things other than the DNS, need > to go find their authors and get fixed, and not become dejure nuances of > the "corrected" specifications of the DNS. In particular, it is > reasonable for any zone admin, the IANA included, to make a > registry-local rule reflecting momentary annoyance at the existence of > well-known bugs, but that no such "rule" should be internalized to the > DNS specs, with a vastly longer shelf-life than the random DNS > (mis)using application. > > Yes, there is a bug (actually, a shared bug with multiple, possibly > independent interoperable implementations of obvious brokenness), but > 666 is no different from AAA, and a five label sequence composed of > numeric (or octal or hex) character values is safe as houses (if ugly), > and it is possible to constrain allocation of label sequences so that > label sequences terminating in numeric (or octal or hex) character > values, and having fewer than five labels, are also not incorrectly > interpreted by this bug-set as dotted quads. > Eric --001636c5a537baa4730464b37a35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you for this clear and refreshing KISS wording.
This certainly re= flects the common lead user understanding.=A0
jfc

2009/3/9 Eric Brunner-Williams <ebw@abenaki.wabanaki.net>

My personal view is that broken code that i= sn't a defacto specification
of the DNS, or broken specifications of things other than the DNS, need
to go find their authors and get fixed, and not become dejure nuances of the "corrected" specifications of the DNS. In particular, it is reasonable for any zone admin, the IANA included, to make a
registry-local rule reflecting momentary annoyance at the existence of
well-known bugs, but that no such "rule" should be internalized t= o the
DNS specs, with a vastly longer shelf-life than the random DNS
(mis)using application.

Yes, there is a bug (actually, a shared bug with multiple, possibly
independent interoperable implementations of obvious brokenness), but
666 is no different from AAA, and a five label sequence composed of
numeric (or octal or hex) character values is safe as houses (if ugly),
and it is possible to constrain allocation of label sequences so that
label sequences terminating in numeric (or octal or hex) character
values, and having fewer than five labels, are also not incorrectly
interpreted by this bug-set as dotted quads.
Eric
--001636c5a537baa4730464b37a35-- From jefsey@jefsey.com Tue Mar 10 08:19:26 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00773A6A14 for ; Tue, 10 Mar 2009 08:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.894, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WRXls7oUA0i for ; Tue, 10 Mar 2009 08:19:25 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id DEED73A69C3 for ; Tue, 10 Mar 2009 08:19:25 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:1614 helo=asus.jefsey.com) by montage2.altserver.com with esmtp (Exim 4.69) (envelope-from ) id 1Lh3kJ-0003BW-1v; Tue, 10 Mar 2009 08:19:55 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Mar 2009 16:20:06 +0100 To: idna-update@alvestrand.no From: JFC Morfin In-Reply-To: <62319647-808E-4709-B082-42BE1BB40D70@evertype.com> References: <200903092209.n29M9PY01903@birdie.sybase.com> <72CFBCB428174A9FB6ED2632FCF7E06B@SUIGNARD.lan> <196961FC49A14A498CAAC9C32F1E5A35046CF9@PE2800.SUIGNARD.lan> <62319647-808E-4709-B082-42BE1BB40D70@evertype.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Pass-two: yes X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20090310151925.DEED73A69C3@core3.amsl.com> Cc: iucg@ietf.org Subject: Re: [iucg] Mapping and Variants X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 15:19:26 -0000 At 09:06 10/03/2009, Michael Everson wrote: >You know, last night I sent an IM to Cary: > >"I don't know why I remain on the IDNA list. Any time I say anything >it gets ignored." > >Cary responded that he felt that both statements were true for >everyone on the list. > >And these decisions will help run the internet.... > >Dejectedly, >Michael +1 However, I feel the problem is with the matter itself (multilinguistics) we actually discover as part of the discipline of optimising the support of (linguistic) diversity. This compex systemic calls for reticular thinking. Poking into one direction and then another (variants, budling, numerics, eszett, capitals/upper-cases, ascii to greek, etc.) cannot lead anywere, and moreover not to a consensus. There are thefore one way of thinking (metaductive, cf. infra) and two ways to consistently approach the issue: - from the inside : we first need to make a "meta cartography" of the problem we face. The first difficuty are the RFC and the language description systems : because they are not designed to permit an easy modelling. Then we need to model the domain names themselves and languages: what are they, what do we want them to be, or support. - from the ouside : we need to consider where the domain name system belongs : what is its exotem. Then to consider how such an exotem is built, encapsualtes, and constrains our "meta map". And to make sure the DNS keep being coherent, either a part it, or as the core of it. "metaductive", means this three steps thinking: building the metamap, studying and playing with its model, resolving down practical coherent decisions. This is very different from the inductive and deductive debate we have (what can I do with what I have, how do I support this, and then that, ...). From the inside is by nature subjective (to the IETF in this case), so it may be easier to peope having a good command of RFCs (the first target of IDNA is to stay coherent with former RFCs). From the outside is by nature more objective as far as the concerned system is considered, this is my own way of thinking (I am not borne with the Internet). But both ways need to meet, so to clearly define their road-maps and mutually understand/cooperate with vision/information. jfc From jefsey@jefsey.com Fri Mar 20 16:38:24 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCADE28C1C3 for ; Fri, 20 Mar 2009 16:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQnrdXaVY9hm for ; Fri, 20 Mar 2009 16:38:24 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 4462828C269 for ; Fri, 20 Mar 2009 16:38:24 -0700 (PDT) Received: from 194.166.193-77.rev.gaoland.net ([77.193.166.194]:4034 helo=asus.jefsey.com) by montage2.altserver.com with esmtp (Exim 4.69) (envelope-from ) id 1LkoIt-0004wf-Rv; Fri, 20 Mar 2009 16:39:08 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Mar 2009 23:35:00 +0100 To: Vint Cerf From: JFC Morfin In-Reply-To: <7260CD59-9418-4DE5-88D6-E93AC8CDAC6E@google.com> References: <7B1FC886-419D-4A4A-ACF6-8B4640D3E9B5@google.com> <9C995EB1-4588-49EA-B1EA-F698B736B5DB@google.com> <7260CD59-9418-4DE5-88D6-E93AC8CDAC6E@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Pass-two: yes X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20090320233824.4462828C269@core3.amsl.com> Cc: idna-update@alvestrand.no, iucg@ietf.org, adminance@corefra.org Subject: Re: [iucg] DRAFT Status of Work on IDNA2008 + IDNAv2 X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 23:38:24 -0000 At 20:11 20/03/2009, Vint Cerf wrote: >yes - the discussion on Monday would be informed by whatever >comments are sent between now and then. The only comment at this stage is that no one can engage into any BOF like process as long as one does not know if we are or not to build on top of IDNA2008. This question is now pending for 8 years. It is necessary everyone knows it after the San Francisco meeting. jfc From jefsey@jefsey.com Tue Mar 24 03:53:21 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86AA53A6A83 for ; Tue, 24 Mar 2009 03:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.024 X-Spam-Level: X-Spam-Status: No, score=-4.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n5Neb4nnXKc for ; Tue, 24 Mar 2009 03:53:20 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id EF50F3A685F for ; Tue, 24 Mar 2009 03:53:19 -0700 (PDT) Received: from 194.166.193-77.rev.gaoland.net ([77.193.166.194]:1469 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtp (Exim 4.69) (envelope-from ) id 1Lm4Gh-0003Ph-1H; Tue, 24 Mar 2009 03:54:03 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Mar 2009 11:54:02 +0100 To: idna-update@alvestrand.no From: JFC Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Pass-two: yes X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20090324105319.EF50F3A685F@core3.amsl.com> Cc: adminance@corefra.org, listegenerale@franceatlarge.org, iucg@ietf.org, Arabic Scripts IDNA Subject: [iucg] RFC 3935 responsibility X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 10:53:21 -0000 The different mails below and my TATWEEL DISALLOW NO position seem to show there is some confusion about the matter being really discussed. The matter is not the TATWEEL codepoint. Considering the impact on IRI, Semantic Addressing, Semiotics, WTO and WIPO rules, etc.. etc... the matter is: who is to assume the RFC 3935 responsibility concerning the digital alphabet being authorized to the world: - IETF? - Unicode? - IANA? - ISO? - WIPO? WTO? - ASWIG? or other enhenced cooperation on a per language basis (we call "Ledgers" in the ML-DNS exploration) - national standardisation bodies? - Governments? - UNESCO or MAAYA or accademics? - Registries? - users? I have no problem this being decided by IETF, however it must be accepted by all the others. This is why: - I think advisable this results from a formal IETF consensus. I am afraid that today there is no text in the Draft to claim this responsibility that a consensus may accept to support. For years I have proposed that at least that responsibility be assumed by Unicode which has experts and ties with other SSDOs in this domain. This is has always been opposed. - I do not think, I may be wrong, this belongs to the current WG-IDNABIS Charter. Otherwise, why was the ASWIG created? - I do not feel such a responsibility would be accepted by the IETF and the accademic, regalian, civil, private societies without at least an IETF entity to review the DISALLOW claims, such as the ccTAG Reviewer. This being said, I have no objection (but I feel some may have objections within and outside the IETF) to a scheme where: - every language should have an ASWIG or Francophonie equivalent, showing close ties with every concerned community and trade. - the IETF documents a procedure where-by these entitities may reflect their decisions in IDNA IANA tables Otherwise, I am afraid this IDNA proposition loses international credibility and will be opposed in WG-LC, IETF-LC, international implementation with an other decade delay. Please, let stay within our charter. And be sure that at the end of the day what will prevail is what the users will want. We only can either delay and confuse it or speed it up after so many years. jfc At 02:00 24/03/2009, Andrew Sullivan wrote: >On Mon, Mar 23, 2009 at 05:34:03PM -0700, Mark Davis wrote: > > Look back at the email archives; this character is used in many languages, > > in many surnames. > >I was afraid you'd say that. Surely that some things are hard to >encode if we don't include someone's favourite code point is not what >we want to do, right? That puts us back into the >character-by-character business. The counter-arguments are also in >the archives, I think. At 02:09 24/03/2009, Patrik F�ltstr�m wrote: >Then I must ask myself, why does it have the properties in Unicode it >has? > >I.e. I really do not like having the IETF "overriding" various >definitions Unicode Consortium has decided upon, because there must be >a reason why the codepoint has the classification it has. If it is >"used as a letter in a name", then it should be one of the letter >variants? Or? > >I am just trying to understand, and will of course given consensus in >this wg change (potentially) exceptions accordingly. > >Where does this slippery slope end? At 05:29 24/03/2009, Sarmad Hussain wrote: > > Based on the on-line exchanges, it appears to me that the general > > consensus is to ban TATWEEL by exception (ie. make it DISALLOWED). > > > > Please respond with: > > > > YES (ie make it DISALLOWED) > >YES, should be DISALLOWED at protocol. At 06:47 24/03/2009, Raed Al-Fayez wrote: >Dear All, > >As a native Arabic speaker I strongly vote for > > YES (ie make it DISALLOWED) > >for the following reasons: > >1- It is so similar to the hyphen (see file: TATWEEL-1.jpg): > �� vs �-� > >2- It will add more help domain fishing and user confusion (see >file: TATWEEL-2.jpg): > �� vs �� vs �� > >3- It is not a letter or a digit (conflict with LDH concept) > http://en.wikipedia.org/wiki/Tatweel > >4- do we really want to see these type of labels as domains (see >file: TATWEEL-4.jpg): > �� vs � vs �� vs �-�-�-�-� (the > last one is composed of TATWEEL + Hyphen) > >5- If someone feels that all registries are capable of fixing >problems in all the languages than why not enabling all code points >and simplify the IDNA protocol!!!!!! > I believe that we need to simplify the registry operations > by keeping them focused on the core functions and not adding extra > work/load on the script problems/issues > >Thanks .. From jefsey@gmail.com Wed Mar 25 17:18:16 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97FA28C171 for ; Wed, 25 Mar 2009 17:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJj01nRDu2fw for ; Wed, 25 Mar 2009 17:18:16 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 7F47628C18C for ; Wed, 25 Mar 2009 17:18:15 -0700 (PDT) Received: by bwz17 with SMTP id 17so306921bwz.37 for ; Wed, 25 Mar 2009 17:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=6UA6Ne0BV8/LsUhdqlqQfxT1eOxFcW3tyaC/FkniHWU=; b=cYYKY08/sRi3Cqtu1JR+UkTj9681BxRthGXLZ3JcydDYOB1ZR7bKNpMYQzOtY2M+/I UKTd2N1UugICvm/59TLPwYx0kXUNaUoav5O4bHYto29t5IT5zDi454i+OzDenxKJs2Ur KuNn93b5D+BOAyYkRaQxbJS3OHcRusROBAKDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=DqvSZyPaaAaTXgQFfKEdzFWOA/fwcHihZ8AhUHey0g1LBPMDXINHu+3X73hhGTRql1 5jZEz/Ln4/PrfdgALnqdjuoMFcCm7gW81VteRefbxg5RwhfqvBsV9MBy8JXw9jLBK+wr OpAOEqVPmNs+dzHDXHTbN3lOLybTknX3zuGVo= MIME-Version: 1.0 Sender: jefsey@gmail.com Received: by 10.223.110.144 with SMTP id n16mr155410fap.63.1238026747379; Wed, 25 Mar 2009 17:19:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2009 01:19:07 +0100 X-Google-Sender-Auth: 205c343cf57407e6 Message-ID: <1f9674ed0903251719v2bbb1583rcb280eb4ca98e97a@mail.gmail.com> From: JFC Morfin To: Lisa Dusseault , Vint Cerf Content-Type: multipart/alternative; boundary=001636c5a45f8001d30465fa90f8 Cc: listegenerale@franceatlarge.org, iucg@ietf.org Subject: Re: [iucg] Touchstones for "Mapping" X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:18:16 -0000 --001636c5a45f8001d30465fa90f8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Lisa and Vint, It is now considered by some that making TATWEEL DISALLOWED at protocol level is used as a case to show further on that the WG consensus thinks that IETF has authority over what internet users may or may not be allowed as a script for their own language, IRI and IPR over the internet. However, - such an authority MUST be accompanied by responsibility, according to RFC 3935, as I already documented it. - I do not find the capacity to discuss (1) the evaluation of the capacity to assume such an authority and (2) the organisation of this responsibilty, in the WG Charter. IMHO this should be clarified ASAP. Best. jfc --001636c5a45f8001d30465fa90f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Lisa and Vint,
It is now co= nsidered by some that making TATWEEL DISALLOWED at protocol level is used a= s a case to show further on that the WG consensus thinks that IETF has auth= ority over what internet users may or may not be allowed as a script for th= eir own language, IRI and IPR over the internet.=A0

However,=A0
- such an authority MUST be accom= panied by responsibility, according to RFC 3935, as I already documented it= .
-=A0I do not find the capacity to discuss (1) the evaluatio= n of the capacity to assume such an authority and (2) the organisation of t= his responsibilty, in the WG Charter. =A0

IMHO this should be clarified ASAP.
Best.
jfc

--001636c5a45f8001d30465fa90f8-- From jefsey@jefsey.com Wed Mar 25 21:23:12 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FFE3A6DCB for ; Wed, 25 Mar 2009 21:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=-1.362, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG298tG+GqL6 for ; Wed, 25 Mar 2009 21:23:11 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 29D023A6B9F for ; Wed, 25 Mar 2009 21:22:44 -0700 (PDT) Received: from 194.166.193-77.rev.gaoland.net ([77.193.166.194]:2429 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtp (Exim 4.69) (envelope-from ) id 1Lmh7p-00028Z-FT; Wed, 25 Mar 2009 21:23:30 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Mar 2009 04:50:41 +0100 To: "Vint Cerf" ,, "Vint Cerf" From: JFC Morfin In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_93723718==.ALT" X-Pass-two: yes X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20090326042245.29D023A6B9F@core3.amsl.com> Cc: listegenerale@franceatlarge.org, iucg@ietf.org Subject: Re: [iucg] Touchstones for "Mapping" X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 04:23:12 -0000 --=====================_93723718==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Dear Vint, Please do not underestimate this. What we want is this IDNA2008 to be acceptable and published asap. Let not make it an IDNA2010. At 01:24 26/03/2009, Vint Cerf wrote: >Jfc, this working group and its predecessor made a number of decisions This WG has been established to correct errors that its predecessor may have made and so far has not made any decision. In addition ... > as to which characters and categories of unicode characters are > permitted for use in domain names. this WG is chartered to specify the rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen ("-") in domain names because experience has shown that significant improvements could be made in the protocol as presently specified. Not to discriminate between these characters, but to support more of them, including those not yet specified by Unicode. However, there may be cases where the stability of the Internet is engaged, this is why the charter recognizes that some explicit exceptions may be necessary, but attempts will be made to minimize these exceptions. This is not the case of TATWEEL. To the countrary, the reason unanimously given concerning TATWEEL is its visual confusion, the leading additional comment being that there are other characters in the same case. So, this concerns the problem of characters that are confusingly similar in appearance that are not specifically part of the scope of the WG. >The working group is chartered and fully empowered to make these >choices using any resources and advice at its disposal. This group is fully empowered to make engineering choices to best support the use of other characters than LDH in minimizing the number of these choices. The current trend leads to something else. I do not oppose that something else as long as it stays wihtin the limits of internationalization + localization + filtering. But here localization issues are confused with internationalization issues. There is a layer violation. As expected, the immediate result is to transfer the concerns from scripts to languages: a proposition to rename ASIWG to ALIWG will now be discussed in Amman. With the lack of support of the French script (majuscules, petites et grandes capitales, minuscules) this makes two digressions from mediatics to full fledge semiotics... this is a very complex new territory for the IETF. This WG purpose is not to decide about such things, but to propose the solutions everyone will adhere to which permit to address them. >Any claim to the contrary is simply neither credible nor valid. Credibility and validity are at least two steps. - IETF LC and SSDOs will look at coherence. - Users if they trust and like it. Let keep things simple/stupid. No exception in the protocol and a simple rule to address them where they belong is the simplest. jfc > >---------- >From: jefsey@gmail.com >To: Lisa Dusseault ; Vint Cerf >Cc: listegenerale@franceatlarge.org ; iucg@ietf.org >Sent: Wed Mar 25 17:19:07 2009 >Subject: Re: Touchstones for "Mapping" >Dear Lisa and Vint, >It is now considered by some that making TATWEEL DISALLOWED at >protocol level is used as a case to show further on that the WG >consensus thinks that IETF has authority over what internet users >may or may not be allowed as a script for their own language, IRI >and IPR over the internet.� > >However,� >- such an authority MUST be accompanied by responsibility, according >to RFC 3935, as I already documented it. >-� I do not find the capacity to discuss (1) the evaluation of the >capacity to assume such an authority and (2) the organisation of >this responsibilty, in the WG Charter. � > >IMHO this should be clarified ASAP. >Best. >jfc --=====================_93723718==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear Vint,
Please do not underestimate this. What we want is this IDNA2008 to be acceptable and published asap. Let not make it an IDNA2010.

At 01:24 26/03/2009, Vint Cerf wrote:

Jfc, this working group and its predecessor made a number of decisions

This WG has been established to correct errors that its predecessor may have made and so far has not made any decision. In addition ...

as to which characters and categories of unicode characters are permitted for use in domain names.

this WG is chartered to specify the rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen ("-") in domain names because experience has shown that significant improvements could be made in the protocol as presently specified. Not to discriminate between these characters, but to support more of them, including those not yet specified by Unicode.

However, there may be cases where the stability of the Internet is engaged, this is why the charter recognizes that some explicit exceptions may be necessary, but attempts will be made to minimize these exceptions.

This is not the case of TATWEEL. To the countrary, the reason unanimously given concerning TATWEEL is its visual confusion, the leading additional comment being that there are other characters in the same case. So, this concerns the problem of characters that are confusingly similar in appearance that are not specifically part of the scope of the WG.

The working group is chartered and fully empowered to make these choices using any resources and advice at its disposal.

This group is fully empowered to make engineering choices to best support the use of other characters than LDH in minimizing the number of these choices. The current trend leads to something else. I do not oppose that something else as long as it stays wihtin the limits of internationalization + localization + filtering. But here localization issues are confused with internationalization issues. There is a layer violation. As expected, the immediate result is to transfer the concerns from scripts to languages: a proposition to rename ASIWG to ALIWG will now be discussed in Amman. With the lack of support of the French script (majuscules, petites et grandes capitales, minuscules) this makes two digressions from mediatics to full fledge semiotics... this is a very complex new territory for the IETF.

This WG purpose is not to decide about such things, but to propose the solutions everyone will adhere to which permit to address them.

Any claim to the contrary is simply neither credible nor valid.

Credibility and validity are at least two steps.
- IETF LC and SSDOs will look at coherence.
- Users if they trust and like it.

Let keep things simple/stupid. No exception in the protocol and a simple rule to address them where they belong is the simplest.

jfc

From: jefsey@gmail.com
To: Lisa Dusseault ; Vint Cerf
Cc: listegenerale@franceatlarge.org ; iucg@ietf.org
Sent: Wed Mar 25 17:19:07 2009
Subject: Re: Touchstones for "Mapping"
Dear Lisa and Vint,
It is now considered by some that making TATWEEL DISALLOWED at protocol level is used as a case to show further on that the WG consensus thinks that IETF has authority over what internet users may or may not be allowed as a script for their own language, IRI and IPR over the internet.�

However,�
- such an authority MUST be accompanied by responsibility, according to RFC 3935, as I already documented it.
-� I do not find the capacity to discuss (1) the evaluation of the capacity to assume such an authority and (2) the organisation of this responsibilty, in the WG Charter. �

IMHO this should be clarified ASAP.
Best.
jfc
--=====================_93723718==.ALT-- From vint@google.com Wed Mar 25 17:24:09 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287A03A680F for ; Wed, 25 Mar 2009 17:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MIME_BAD_LINEBREAK=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UDtKQhc7DYr for ; Wed, 25 Mar 2009 17:24:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 26A9F3A6805 for ; Wed, 25 Mar 2009 17:24:07 -0700 (PDT) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id n2Q0OrLQ030337; Thu, 26 Mar 2009 00:24:54 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1238027096; bh=xP7Fw0ZMqv2BT1AQ4lcLMO6at4o=; h=DomainKey-Signature:Content-class:MIME-Version:Content-Type: X-MimeOLE:Subject:Date:Message-ID:X-MS-Has-Attach: X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:From:To:Cc: X-System-Of-Record; b=feHJlgeS2448wKEoi4DIV4RwXOBQEESVzUAVEpT3+DzT kPrtnYGKMiTSRiqeDmaRe6c2LNl1YD9tGzfWAeWnRg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=content-class:mime-version:content-type:x-mimeole:subject:date: message-id:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:from:to:cc:x-system-of-record; b=ppJ12Emp55aZtGsTG1MhXpdfQZm3VSEPz5VCOvseUXTf/3BeM7jiHIbkBI8nm00K4 NkygAyWk8JsVceUWWkrrw== Received: from mtv-exbe-3.mtv.corp.google.com (mtv-exbe-3.mtv.corp.google.com [172.25.44.139]) by zps19.corp.google.com with ESMTP id n2Q0Oopw026503; Wed, 25 Mar 2009 17:24:50 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ADA9.467ECE03" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 25 Mar 2009 17:24:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Touchstones for "Mapping" Thread-Index: AcmtqH/zzyrUGP3wSaK7zBXfIvk0JgAAMZda From: "Vint Cerf" To: , , "Vint Cerf" X-System-Of-Record: true X-Mailman-Approved-At: Thu, 26 Mar 2009 15:44:02 -0700 Cc: listegenerale@franceatlarge.org, iucg@ietf.org Subject: Re: [iucg] Touchstones for "Mapping" X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:24:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ADA9.467ECE03 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmZjLCB0aGlzIHdvcmtpbmcgZ3JvdXAgYW5kIGl0cyBwcmVkZWNlc3NvciBtYWRlIGEgbnVtYmVy IG9mIGRlY2lzaW9ucyBhcyB0byB3aGljaCBjaGFyYWN0ZXJzIGFuZCBjYXRlZ29yaWVzIG9mIHVu aWNvZGUgY2hhcmFjdGVycy5hcmUgcGVybWl0dGVkIGZvciB1c2UgaW4gZG9tYWluIG5hbWVzLiBU aGUgd29ya2luZyBncm91cCBpcyBjaGFydGVyZWQgYW5kIGZ1bGx5IGVtcG93ZXJlZCB0byBtYWtl IHRoZXNlIGNob2ljZXMgdXNpbmcgYW55IHJlc291cmNlcyBhbmQgYWR2aWNlIGF0IGl0cyBkaXNw b3NhbC4gQW55IGNsYWltIHRvIHRoZXQgY29udHJhcnkgaXMgc2ltcGx5IG5laXRoZXIgY3JlZGli bGUgbm9yIHZhbGlkLiANCg0KVmludA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpGcm9tOiBqZWZzZXlAZ21haWwuY29tIA0KVG86IExpc2EgRHVzc2VhdWx0IDsgVmludCBD ZXJmIA0KQ2M6IGxpc3RlZ2VuZXJhbGVAZnJhbmNlYXRsYXJnZS5vcmcgOyBpdWNnQGlldGYub3Jn IA0KU2VudDogV2VkIE1hciAyNSAxNzoxOTowNyAyMDA5DQpTdWJqZWN0OiBSZTogVG91Y2hzdG9u ZXMgZm9yICJNYXBwaW5nIiANCg0KDQpEZWFyIExpc2EgYW5kIFZpbnQsDQpJdCBpcyBub3cgY29u c2lkZXJlZCBieSBzb21lIHRoYXQgbWFraW5nIFRBVFdFRUwgRElTQUxMT1dFRCBhdCBwcm90b2Nv bCBsZXZlbCBpcyB1c2VkIGFzIGEgY2FzZSB0byBzaG93IGZ1cnRoZXIgb24gdGhhdCB0aGUgV0cg Y29uc2Vuc3VzIHRoaW5rcyB0aGF0IElFVEYgaGFzIGF1dGhvcml0eSBvdmVyIHdoYXQgaW50ZXJu ZXQgdXNlcnMgbWF5IG9yIG1heSBub3QgYmUgYWxsb3dlZCBhcyBhIHNjcmlwdCBmb3IgdGhlaXIg b3duIGxhbmd1YWdlLCBJUkkgYW5kIElQUiBvdmVyIHRoZSBpbnRlcm5ldC4gDQoNCkhvd2V2ZXIs IA0KLSBzdWNoIGFuIGF1dGhvcml0eSBNVVNUIGJlIGFjY29tcGFuaWVkIGJ5IHJlc3BvbnNpYmls aXR5LCBhY2NvcmRpbmcgdG8gUkZDIDM5MzUsIGFzIEkgYWxyZWFkeSBkb2N1bWVudGVkIGl0Lg0K DQotIEkgZG8gbm90IGZpbmQgdGhlIGNhcGFjaXR5IHRvIGRpc2N1c3MgKDEpIHRoZSBldmFsdWF0 aW9uIG9mIHRoZSBjYXBhY2l0eSB0byBhc3N1bWUgc3VjaCBhbiBhdXRob3JpdHkgYW5kICgyKSB0 aGUgb3JnYW5pc2F0aW9uIG9mIHRoaXMgcmVzcG9uc2liaWx0eSwgaW4gdGhlIFdHIENoYXJ0ZXIu ICANCg0KSU1ITyB0aGlzIHNob3VsZCBiZSBjbGFyaWZpZWQgQVNBUC4NCkJlc3QuDQpqZmMNCg0K DQo= ------_=_NextPart_001_01C9ADA9.467ECE03 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PHA+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD4NCkpmYywgdGhpcyB3b3JraW5n IGdyb3VwIGFuZCBpdHMgcHJlZGVjZXNzb3IgbWFkZSBhIG51bWJlciBvZiBkZWNpc2lvbnMgYXMg dG8gd2hpY2ggY2hhcmFjdGVycyBhbmQgY2F0ZWdvcmllcyBvZiB1bmljb2RlIGNoYXJhY3RlcnMu YXJlIHBlcm1pdHRlZCBmb3IgdXNlIGluIGRvbWFpbiBuYW1lcy4gVGhlIHdvcmtpbmcgZ3JvdXAg aXMgY2hhcnRlcmVkIGFuZCBmdWxseSBlbXBvd2VyZWQgdG8gbWFrZSB0aGVzZSBjaG9pY2VzIHVz aW5nIGFueSByZXNvdXJjZXMgYW5kIGFkdmljZSBhdCBpdHMgZGlzcG9zYWwuIEFueSBjbGFpbSB0 byB0aGV0IGNvbnRyYXJ5IGlzIHNpbXBseSBuZWl0aGVyIGNyZWRpYmxlIG5vciB2YWxpZC4gPGJy Pjxicj5WaW50PC9mb250PjwvcD4NCjxwPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNl bnRlciB0YWJpbmRleD0tMT4NCjxmb250IGZhY2U9VGFob21hIHNpemU9Mj4NCjxiPkZyb208L2I+ OiBqZWZzZXlAZ21haWwuY29tIDxqZWZzZXlAZ21haWwuY29tPg08YnI+PGI+VG88L2I+OiBMaXNh IER1c3NlYXVsdCA8bGlzYS5kdXNzZWF1bHRAbWVzc2FnaW5nYXJjaGl0ZWN0cy5jb20+OyBWaW50 IENlcmYNPGJyPjxiPkNjPC9iPjogbGlzdGVnZW5lcmFsZUBmcmFuY2VhdGxhcmdlLm9yZyA8bGlz dGVnZW5lcmFsZUBmcmFuY2VhdGxhcmdlLm9yZz47IGl1Y2dAaWV0Zi5vcmcgPGl1Y2dAaWV0Zi5v cmc+DTxicj48Yj5TZW50PC9iPjogV2VkIE1hciAyNSAxNzoxOTowNyAyMDA5PGJyPjxiPlN1Ympl Y3Q8L2I+OiBSZTogVG91Y2hzdG9uZXMgZm9yICJNYXBwaW5nIg08YnI+PC9mb250PjwvcD4NCjxk aXYgc3R5bGU9InRleHQtYWxpZ246IGxlZnQ7Ij5EZWFyIExpc2EgYW5kIFZpbnQsPC9kaXY+PGRp dj5JdCBpcyBub3cgY29uc2lkZXJlZCBieSBzb21lIHRoYXQgbWFraW5nIFRBVFdFRUwgRElTQUxM T1dFRCBhdCBwcm90b2NvbCBsZXZlbCBpcyB1c2VkIGFzIGEgY2FzZSB0byBzaG93IGZ1cnRoZXIg b24gdGhhdCB0aGUgV0cgY29uc2Vuc3VzIHRoaW5rcyB0aGF0IElFVEYgaGFzIGF1dGhvcml0eSBv dmVyIHdoYXQgaW50ZXJuZXQgdXNlcnMgbWF5IG9yIG1heSBub3QgYmUgYWxsb3dlZCBhcyBhIHNj cmlwdCBmb3IgdGhlaXIgb3duIGxhbmd1YWdlLCBJUkkgYW5kIElQUiBvdmVyIHRoZSBpbnRlcm5l dC7CoDwvZGl2Pg0KPGRpdj48YnI+PC9kaXY+PGRpdj5Ib3dldmVyLMKgPC9kaXY+PGRpdj4tIHN1 Y2ggYW4gYXV0aG9yaXR5IE1VU1QgYmUgYWNjb21wYW5pZWQgYnkgcmVzcG9uc2liaWxpdHksIGFj Y29yZGluZyB0byBSRkMgMzkzNSwgYXMgSSBhbHJlYWR5IGRvY3VtZW50ZWQgaXQuPGJyPjwvZGl2 PjxkaXY+LcKgSSBkbyBub3QgZmluZCB0aGUgY2FwYWNpdHkgdG8gZGlzY3VzcyAoMSkgdGhlIGV2 YWx1YXRpb24gb2YgdGhlIGNhcGFjaXR5IHRvIGFzc3VtZSBzdWNoIGFuIGF1dGhvcml0eSBhbmQg KDIpIHRoZSBvcmdhbmlzYXRpb24gb2YgdGhpcyByZXNwb25zaWJpbHR5LCBpbiB0aGUgV0cgQ2hh cnRlci4gwqA8L2Rpdj4NCjxkaXY+PGJyPjwvZGl2PjxkaXY+SU1ITyB0aGlzIHNob3VsZCBiZSBj bGFyaWZpZWQgQVNBUC48L2Rpdj48ZGl2PkJlc3QuPC9kaXY+PGRpdj5qZmM8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2Pjxicj48L2Rpdj4NCg== ------_=_NextPart_001_01C9ADA9.467ECE03-- From saleh@nic.ir Thu Mar 26 04:15:05 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FABD3A6827 for ; Thu, 26 Mar 2009 04:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O44GZ7zTKQjm for ; Thu, 26 Mar 2009 04:15:04 -0700 (PDT) Received: from relay.irnic.ir (relay.linux.ir [193.189.122.196]) by core3.amsl.com (Postfix) with ESMTP id B36DF3A6403 for ; Thu, 26 Mar 2009 04:15:03 -0700 (PDT) Message-ID: <49CB6454.10203@nic.ir> Date: Thu, 26 Mar 2009 15:47:40 +0430 From: Alireza Saleh User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: JFC Morfin References: <200903260423.n2Q4NX7W014604@smtp.irnic.ir> In-Reply-To: <200903260423.n2Q4NX7W014604@smtp.irnic.ir> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 26 Mar 2009 15:44:02 -0700 Cc: listegenerale@franceatlarge.org, Vint Cerf , iucg@ietf.org, lisa.dusseault@messagingarchitects.com Subject: Re: [iucg] Touchstones for "Mapping" X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 11:15:05 -0000 +1 JFC Morfin wrote: > Dear Vint, > Please do not underestimate this. What we want is this IDNA2008 to be > acceptable and published asap. Let not make it an IDNA2010. > > At 01:24 26/03/2009, Vint Cerf wrote: >> Jfc, this working group and its predecessor made a number of decisions > > This WG has been established to correct errors that its predecessor > may have made and so far has not made any decision. In addition ... > >> as to which characters and categories of unicode characters are >> permitted for use in domain names. > > this WG is chartered to specify the rules for the use of characters > other than Latin A(a)-Z(z), digits 0-9 and the hyphen ("-") in domain > names because experience has shown that significant improvements could > be made in the protocol as presently specified. Not to discriminate > between these characters, but to support more of them, including those > not yet specified by Unicode. > > However, there may be cases where the stability of the Internet is > engaged, this is why the charter recognizes that some explicit > exceptions may be necessary, but attempts will be made to minimize > these exceptions. > > This is not the case of TATWEEL. To the countrary, the reason > unanimously given concerning TATWEEL is its visual confusion, the > leading additional comment being that there are other characters in > the same case. So, this concerns the problem of characters that are > confusingly similar in appearance that are not specifically part of > the scope of the WG. > >> The working group is chartered and fully empowered to make these >> choices using any resources and advice at its disposal. > > This group is fully empowered to make engineering choices to best > support the use of other characters than LDH in minimizing the number > of these choices. The current trend leads to something else. I do not > oppose that something else as long as it stays wihtin the limits of > internationalization + localization + filtering. But here localization > issues are confused with internationalization issues. There is a layer > violation. As expected, the immediate result is to transfer the > concerns from scripts to languages: a proposition to rename ASIWG to > ALIWG will now be discussed in Amman. With the lack of support of the > French script (majuscules, petites et grandes capitales, minuscules) > this makes two digressions from mediatics to full fledge semiotics... > this is a very complex new territory for the IETF. > > This WG purpose is not to decide about such things, but to propose the > solutions everyone will adhere to which permit to address them. > >> Any claim to the contrary is simply neither credible nor valid. > > Credibility and validity are at least two steps. > - IETF LC and SSDOs will look at coherence. > - Users if they trust and like it. > > Let keep things simple/stupid. No exception in the protocol and a > simple rule to address them where they belong is the simplest. > > jfc > >> ------------------------------------------------------------------------ >> *From*: jefsey@gmail.com >> *To*: Lisa Dusseault ; Vint Cerf >> *Cc*: listegenerale@franceatlarge.org ; iucg@ietf.org >> *Sent*: Wed Mar 25 17:19:07 2009 >> *Subject*: Re: Touchstones for "Mapping" >> Dear Lisa and Vint, >> It is now considered by some that making TATWEEL DISALLOWED at >> protocol level is used as a case to show further on that the WG >> consensus thinks that IETF has authority over what internet users may >> or may not be allowed as a script for their own language, IRI and IPR >> over the internet.� >> >> However,� >> - such an authority MUST be accompanied by responsibility, according >> to RFC 3935, as I already documented it. >> -� I do not find the capacity to discuss (1) the evaluation of the >> capacity to assume such an authority and (2) the organisation of this >> responsibilty, in the WG Charter. � >> >> IMHO this should be clarified ASAP. >> Best. >> jfc From jefsey@jefsey.com Sun Mar 29 19:21:01 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4E63A6CF1 for ; Sun, 29 Mar 2009 19:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2NowEL+PLsT for ; Sun, 29 Mar 2009 19:21:00 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 96C963A6CEB for ; Sun, 29 Mar 2009 19:21:00 -0700 (PDT) Received: from [79.94.76.110] (port=3603 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtp (Exim 4.69) (envelope-from ) id 1Lo78P-0006Kf-4S for iucg@ietf.org; Sun, 29 Mar 2009 19:21:57 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 Mar 2009 04:21:54 +0200 To: iucg@ietf.org From: jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Pass-two: yes X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20090330022100.96C963A6CEB@core3.amsl.com> Subject: [iucg] ADN X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 02:21:01 -0000 Vint Cerf as a Chair of the WG-IDNABIS steers his WG outside of its Charter, trying to give it a linguistic legitimacy. This unfortunately removes credibility and therefore technical legitimacy to that WG. He just chose to try to shut my mouth in _removing_ me from the list! Actually, this is a good metter. This means that my position (to support users linguistic empowerment rather than their linguistic control by Google engineers) gains support. This eventually shows that most probably the IDNA proposition is not going to be ready anytime very soon, and will be disputed at IETF LC level. Our user problem is to stabilise now a linguistic Domain Name practice as soon as possible. If IDNA2008 fails us, we need to deploy a solution than we can use asap without depending on IETF (organised?) delays and ICANN limitations. That also can support semantic addressing. I therefore propose you that we write in the shortest delay an I_D for information we will ask the IESG to accept. It would describe our existing/immediately possible practice. The principle is simple: it is a transparent generalisation of IDNs, we call ADN (Applied Domain Names). These domain names: - are built in the xx-- format (except xn--). - the "xx--" header tells the application which coding/decoding algorithm to use. - TLD and zone managers accept their registrations without any special consideration. ADNs are user applications layer app2app codes: it belongs to these applications to deal with them. We only need to create an IUCG header table (ADNH) for the code (header) of the various possible algorithms. Comments welcome. jfc