From psuger@gmail.com Tue Dec 1 09:34: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 BE8B83A6903 for ; Tue, 1 Dec 2009 09:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 fUoyXVE7tpxR for ; Tue, 1 Dec 2009 09:34:20 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 1A5FD3A6950 for ; Tue, 1 Dec 2009 09:34:18 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so448773fga.13 for ; Tue, 01 Dec 2009 09:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=7dEYALQoQ4D5JXd97D08S8+3Yrqja7ShaA3dBATbBDU=; b=U0R0gvIOQjGJ2S5FJvy9yxlCsk1rmg6pP8XUcQe8/eUGyPQKNHaIaRaAHKxHJe/vIr BSUDEWFQJ47H9aA7Fk2fQus8+etRUI+lebWnRmLRpKtCw7Ogmr3nlzdwEnIRaONfuuDC UUahKRNK2EfN7Lyjy9yydymaz/goKGGbo9Mjo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=DlO9kGM4FT2Z6t818EEkynmcLSFI3rGsCFFRj7cDJKpqd4CuzAHC/51y8A34n7l0TT BR2mI4ryrpbbRpV7xeIWAgBMBCe0cCVzGJLQdSLnaNQIB3e0lqfo7rogN4oE05AY+Pns KiGfCsP88U2d5vTItc9ewlnNKowjZaU9GjEDc= MIME-Version: 1.0 Received: by 10.239.141.159 with SMTP id c31mr609734hba.147.1259688846801; Tue, 01 Dec 2009 09:34:06 -0800 (PST) Date: Tue, 1 Dec 2009 18:34:06 +0100 Message-ID: <4e9b16b30912010934n1077ddb4n6361df098d2ba00d@mail.gmail.com> From: Patrick Suger To: IDNA update work , Lisa Dusseault , Vint Cerf Content-Type: multipart/alternative; boundary=001485f6c75a3dbca70479ae2aad Cc: internet users contributing group Subject: [iucg] Jefsey's disciples 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, 01 Dec 2009 17:34:21 -0000 --001485f6c75a3dbca70479ae2aad Content-Type: text/plain; charset=ISO-8859-1 *Adrew Sullivan, Eric Brunner-Williams wrote:* "Nobody is trying to make domain name labels into language (well, maybe Jefsey's disciples are, but leave that aside), but we have to be realistic and understand that the utility and ease of a given set of labels is going to be heavily conditioned by the socio-linguistic background of the person." "Unfortunately, to that set the persons who assert that labels formed from characters taken from Arabic Script must be "words" must be added. So, Jefsey's disciples and a plurality of a vendor's forum, and I'd greatly prefer if it was just Jefsey's disciples." Dear Colleagues, I am surprised by this. I assumed the target was to assess the technical consensus in accepting to characters as PVALID. No to discriminate a consensus on people's opinions. One. Nobody is someone else's disciple, however some are others' employees. I suspect I qualify as a "Jefsey's disciple". I am not (we had a recent fundamental dispute on a mailing list which would disqualify me). We are Internet lead users (i.e. @larges), members of the iucg@ietf.org mailing list, French speaking people gathered by the poor IDNA support of our French language orthotypography, we need to support our ".fra" project. Two. This is no reason for "leaving them/us asside". They/we are equal members of this WG and equal contributors to its work. Actually, we already engaged work to stabilize its quick deployment trough best user practices publications (http://idna2010.org). Look we start being upset by all the dillatory blahblah. We want IDNA published ASAP, so we can build our own open Internet usage solutions and clarify the ICANN's attitude. Three. I am at real loss when I try to understand how we could really help filling the gap between some IETF participants and real world users, when the matter is non protocol issues. Where I am certainly a supporter of Jefsey is in his efforts to help in this area. May be he is wrong, but I can only note how Jefsey is "left aside" by this WG. *Eric Brunner-Williams wrote:* "I don't know of any other organized group of "label to non-label" advocates attempting to change label semantics". A part from billion people nations.... Anyway, I do know an organized group attempting to change the human semantics. Actually, I am mainly interested in the only existing natural semantic processor (i.e. the human brain): its I/O protocols are languages, its syntax is orthotypographic. The Internet of the users? Best Patrick Suger. --001485f6c75a3dbca70479ae2aad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adrew Sullivan, Eric Brunner-Williams = wrote:
"Nobody is trying to make domain name labels into langua= ge (well, maybe Jefsey's disciples are, but leave that aside), but we h= ave to be realistic and understand that the utility and ease of a given set= of labels is going to be heavily conditioned by the socio-linguistic backg= round of the person." "Unfortunately, to that set the persons who= assert that labels formed from characters taken from Arabic Script must be= "words" must be added. So, Jefsey's disciples and a pluralit= y of a vendor's forum, and I'd greatly prefer if it was just Jefsey= 's disciples."


Dear Colleagues,

I am surprised by this. I assumed the= target was to assess the technical consensus in accepting to characters as= PVALID. No to discriminate a consensus on people's opinions.

One. Nobody is someone else's disciple, however some are others' em= ployees. I suspect I qualify as a "Jefsey's disciple". I am n= ot (we had a recent fundamental dispute on a mailing list which would disqu= alify me). We are Internet lead users (i.e. @larges), members of the iucg@ietf.org mailing list, French speaking = people gathered by the poor IDNA support of our French language orthotypogr= aphy, we need to support our ".fra" project.

Two. This is no reason for "leaving them/us asside". They/we = are equal members of this WG and equal contributors to its work. Actually, = we already engaged work to stabilize its quick deployment trough best user = practices publications (http://idna2010.org= ). Look we start being upset by all the dillatory blahblah. We want IDN= A published ASAP, so we can build our own open Internet usage solutions and= clarify the ICANN's attitude.

Three. I am at real loss when I try to understand how we could really h= elp filling the gap between some IETF participants and real world users, wh= en the matter is non protocol issues. Where I am certainly a supporter of J= efsey is in his efforts to help in this area. May be he is wrong, but I can= only note how Jefsey is "left aside" by this WG.

Eric Brunner-Williams wrote:"I don't know of any other organized group of "label to non= -label" advocates attempting to change label semantics".

A part from billion people nations....

Anyway, I do know an orga= nized group attempting to change the human semantics.
Actually, I am ma= inly interested in the only existing natural semantic processor (i.e. the h= uman brain): its I/O protocols are languages, its syntax is orthotypographi= c. The Internet of the users?

Best

Patrick Suger.
--001485f6c75a3dbca70479ae2aad-- From eblanconil@gmail.com Tue Dec 1 06:04:28 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 A7D1E3A6962 for ; Tue, 1 Dec 2009 06:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[AWL=-3.200, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_33=0.6, MANGLED_MEDS=2.3, MIME_8BIT_HEADER=0.3] 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 p0xLDELcdVV9 for ; Tue, 1 Dec 2009 06:04:26 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 8A9953A6A4E for ; Tue, 1 Dec 2009 06:03:01 -0800 (PST) Received: by fxm5 with SMTP id 5so4910780fxm.28 for ; Tue, 01 Dec 2009 06:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=R5PIJgfnhyrxtufXMwu82rcTzNgTfTP81aa+ZJzjIAQ=; b=gcMglAmRzgYmMgKdGXsjDRJr7JhQ92zbPaO0q8cBSNBFZdypqClprBfopSaKFD/SNY yu+q4G2m3Hmng2KxBHhrzIx7LLSRiVVxjRVJv/Qi1Q2cPxzkYPOQJjK3ugGD0JMRm7aW 0Cd+3rzuze4Wu84lBtLZ92IUw3OnRkHgldQxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XJRZ+zSmKCASkYUvmVcHZrK0lPTGP2PrDPc5GMosdiH2FDtyJD6/LtGpcbXOJpWX9l 2sxqUQuL56c9UbiFPe4lTRmkK/rFlv3UlNBodWT9/h8rvlRkGOBF1jvDOUDarrqDCtKI ZeVDP2LZSfPPOcSqvaTKDc+1oPSNdQRivIabM= MIME-Version: 1.0 Received: by 10.216.88.207 with SMTP id a57mr1909913wef.200.1259676169626; Tue, 01 Dec 2009 06:02:49 -0800 (PST) In-Reply-To: <6aad7a210912010215r2f9c39bcle6e7504e3190a297@mail.gmail.com> References: <4b148214.0710660a.3c47.3aeeSMTPIN_ADDED@mx.google.com> <6aad7a210912010215r2f9c39bcle6e7504e3190a297@mail.gmail.com> Date: Tue, 1 Dec 2009 15:02:49 +0100 Message-ID: <6589127a0912010602l3e52040dv53323366c53fa2e6@mail.gmail.com> From: Elisabeth Blanconil To: comptoir@cafedu.com Content-Type: multipart/alternative; boundary=0016e6d7eaa79f66320479ab3684 X-Mailman-Approved-At: Tue, 01 Dec 2009 09:37:44 -0800 Subject: Re: [iucg] =?iso-8859-1?q?=5Bcomptoir_707=5D_Re=3A_c=27est_pas_moi=2C?= =?iso-8859-1?q?_c=27est_vint_cerf_qu=27a_cass=E9_la_machine_=E0_gl?= =?iso-8859-1?q?in-glin-ternet_!?= 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, 01 Dec 2009 14:04:28 -0000 --0016e6d7eaa79f66320479ab3684 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aye ! JFC ! Je r=E9sume l'=E9tendue technico-=E9cnomique, politique, strat=E9gique du d=E9sastre/changement si j'ai bien compris. 1. tu nous as fait discuter Interplus. On est =E0 peu pr=E8s d'accord, mais l'introduction d=E9pend du texte sur IDNA en finalisation =E0 l'IESG. Eeauc= oup ncore une cinquantaine de mails hier. 2. tu nous as dit pour impl=E9menter l'Interplus il faut une interbox physi= que ou logicielle. Elle aura deux prises (physiques ou logiques) : - une vers l'internet - une vers la machine utilisateur. Si elle est logique, l'interbox est localis=E9e sur la machine utilisateur. 3. on va y localiser trois choses : - un ONES, c'est-=E0-dire un r=E9seau de services =E9tendus - une couche d'applications fournissant ces services - des outils de gestion qui vont fonctionner sous un syst=E8me d'interapplication Netix, vont virtuellement supporter la couche interapplication et utiliser les classes. 4. ce faisant on ne va RIEN changer de l'internet et des applications, et utiliser au maximum ce qui existe et qui est valid=E9. 5. tu nous dis : il me faut des d=E9veloppeurs C humbles, d=E9di=E9s et intelligents (pas facile =E0 trouver) pour t'aider =E0 tester toutes ces id= =E9es. 6. En attendant tu testes le logiciel phare : BIND non pas comme un service r=E9seau, mais comme une application utilisateur, comme tu nous as parl=E9 = de Perl, Apache et peut-=EAtre Lisp. 7. Et tu vois que si l'on utilise BIND en couche "services pseudo-r=E9seau"= , et non-pas =E0 travers un appel =E0 la "couche services r=E9seau" (DNS de l= 'ISP), la plus part des doubles contraintes qui prot=E8gent la stabilit=E9 d'utilisation et =E9conomiques de l'Internet tombent. Non seulement, nous savions que l'interplus est au nommage et =E0 l'=E9cono= mie de l'internet, ce que les NATs sont =E0 son adressage et =E0 son routage : = un cauchemard et une opportunit=E9 ... mais nous d=E9couvrons que l'impl=E9mentation de l'Interplus est d=E9j=E0 l= =E0, alors que RIEN n'a =E9t=E9 fait pour nous en prot=E9ger et pour en tirer parti de= fa=E7on organis=E9e. Donc l'urgence absolue est de trouver une parade =E0 la d=E9stabilisation d= u nommage. C'est un sujet dont tu ne nous as jamais parl=E9 ? Que proposes-tu= ? Si je comprends bien on parle de milliards d'euro et de refonte totale de l= a Gouvernance ? Cela ne nous d=E9passe-t-il pas un peu beaucoup ? Elisabeth Blanconil Le 1 d=E9cembre 2009 11:15, jean-michel bernier de portzamparc < jmabdp@gmail.com> a =E9crit : > Tu rigoles ou quoi ? > C'est la mort du petit cheval ! > On peut faire tout cela avec Bind ? > Je m'y mets vraiement !!! > > Portzamparc > > Le 1 d=E9cembre 2009 03:39, jefsey a =E9crit : > > Chers CafeduComp=E8res et Caf=E9duCom=E8res, >> >> dans mon processus lent vu les charges pas ailleurs, qui consiste =E0 >> prototyper l'interplus (ce qui manque =E0 l'Internet pour supporter >> l'intersem) - je n'ai toujors pas trouv=E9 de d=E9veloppeur C Windows >> suffisament fou pour changer l'Internet - je proc=E8de comme indiqu=E9 := je ne >> change rien, j'utilise ce qu'il y a d'actuellement le plus courrant. >> >> Je me suis donc pris par la main et j'ai fait ce que tout le monde peut >> faire. J'ai t=E9l=E9charg=E9 BIND sur mon XP. J'ai cherch=E9 =E0 compren= dre s'il >> correspondait bien aux RFC. etc. J'ai pos=E9 quelques questions pour ce = qu'ils >> ne veulent pas documenter, etc. Le r=E9sultat actuel est le suivant : >> >> 1. je ne suis plus d=E9pendant que de "MYCANN" (My Concerted Adminance o= f >> Names and Numbers). >> >> 2. sous les fichiers "MYCANN" que je vais peu =E0 peu me proposer, j'ai >> 65000 fichiers racines (toutes les classes), des dizaines de milliers de >> pr=E9sentations, des dizaines de milliers de TLD (tout cela se multiplie= l'un >> pas l'autre pour faire de la diversit=E9). Un TLD me co=FBte 1 minute et= z=E9ro >> euro dix d'=E9lectricit=E9, temps internet et temps machine =E0 cr=E9er. >> >> 3. j'ai des milliards de sous-adresses IDv6 et pas de probl=E8me pour >> supporter les 25.000 langues document=E9es par Linguasph=E8re (sauf les >> majuscules fran=E7aises, l=E0 il me faut un vrai d=E9veloppeur) >> >> Grosso modo, si on y passe un peu de temps, revoit l'installateur Window= s, >> travaille un peu les configs et les syst=E8mes de mises =E0 jour, il doi= t =EAtre >> possible de se cr=E9er une telle "internef" (cybship) moyennant un >> t=E9l=E9chargement d'une vingtaine de Giga et cinq minutes de mise en pl= ace. Et >> qui soit bien, bien plus s=FBr et plus rapide que ce que vous utilisez. >> >> Bien entendu les noms de domaine du type coca-cola.fra, ibm.jfc, etc. et >> m=EAme ibm.com et nic.fr totalement l=E9gitimes, m=EAme aux yeux des pir= es >> ICANNiens, ne me co=FBtent pas un sous et marchent du tonnerre. Et cela = c'est >> vrai pour quiconque. M=EAme au fond de l'Afrique, du Bengladesh, ou de D= C. >> Pour pas un rond : plus d'ICANN, plus d'Am=E9ricain, plus d'ISOC. ! >> >> Cela, c'est l'internet d=E9velopp=E9 par Vint Cerf, l'IETF, "g=E9r=E9" p= ar l'ICANN >> quand il est utilis=E9 sans se laisser impressionner par le >> blahblahyanki/paris ambiant. Pas celui de demain, du futur, etc. c'est c= elui >> d'aujourd'hui tel que sp=E9cifi=E9 en 1982. >> >> Bon, maintenant qu'est-ce qu'on fait :-) Parceque si tout pour tout cass= er >> est l=E0, ils n'ont rien voulu pr=E9voir pour que l'on puisse quand m=EA= me >> continuer =E0 communiquer entre nous. La devise de Vint est "si c'est pa= s >> cass=E9, y faut pas r=E9parer". Eh! bien. Si ce n'est pas encore tout ca= ss=E9, >> cela semble un peu bancal. >> >> jfc >> > --0016e6d7eaa79f66320479ab3684 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aye ! JFC !

Je r=E9sume l'=E9tendue technico-=E9cnomique, politi= que, strat=E9gique du d=E9sastre/changement si j'ai bien compris.
1. tu nous as fait discuter Interplus. On est =E0 peu pr=E8s d'accord= , mais l'introduction d=E9pend du texte sur IDNA en finalisation =E0 l&= #39;IESG. Eeaucoup ncore une cinquantaine de mails hier.

2. tu nous as dit pour impl=E9menter l'Interplus il faut une interb= ox physique ou logicielle. Elle aura deux prises (physiques ou logiques) :<= br>=A0=A0=A0 - une vers l'internet
=A0=A0=A0 - une vers la machine u= tilisateur.
=A0=A0=A0 Si elle est logique, l'interbox est localis=E9e sur la machin= e utilisateur.

3. on va y localiser trois choses :
=A0=A0=A0 - u= n ONES, c'est-=E0-dire un r=E9seau de services =E9tendus
=A0=A0=A0 -= une couche d'applications fournissant ces services
=A0=A0=A0 - des outils de gestion qui vont fonctionner sous un syst=E8me d&= #39;interapplication Netix, vont virtuellement supporter la couche interapp= lication et utiliser les classes.

4. ce faisant on ne va RIEN change= r de l'internet et des applications, et utiliser au maximum ce qui exis= te et qui est valid=E9.

5. tu nous dis : il me faut des d=E9veloppeurs C humbles, d=E9di=E9s et= intelligents (pas facile =E0 trouver) pour t'aider =E0 tester toutes c= es id=E9es.

6. En attendant tu testes le logiciel phare : BIND non p= as comme un service r=E9seau, mais comme une application utilisateur, comme= tu nous as parl=E9 de Perl, Apache et peut-=EAtre Lisp.

7. Et tu vois que si l'on utilise BIND en couche "services pse= udo-r=E9seau", et non-pas =E0 travers un appel =E0 la "couche ser= vices r=E9seau" (DNS de l'ISP), la plus part des doubles contraint= es qui prot=E8gent la stabilit=E9 d'utilisation et =E9conomiques de l&#= 39;Internet tombent.

Non seulement, nous savions que l'interplus est au nommage et =E0 l= '=E9conomie de l'internet, ce que les NATs sont =E0 son adressage e= t =E0 son routage : un cauchemard et une opportunit=E9 ...

mais nous= d=E9couvrons que l'impl=E9mentation de l'Interplus est d=E9j=E0 l= =E0, alors que RIEN n'a =E9t=E9 fait pour nous en prot=E9ger et pour en= tirer parti de fa=E7on organis=E9e.

Donc l'urgence absolue est de trouver une parade =E0 la d=E9stabili= sation du nommage. C'est un sujet dont tu ne nous as jamais parl=E9 ? Q= ue proposes-tu ? Si je comprends bien on parle de milliards d'euro et d= e refonte totale de la Gouvernance ? Cela ne nous d=E9passe-t-il pas un peu= beaucoup ?

Elisabeth Blanconil

Le 1 d=E9cembre 2= 009 11:15, jean-michel bernier de portzamparc <jmabdp@gmail.com> a =E9crit :
Tu rigoles ou quoi ?
C'est la mort du petit cheval !
On peut fair= e tout cela avec Bind ?
Je m'y mets vraiement !!!

Portzamparc=

Le 1 d=E9cembre 2009 03:39, jefsey <jef= sey@jefsey.com> a =E9crit :

Chers CafeduComp= =E8res et Caf=E9duCom=E8res,

dans mon processus lent vu les charges pas ailleurs, qui consiste =E0 proto= typer l'interplus (ce qui manque =E0 l'Internet pour supporter l= 9;intersem) - je n'ai toujors pas trouv=E9 de d=E9veloppeur C Windows s= uffisament fou pour changer l'Internet - je proc=E8de comme indiqu=E9 := je ne change rien, j'utilise ce qu'il y a d'actuellement le pl= us courrant.

Je me suis donc pris par la main et j'ai fait ce que tout le monde peut= faire. J'ai t=E9l=E9charg=E9 BIND sur mon XP. J'ai cherch=E9 =E0 c= omprendre s'il correspondait bien aux RFC. etc. J'ai pos=E9 quelque= s questions pour ce qu'ils ne veulent pas documenter, etc. =A0Le r=E9su= ltat actuel est le suivant :

1. je ne suis plus d=E9pendant que de "MYCANN" (My Concerted Admi= nance of Names and Numbers).

2. sous les fichiers "MYCANN" que je vais peu =E0 peu me proposer= , j'ai 65000 fichiers racines (toutes les classes), des dizaines de mil= liers de pr=E9sentations, des dizaines de milliers de TLD (tout cela se mul= tiplie l'un pas l'autre pour faire de la diversit=E9). Un TLD me co= =FBte 1 minute et z=E9ro euro dix d'=E9lectricit=E9, temps internet et = temps machine =E0 cr=E9er.

3. j'ai des milliards de sous-adresses IDv6 et pas de probl=E8me pour s= upporter les 25.000 langues document=E9es par Linguasph=E8re (sauf les maju= scules fran=E7aises, l=E0 il me faut un vrai d=E9veloppeur)

Grosso modo, si on y passe un peu de temps, revoit l'installateur Windo= ws, travaille un peu les configs et les syst=E8mes de mises =E0 jour, il do= it =EAtre possible de se cr=E9er une telle "internef" (cybship) m= oyennant un t=E9l=E9chargement d'une vingtaine de Giga et cinq minutes = de mise en place. Et qui soit bien, bien plus s=FBr et plus rapide que ce q= ue vous utilisez.

Bien entendu les noms de domaine du type coca-cola.fra, ibm.jfc, etc. et m= =EAme ibm.com et nic.fr totalement l=E9gitimes, m= =EAme aux yeux des pires ICANNiens, ne me co=FBtent pas un sous et marchent= du tonnerre. Et cela c'est vrai pour quiconque. M=EAme au fond de l= 9;Afrique, du Bengladesh, ou de DC. Pour pas un rond : plus d'ICANN, pl= us d'Am=E9ricain, plus d'ISOC. !

Cela, c'est l'internet d=E9velopp=E9 par Vint Cerf, l'IETF, &qu= ot;g=E9r=E9" par l'ICANN quand il est utilis=E9 sans se laisser im= pressionner par le blahblahyanki/paris ambiant. Pas celui de demain, du fut= ur, etc. c'est celui d'aujourd'hui tel que sp=E9cifi=E9 en 1982= .

Bon, maintenant qu'est-ce qu'on fait :-) Parceque si tout pour tout= casser est l=E0, ils n'ont rien voulu pr=E9voir pour que l'on puis= se quand m=EAme continuer =E0 communiquer entre nous. La devise de Vint est= "si c'est pas cass=E9, y faut pas r=E9parer". Eh! bien. Si c= e n'est pas encore tout cass=E9, cela semble un peu bancal.

jfc
--0016e6d7eaa79f66320479ab3684-- From psuger@gmail.com Tue Dec 1 14:42:51 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 5905A3A69BE for ; Tue, 1 Dec 2009 14:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Mbu-7mZM92Oh for ; Tue, 1 Dec 2009 14:42:50 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 16C563A6916 for ; Tue, 1 Dec 2009 14:42:49 -0800 (PST) Received: by fxm5 with SMTP id 5so5526289fxm.28 for ; Tue, 01 Dec 2009 14:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=O09ZnXH/LN9/rnxLtDHJfnRfhLXfesYdeFnF3a7/Low=; b=IvZj8mziY70iGf9Fqed3TviTWAtSjFY3VwiHB4op+VZurIqcLw1JBtBzxShGdNN+kh 0f+7iZovyzZI2C6IkEDBY5XTLoF2LmnP8APjc56Rns5HjsNXUOqn3BicZj3CAXmI07kf BjzqDnWJRYbO1EjILOH/A7d3dmwo7+exZ34Hc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=YKcR3DgYAQbDbcwpG9bUb82IYFeb0p9YuFCxID7mWs/v7FZY6Z5RMCRymCkryk4Pgi iy8Miw2sncS/Jw1cjSBBmQ/yTZSUe4VZOE7mGjpkD7b5IsMlOwDL/y6kKQKP5qMgoFKl 39yc1lhMccsT+QQSBeSA7FGwqcLH5D1goikNI= MIME-Version: 1.0 Received: by 10.239.182.163 with SMTP id q35mr634778hbg.70.1259707359009; Tue, 01 Dec 2009 14:42:39 -0800 (PST) In-Reply-To: <20091201174417.GM71984@shinkuro.com> References: <4e9b16b30912010934n1077ddb4n6361df098d2ba00d@mail.gmail.com> <20091201174417.GM71984@shinkuro.com> Date: Tue, 1 Dec 2009 23:42:38 +0100 Message-ID: <4e9b16b30912011442i7ea67163w5a89400bc1d17f08@mail.gmail.com> From: Patrick Suger To: internet users contributing group Content-Type: multipart/alternative; boundary=001485f5eda8a79b490479b27902 Subject: [iucg] Fwd: Jefsey's disciples 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, 01 Dec 2009 22:42:51 -0000 --001485f5eda8a79b490479b27902 Content-Type: text/plain; charset=ISO-8859-1 a very nice response from Andrew Sullivan ---------- Forwarded message ---------- From: Andrew Sullivan Date: 2009/12/1 Subject: Re: Jefsey's disciples To: Patrick Suger Cc: Lisa Dusseault , Vint Cerf I've taken the list addresses out because I think the lists have enough on-topic traffic. But you should feel free to forward this wherever you want. On Tue, Dec 01, 2009 at 06:34:06PM +0100, Patrick Suger wrote: > I am surprised by this. I assumed the target was to assess the technical > consensus in accepting to characters as PVALID. No to discriminate a > consensus on people's opinions. My apologies if you read what I wrote as somehow discriminatory. I was simply observing that there was in fact a proposal, which seemed to come from Jefsey and some people who appear more often than not to agree with him, to try to tag labels as being "in a language". I consider that effort to be wrong-headed, and I've argued why in the past; but my point was to set that discussion aside, because it is totally irrelevant to the point I was trying to make. As to discipleship, I'm happy to call you whatever you wish, except that I always get the descriptions wrong. But I do apologise if I offended you, since that was by no means my goal. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --001485f5eda8a79b490479b27902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable a very nice response from Andrew Sullivan


---------- Forwarded message ----------
From: Andrew Sullivan <ajs@shinkuro.com>
Date: 2009/12/1
Subject: Re: Jefsey's disciples
To: Patrick Suger= <psuger@gmail.com>
Cc: Li= sa Dusseault <lisa.dusseault= @gmail.com>, Vint Cerf <vint@g= oogle.com>


I've taken the list addresses out because I think the lists hav= e
enough on-topic traffic. =A0But you should feel free to forward this
wherever you want.

On Tue, Dec 01, 2009 at 06:34:06PM +0100, Patrick Suger wrote:

> I am surprised by this. I assumed the target was to assess the technic= al
> consensus in accepting to characters as PVALID. No to discriminate a > consensus on people's opinions.

My apologies if you read what I wrote as somehow discriminatory. =A0I=
was simply observing that there was in fact a proposal, which seemed
to come from Jefsey and some people who appear more often than not to
agree with him, to try to tag labels as being "in a language". = =A0I
consider that effort to be wrong-headed, and I've argued why in the
past; but my point was to set that discussion aside, because it is
totally irrelevant to the point I was trying to make.

As to discipleship, I'm happy to call you whatever you wish, except
that I always get the descriptions wrong.

But I do apologise if I offended you, since that was by no means my goal.
Best regards,

Andrew

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

--001485f5eda8a79b490479b27902-- From psuger@gmail.com Tue Dec 1 14:43:30 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 38F7C3A6840 for ; Tue, 1 Dec 2009 14:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PvcFKEr+dTOP for ; Tue, 1 Dec 2009 14:43:29 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id A092C3A6916 for ; Tue, 1 Dec 2009 14:43:28 -0800 (PST) Received: by fxm5 with SMTP id 5so5526785fxm.28 for ; Tue, 01 Dec 2009 14:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=pTc2nP6CoM9jy7MhjPd1Fspc9aC5/IfGOvTVrVP8Oyc=; b=ZhMWNyCdovBBMIcv/gC34CHUyfZVtDbmlb5AHh6WSnYsHOsfgMclDJr6LqU32CBoXp QvuC+/L3i6LgdzKaVtQUrbe68/KjwqmlF8hH3hj7Vs7sDPPbAM7ePi/RbmbpXTADI7cc VVgBF35bGToxrDfKFy/WjrkDJ9vhz9P5ePR2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ZDB4cmdkHLhSoCh8w5ravrbAXesvCTI80Nj4Qk3610rEI+9aba0780IDlnE1x+NDd4 CzixeK1Vl5976AQv1Uzz+2E82K1Zu/Y8dN5yvyzckN8gUkJ5NFRssUE9rjkLhT+UvoJb S5esbCY2SLlF8Cidd9uHgqKGOlSTkZ/XLnHcM= MIME-Version: 1.0 Received: by 10.239.194.137 with SMTP id n9mr683893hbi.15.1259707397609; Tue, 01 Dec 2009 14:43:17 -0800 (PST) In-Reply-To: <4e9b16b30912011204ka9f4164ld74b9bcd68e43462@mail.gmail.com> References: <4e9b16b30912010934n1077ddb4n6361df098d2ba00d@mail.gmail.com> <20091201174417.GM71984@shinkuro.com> <4e9b16b30912011204ka9f4164ld74b9bcd68e43462@mail.gmail.com> Date: Tue, 1 Dec 2009 23:43:17 +0100 Message-ID: <4e9b16b30912011443y4e2d4a83hba29fca60d7ddb8a@mail.gmail.com> From: Patrick Suger To: internet users contributing group Content-Type: multipart/alternative; boundary=001485eb935df4988b0479b27bf5 Subject: [iucg] Fwd: Jefsey's disciples 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, 01 Dec 2009 22:43:30 -0000 --001485eb935df4988b0479b27bf5 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: Patrick Suger Date: 2009/12/1 Subject: Re: Jefsey's disciples To: Andrew Sullivan Cc: Lisa Dusseault , Vint Cerf Dear Andrew, Sorry, I was not hurt, but dismayed. You IETF people do obviously not undestand what we try to tell you and who we are. We tried, probably clumsily, to tell it to you in your own words. Now, we have agreed with Jefsey (again, but he is pushing naming for 30 years, so ...) the only solution is to _show_ it to you. These are the Multilinc, .FRA and .PERFIDA projects (25.000 TLDs). We know what we do is a possible mess. But better us than Russian mafia or American breakers. How to learn if we do not test interplus. So we test Jefsey's config. Don't ask me the detail, I am no techie. But this means that I sail my totally independent cybship. No root server, no ISP nameserver. No need for DNSSEC. No cache. We have scores of test TLDs, in tenth of classes, using plenty of different presentations. At no cost. No one being able to hack us. This just using plain off the shelves BIND software. Under Linux and Windows. And Jesey's MYCANN test files. I am afraid what you do not understand is that we are not techies, just users. May be smart users, but there certainly are smarter than us around, with another agenda than just using the internet better. I will be candid: we do consider you as pretty well outdated in the way you use, admin and govern of your own technology! This is why we worry: you did not consider the way everyone can freely start living in a no-ICANN, no root server system, no unique root file Internet in using your own tools. So , you did not consider how to protect us from all the dangers the use of your own protocols and tools may expose us to. We identified Interplus is the same for naming, IPv6 and economy as NATs are for addressing. Except that you are those who developped it. And it still works the same all over. This is why we really are embarassed because obviously you do not understand it. And we think we got/are a real problem! Best Patrick Suger 2009/12/1 Andrew Sullivan I've taken the list addresses out because I think the lists have > enough on-topic traffic. But you should feel free to forward this > wherever you want. > > On Tue, Dec 01, 2009 at 06:34:06PM +0100, Patrick Suger wrote: > > > I am surprised by this. I assumed the target was to assess the technical > > consensus in accepting to characters as PVALID. No to discriminate a > > consensus on people's opinions. > > My apologies if you read what I wrote as somehow discriminatory. I > was simply observing that there was in fact a proposal, which seemed > to come from Jefsey and some people who appear more often than not to > agree with him, to try to tag labels as being "in a language". I > consider that effort to be wrong-headed, and I've argued why in the > past; but my point was to set that discussion aside, because it is > totally irrelevant to the point I was trying to make. > > As to discipleship, I'm happy to call you whatever you wish, except > that I always get the descriptions wrong. > > But I do apologise if I offended you, since that was by no means my goal. > > Best regards, > > Andrew > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > --001485eb935df4988b0479b27bf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: Patrick Suger = <psuger@gmail.com>
= Date: 2009/12/1
Subject: Re: Jefsey's disciples
To: Andrew Sullivan <ajs@shinkuro.com>
Cc: Lisa Dusseault <= lisa.dusseault@gmail.com>= ;, Vint Cerf <vint@google.com>=


Dear Andrew,

Sorry, I was not hurt, but dismayed.=A0
You IETF people do obviously not undestand what we try to tell you and who = we are. We tried, probably clumsily, to tell it to you in your own words. N= ow, we have agreed with Jefsey (again, but he is pushing naming for 30 year= s, so ...) the only solution is to _show_ it to you. These are the Multilin= c, .FRA and .PERFIDA projects (25.000 TLDs). We know what we do is a possib= le mess. But better us than Russian mafia or American breakers. How to lear= n if we do not test interplus. So we test Jefsey's config. Don't as= k me the detail, I am no techie.

But this means that I sail my totally independent cybship. No root server, = no ISP nameserver. No need for DNSSEC. No cache. We have scores of test TLD= s, in tenth of classes, using plenty of different presentations. At no cost= . No one being able to hack us. This just using plain off the shelves BIND = software. Under Linux and Windows. And Jesey's MYCANN test files.

I am afraid what you do not understand is that we are not techies, just use= rs. May be smart users, but there certainly are smarter than us around, wit= h another agenda than just using the internet better. I will be candid:=A0 = we do consider you as pretty well outdated in the way you use, admin and go= vern of your own technology!=A0 This is why we worry: you did not consider = the way everyone can freely start living in a no-ICANN, no root server syst= em, no unique root file Internet in using your own tools. So , you did not = consider how to protect us from all the dangers the use of your own protoco= ls and tools may expose us to.

We identified Interplus is the same for naming, IPv6 and economy as NATs ar= e for addressing. Except that you are those who developped it. And it still= works the same all over.

This is why we really are embarassed because obviously you do not understan= d it.=A0 And we think we got/are a real problem!
Best

Patrick Suger

2009/12/1 Andrew Sullivan <= span dir=3D"ltr"><= ajs@shinkuro.com>

I've taken the list addresses out because I think the lists have
enough on-topic traffic. =A0But you should feel free to forward this
wherever you want.

On Tue, Dec 01, 2009 at 06:34:06PM +0100, Patrick Suger wrote:

> I am surprised by this. I assumed the target was to assess the technic= al
> consensus in accepting to characters as PVALID. No to discriminate a > consensus on people's opinions.

My apologies if you read what I wrote as somehow discriminatory. =A0I=
was simply observing that there was in fact a proposal, which seemed
to come from Jefsey and some people who appear more often than not to
agree with him, to try to tag labels as being "in a language". = =A0I
consider that effort to be wrong-headed, and I've argued why in the
past; but my point was to set that discussion aside, because it is
totally irrelevant to the point I was trying to make.

As to discipleship, I'm happy to call you whatever you wish, except
that I always get the descriptions wrong.

But I do apologise if I offended you, since that was by no means my goal.
Best regards,

Andrew

--
Andrew Sullivan
ajs@shinkuro.com<= br> Shinkuro, Inc.


--001485eb935df4988b0479b27bf5-- From psuger@gmail.com Tue Dec 1 14:44:29 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 827E53A69CA for ; Tue, 1 Dec 2009 14:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, 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 xysPINua3SCN for ; Tue, 1 Dec 2009 14:44:28 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 2F5B43A6916 for ; Tue, 1 Dec 2009 14:44:28 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e21so52596fga.13 for ; Tue, 01 Dec 2009 14:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=gUDzjBcxA+BBxxnYDST8hVqdtacQ7lTB2rIFB6aJVy0=; b=Qc3DFjZkW8G7vKqPM3rhfmS3eDGeFlOilkW8DaGLSDGezqilzLLZHNx/sjKH2Xf28a NWTQGTL9koKJml1KDC3NoVnzk7FXHO7W/od/Qg7pPCbKbL2Qiq82L2azsSJfTsEbn4ak 6kB9EEz8DsUDFEB7EWMPUEbPjUPi1Dn0Hk4tQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=oRQRqEwUn5kbps4HLwrkAPKlQWulX2nksr5OsNXmEjVvXZ5E1aBHTUEbUPgr7awccP 5zWaYDsgkpmgFFWNCWtJfPr4l+wT/en7+Fp6KX5smJPDidPHvkV8m7KHu+xfvTs/v7SA SSgqRLcW5kUPu1GmuOx6EGvKVv4n7Gv0O3qRM= MIME-Version: 1.0 Received: by 10.239.196.130 with SMTP id v2mr609868hbi.207.1259707460263; Tue, 01 Dec 2009 14:44:20 -0800 (PST) In-Reply-To: <20091201200925.GX71984@shinkuro.com> References: <4e9b16b30912010934n1077ddb4n6361df098d2ba00d@mail.gmail.com> <20091201174417.GM71984@shinkuro.com> <4e9b16b30912011204ka9f4164ld74b9bcd68e43462@mail.gmail.com> <20091201200925.GX71984@shinkuro.com> Date: Tue, 1 Dec 2009 23:44:20 +0100 Message-ID: <4e9b16b30912011444s64df63d1q884c75df5e88923f@mail.gmail.com> From: Patrick Suger To: internet users contributing group Content-Type: multipart/alternative; boundary=00c09feaf271b09ff80479b27fe1 Subject: [iucg] Fwd: Jefsey's disciples 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, 01 Dec 2009 22:44:29 -0000 --00c09feaf271b09ff80479b27fe1 Content-Type: text/plain; charset=ISO-8859-1 Sorry we misunderstood. A decent person. ---------- Forwarded message ---------- From: Andrew Sullivan Date: 2009/12/1 Subject: Re: Jefsey's disciples To: Patrick Suger Cc: Lisa Dusseault , Vint Cerf On Tue, Dec 01, 2009 at 09:04:30PM +0100, Patrick Suger wrote: > You IETF people do obviously not undestand what we try to tell you and who > we are. Well, now it's my turn to be dismayed ;-) I don't know who "we IETF people" are, except for those who participate in the mailing lists. That's all there is to it. The rest of it is noise: decisions taken at face to face meetings are supposed to be confirmed on the list (as they have been in this case, IMO). There are no protocol police, as you are discovering by performing your experiments. Nobody has come to knock on your virtual door, and nobody will. > But this means that I sail my totally independent cybship. No root server, > no ISP nameserver. No need for DNSSEC. No cache. We have scores of test > TLDs, in tenth of classes, using plenty of different presentations. At no > cost. No one being able to hack us. This just using plain off the shelves > BIND software. Under Linux and Windows. And Jesey's MYCANN test files. I'm glad you think this works. But the IETF is about _inter_operation, and your configuration won't work to allow me to interoperate with you, and conversely. That's the objection you've heard. But this is way off-topic for what we were discussing. I wish you luck with your experiments, and look forward to the report of how it goes. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --00c09feaf271b09ff80479b27fe1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry we misunderstood.
A decent person.


---------- Forwarded message ----------
From: Andrew Sullivan <ajs@shinkuro.com>
Date: 2009/12/1
Subject: Re: Jefsey's disciples
To: Patrick Suger= <psuger@gmail.com>
Cc: Li= sa Dusseault <lisa.dusseault= @gmail.com>, Vint Cerf <vint@g= oogle.com>


On Tue, Dec 01, 2009 at 09:04:30PM +0100, Patrick= Suger wrote:

> You IETF people do obviously not undestand what we try to tell you and= who
> we are.

Well, now it's my turn to be dismayed ;-) I don't know who &q= uot;we IETF
people" are, except for those who participate in the mailing lists. That's all there is to it. =A0The rest of it is noise: decisions taken<= br> at face to face meetings are supposed to be confirmed on the list (as
they have been in this case, IMO). =A0There are no protocol police, as
you are discovering by performing your experiments. =A0Nobody has come
to knock on your virtual door, and nobody will.

> But this means that I sail my totally independent cybship. No root ser= ver,
> no ISP nameserver. No need for DNSSEC. No cache. We have scores of tes= t
> TLDs, in tenth of classes, using plenty of different presentations. At= no
> cost. No one being able to hack us. This just using plain off the shel= ves
> BIND software. Under Linux and Windows. And Jesey's MYCANN test fi= les.

I'm glad you think this works. =A0But the IETF is about
_inter_operation, and your configuration won't work to allow me to
interoperate with you, and conversely. =A0That's the objection you'= ve
heard.

But this is way off-topic for what we were discussing. =A0I wish you
luck with your experiments, and look forward to the report of how it
goes.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

--00c09feaf271b09ff80479b27fe1-- From psuger@gmail.com Tue Dec 1 14:51: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 3C7703A68D3 for ; Tue, 1 Dec 2009 14:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BYy6UZixM7lV for ; Tue, 1 Dec 2009 14:51:20 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 833083A68E7 for ; Tue, 1 Dec 2009 14:51:17 -0800 (PST) Received: by fxm5 with SMTP id 5so5532865fxm.28 for ; Tue, 01 Dec 2009 14:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=umS+RwxM7npl9WbYAZ+P0pqgZvEztI8wthOmXloiAVc=; b=YssbNzeWLEgg3J5klGM0dBx1MfznkatIzLIzQ8ZBAm/zDkpls8RFyK3Vgsw0GU788p f4mhPoc/jinTAStB4Sqa1OJaSF37aWD0ccNzus4i3iJv5zQkJn7BLkBOG6kVcHbGGYGG Tkx+k8Di3XW4yUkpeOIvEDjFgQ5JDaN6M2dPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=FReqOHi27oaNe9io+YxOuUYs2RZRWahaotcCpp3BGjvhNsH1pgwOH4wT4oLLhm1Nyl 7egu8Ur5SYrN+iPZjxN6IpdACDByi+chs1J/hEObF2zaaX7BSrq9oFL30lNiif3I1eNH IrOmiQi+0zOkSQbUoBsMzVcCMxkAv94gtTTjs= MIME-Version: 1.0 Received: by 10.239.182.163 with SMTP id q35mr635001hbg.70.1259707488348; Tue, 01 Dec 2009 14:44:48 -0800 (PST) In-Reply-To: <4e9b16b30912011432i13482394o252d9c3ac6e63aca@mail.gmail.com> References: <4e9b16b30912010934n1077ddb4n6361df098d2ba00d@mail.gmail.com> <20091201174417.GM71984@shinkuro.com> <4e9b16b30912011204ka9f4164ld74b9bcd68e43462@mail.gmail.com> <20091201200925.GX71984@shinkuro.com> <4e9b16b30912011432i13482394o252d9c3ac6e63aca@mail.gmail.com> Date: Tue, 1 Dec 2009 23:44:48 +0100 Message-ID: <4e9b16b30912011444n242cb49mc434e460832fdc81@mail.gmail.com> From: Patrick Suger To: internet users contributing group Content-Type: multipart/alternative; boundary=001485f5eda85d29080479b2811b Subject: [iucg] Fwd: Jefsey's disciples 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, 01 Dec 2009 22:51:21 -0000 --001485f5eda85d29080479b2811b Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: Patrick Suger Date: 2009/12/1 Subject: Re: Jefsey's disciples To: Andrew Sullivan Cc: Lisa Dusseault , Vint Cerf 2009/12/1 Andrew Sullivan On Tue, Dec 01, 2009 at 09:04:30PM +0100, Patrick Suger wrote: > > > You IETF people do obviously not undestand what we try to tell you and > who > > we are. > > Well, now it's my turn to be dismayed ;-) I don't know who "we IETF > people" are, except for those who participate in the mailing lists. > Dear Andrew, This is what I mean. That's all there is to it. The rest of it is noise: decisions taken > at face to face meetings are supposed to be confirmed on the list (as > they have been in this case, IMO). There are no protocol police, as > you are discovering by performing your experiments. Nobody has come > to knock on your virtual door, and nobody will. > I am afraid there is some confusion. I talk of your common culture. The way you approach the network architecture. Basically RFC 3935 being taken as a Gospel and not as a non unique Charter. We understand you as well. No problem. But you seem only to understand one another, not to be interested in understanding us. And we are at loss knowing what to do. > > > But this means that I sail my totally independent cybship. No root > server, > > no ISP nameserver. No need for DNSSEC. No cache. We have scores of test > > TLDs, in tenth of classes, using plenty of different presentations. At no > > cost. No one being able to hack us. This just using plain off the shelves > > BIND software. Under Linux and Windows. And Jesey's MYCANN test files. > > I'm glad you think this works. But the IETF is about > _inter_operation, and your configuration won't work to allow me to > interoperate with you, and conversely. That's the objection you've > heard. > We do not think it works. We see it works, we use it. We have no problem to fully interface with everyone you interface. But are not bound to only interface them, or to interface them in your way. We also can interface them in our mutually agreed way when you do not support it. > But this is way off-topic for what we were discussing. I wish you > luck with your experiments, and look forward to the report of how it > goes. > Certainly this is our intent. This is why we joined the IUCG. However, we just are users with our own life. Not specialised academics nor paid employees. We could do with seome help. Take care. Patrick --001485f5eda85d29080479b2811b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: Patrick Suger = <psuger@gmail.com>
= Date: 2009/12/1
Subject: Re: Jefsey's disciples
To: Andrew Sullivan <ajs@shinkuro.com>
Cc: Lisa Dusseault <= lisa.dusseault@gmail.com>= ;, Vint Cerf <vint@google.com>=


2009/12/1 Andrew Sullivan <ajs@shinkuro.= com>

On Tue, Dec 01, 2009 at 09:04:30PM +0100, Patrick Suger wrote:

> You IETF people do obviously not undestand what we try to tell you and= who
> we are.

Well, now it's my turn to be dismayed ;-) I don't know who &q= uot;we IETF
people" are, except for those who participate in the mailing lists.

Dear Andrew,
This is what I mean.

<= /div>
That's all there is to it. =A0The rest of it is noise: decisions taken<= br> at face to face meetings are supposed to be confirmed on the list (as
they have been in this case, IMO). =A0There are no protocol police, as
you are discovering by performing your experiments. =A0Nobody has come
to knock on your virtual door, and nobody will.
=A0
I am afraid there is some confusion. I talk of your common culture= . The way you approach the network architecture. Basically RFC 3935 being t= aken as a Gospel and not as a non unique Charter. We understand you as well= . No problem. But you seem only to understand one another, not to be intere= sted in understanding us. And we are at loss knowing what to do.

=A0

> But this means that I sail my totally independent cybship. No root ser= ver,
> no ISP nameserver. No need for DNSSEC. No cache. We have scores of tes= t
> TLDs, in tenth of classes, using plenty of different presentations. At= no
> cost. No one being able to hack us. This just using plain off the shel= ves
> BIND software. Under Linux and Windows. And Jesey's MYCANN test fi= les.

I'm glad you think this works. =A0But the IETF is about
_inter_operation, and your configuration won't work to allow me to
interoperate with you, and conversely. =A0That's the objection you'= ve
heard.

=A0
We do not think it works. We= see it works, we use it. We have no problem to fully interface with everyo= ne you interface. But are not bound to only interface them, or to interface= them in your way. We also can interface them in our mutually agreed way wh= en you do not support it.=A0

=A0
But = this is way off-topic for what we were discussing. =A0I wish you
luck with your experiments, and look forward to the report of how it
goes.

Certainly this is our intent. This is why w= e joined the IUCG. However, we just are users with our own life. Not specia= lised academics nor paid employees. We could do with seome help.

Take care.


Patrick

--001485f5eda85d29080479b2811b-- From eblanconil@gmail.com Wed Dec 2 00:32:31 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 155583A6908 for ; Wed, 2 Dec 2009 00:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, 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 zgVrRkit7XED for ; Wed, 2 Dec 2009 00:32:30 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 0F4103A67E5 for ; Wed, 2 Dec 2009 00:32:00 -0800 (PST) Received: by ewy6 with SMTP id 6so775710ewy.29 for ; Wed, 02 Dec 2009 00:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=rtMSFib02EaDmSqeePcglIA0+aEjNPFidHkIXQro9t4=; b=YeXZBCtW7vS1JWKajyLwK6XGpDP3CFs7P4hIrHrnERvf9NcnTr3qNPvyGTBCkXkFpv VcJxXNP1aOdgv3xN1O4602CANIfA+ztcyhKcYahUsXwL7IKqVE+rtthTOZRoqX6Ahjuv jtFF7Rwl4ObNj5Ky7bqta7Qoa8ESaqzVLimCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=EtsXw0fB8Pei515h0Ydpksgp88vBEhY/GRo94tYx3KdpXi6x119Sr9RTaFQftpYoez fNk9AMPZGxWS0d9rMkL0uQPm/eiCIVdv442vBXRrSISopRXfW/wdfx4SanRr5wHHw3oQ mrB5RMRyj92p8cXt+dmACeJRa6nrSPf+s1sIQ= MIME-Version: 1.0 Received: by 10.216.90.209 with SMTP id e59mr2232011wef.193.1259742710115; Wed, 02 Dec 2009 00:31:50 -0800 (PST) In-Reply-To: <6589127a0912020030g27b5cb8cua20ecdc4924198a7@mail.gmail.com> References: <137F0BCC-E292-4470-916B-D9D411EF43F7@frobbit.se> <8BC845943058D844ABFC73D2220D466508B5A06C@nics-mail.sbg.nic.at> <4b13eafd.1701d00a.1ee7.ffffdeb8@mx.google.com> <30b660a20911301001p26b4fd38s1ad803d8d0fcf89e@mail.gmail.com> <4b152c06.0702d00a.5fec.602c@mx.google.com> <30b660a20912011202y37f7c8ew5e83383e12712747@mail.gmail.com> <4b157aff.0f67f10a.2590.28fb@mx.google.com> <6589127a0912020030g27b5cb8cua20ecdc4924198a7@mail.gmail.com> Date: Wed, 2 Dec 2009 09:31:50 +0100 Message-ID: <6589127a0912020031v66c80933t4212f6509255838@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: multipart/alternative; boundary=0016e6d7e363beace30479bab446 Subject: [iucg] Fwd: AW: Mappings - some examples 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, 02 Dec 2009 08:32:31 -0000 --0016e6d7e363beace30479bab446 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: Elisabeth Blanconil Date: 2009/12/2 Subject: Re: AW: Mappings - some examples To: Patrik F=C3=A4ltstr=C3=B6m Cc: Georg Ochsner , Alexander Mayrhofer < alexander.mayrhofer@nic.at>, Mark Davis =E2=98=95 , IDN= A update work , Andreas St=C3=B6tzner , Michael Everson 2009/12/2 Patrik F=C3=A4ltstr=C3=B6m Google already today "correct" my spellings in a way so that it is > increasingly (yes, it is getting worse) hard to search for words that are > correctly spelled in Swedish, but Google think it is a misspelling in > English. > > I have wanted for some time an ability to turn off Googles "help" ;-) > oh! YES !!!!! Patrik, Same in French. One has to become a "LeGogoBingo" professional when one really wants to use search engines. It is good training for semantic addressing. LeGogoBingo's value added spelling makes it more and more difficult to find something precise. Now, the point we discuss today is to know if we want IDNA to be LeGogoBing= o (Vint, Harald, Keneth, Mark and Shawn) compatible. Keneth explained it woul= d now be too costly for them to "upgrade". We consensually said "no", so they need to make us consensually say "yes". IMHO, they should really explain their problem in basic technical requirements. Even it was biased to ask engineers from Unicode, Vint wrote to an IBM engineer. Anyway, we believe we did find a good solution (interplus). We start testin= g it. However it will take time as we only are users, have no lab and budget, speak another language (BTW this is probably why we MUST have a solution). We, also, have other things to do in life. However we are no fool either: engineers could come with other/better solution if they were clearly explained technical requirements rather than to try to become hearsays linguists. We have very good linguists among "Jefsey disciples" : we try to make them think as users. Elisabeth Blanconil. --0016e6d7e363beace30479bab446 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: Elisabeth Blanconil <eblanconil@gmail.com&= gt;
Date: 2009/12/2
Subject: Re: AW: Mappings - some examples
To: Patrik = F=C3=A4ltstr=C3=B6m <patrik@frobbit= .se>
Cc: Georg Ochsner <g.ochsner@revolistic.com>, Alexander Mayrhofer <alexander.mayrhofer@nic.at>, Mark= Davis =E2=98=95 <mark@macchiato.c= om>, IDNA update work <idna-update@alvestrand.no>, Andreas St=C3=B6tzner <a.stoetzner@t-online.de>, Michael Ev= erson <everson@evertype.com&= gt;

2009/12/2 Patrik F=C3=A4ltstr=C3=B6m <patri= k@frobbit.se>

Google already today "correct" my s= pellings in a way so that it is increasingly (yes, it is getting worse) har= d to search for words that are correctly spelled in Swedish, but Google thi= nk it is a misspelling in English.

I have wanted for some time an ability to turn off Goog= les "help" ;-)

=
oh! YES !!!!!


Patrik,

Same in French. One has to become a "LeGogoBingo" professional wh= en one really wants to use search engines. It is good training for semantic= addressing. LeGogoBingo's value added spelling makes it more and more = difficult to find something precise.

Now, the point we discuss today is to know if we want IDNA to be LeGogoBing= o (Vint, Harald, Keneth, Mark and Shawn) compatible. Keneth explained it wo= uld now be too costly for them to "upgrade". We consensually said= "no", so they need to make us consensually say "yes". = IMHO, they should really explain their problem in basic technical requireme= nts. Even it was biased to ask engineers from Unicode, Vint wrote to an IBM= engineer.

Anyway, we believe we did find a good solution (interplus). We start testin= g it. However it will take time as we only are users, have no lab and budge= t, speak another language (BTW this is probably why we MUST have a solution= ). We, also, have other things to do in life. However we are no fool either= : engineers could come with other/better solution if they were clearly expl= ained technical requirements rather than to try to become hearsays linguist= s. We have very good linguists among "Jefsey disciples" : we try = to make them think as users.

Elisabeth Blanconil.


--0016e6d7e363beace30479bab446-- From vesely@tana.it Wed Dec 2 02:36:19 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 835B03A68ED for ; Wed, 2 Dec 2009 02:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 MzHjxX8KqWOO for ; Wed, 2 Dec 2009 02:36:18 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 8F42E3A67A4 for ; Wed, 2 Dec 2009 02:36:18 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 02 Dec 2009 11:36:09 +0100 id 00000000005DC037.000000004B164319.00000ECD Message-ID: <4B164319.7040508@tana.it> Date: Wed, 02 Dec 2009 11:36:09 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: internet users contributing group References: <137F0BCC-E292-4470-916B-D9D411EF43F7@frobbit.se> <8BC845943058D844ABFC73D2220D466508B5A06C@nics-mail.sbg.nic.at> <4b13eafd.1701d00a.1ee7.ffffdeb8@mx.google.com> <30b660a20911301001p26b4fd38s1ad803d8d0fcf89e@mail.gmail.com> <4b152c06.0702d00a.5fec.602c@mx.google.com> <30b660a20912011202y37f7c8ew5e83383e12712747@mail.gmail.com> <4b157aff.0f67f10a.2590.28fb@mx.google.com> <6589127a0912020030g27b5cb8cua20ecdc4924198a7@mail.gmail.com> <6589127a0912020031v66c80933t4212f6509255838@mail.gmail.com> In-Reply-To: <6589127a0912020031v66c80933t4212f6509255838@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [iucg] Fwd: AW: Mappings - some examples 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, 02 Dec 2009 10:36:19 -0000 Elisabeth Blanconil wrote: > 2009/12/2 Patrik Fältström > > > Google already today "correct" my spellings in a way so that it is > increasingly (yes, it is getting worse) hard to search for words > that are correctly spelled in Swedish, but Google think it is a > misspelling in English. > > Same in French. One has to become a "LeGogoBingo" professional when one > really wants to use search engines. It is good training for semantic > addressing. LeGogoBingo's value added spelling makes it more and more > difficult to find something precise. > > Now, the point we discuss today is to know if we want IDNA to be > LeGogoBingo (Vint, Harald, Keneth, Mark and Shawn) compatible. One limitation results from the "application/x-www-form-urlencoded" type provided by HTML. User's input arrives to Google with no indication whatsoever about language and character set. (Googling for "iconv c3a4e284a2c2ae" one can find various explanation of a technique currently used to determine if the character set sent by the browser is UTF-8. No clue for the language, obviously.) > Anyway, we believe we did find a good solution (interplus). The other HTML form type, multipart/form-data, provides for header fields that might be used to specify the language. Since it is not urlencoded, it is primarily used with the POST method, and often only for forms that upload files. The situation looks similar for HTML5 http://www.w3.org/TR/html5/forms.html#attributes-for-form-submission I'm unable to devise how on the Earth a server can make reliable assumptions about the language that a user submits, because I could google for "confounded déjoué"... -- I came upon a wedding that old families had contrived; Bethlehem the bridegroom, Babylon the bride. [L. Cohen, Last Year's Man] From jefsey@jefsey.com Wed Dec 2 12:25:19 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 C47353A690A for ; Wed, 2 Dec 2009 12:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-0.480, 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 b1I2pujykcsk for ; Wed, 2 Dec 2009 12:25:18 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id E47BD3A6829 for ; Wed, 2 Dec 2009 12:25:18 -0800 (PST) Received: from 89-158-60-65.rev.dartybox.com ([89.158.60.65]:4778 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NFvkk-0000UA-HH; Wed, 02 Dec 2009 12:24:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 Dec 2009 21:24:43 +0100 To: Lisa Dusseault , Andrew Sullivan , "john+ietf@jck.com" , "Vint Cerf" , "Michel SUIGNARD" , From: jefsey In-Reply-To: References: <20091202192616.GQ75004@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091202202518.E47BD3A6829@core3.amsl.com> Cc: iucg@ietf.org, arabic Scripts IDNA Subject: Re: [iucg] Bundling 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, 02 Dec 2009 20:25:19 -0000 At 20:35 02/12/2009, Lisa Dusseault wrote: >I don't see where that principle begins and ends. If it were >entirely true, zone operators would be entirely free to register >xn--garbage as a domain, entirely free to register DISALLOWED characters. > >Since it is in the purview of IDNA designers to make a character >valid or disallowed, wouldn't also be in the purview of IDNA >designers to say something like "This character becomes valid on >date 01/01/2020", right? So why wouldn't it be in the purview of >IDNA designers to also say something like "This character becomes >fully valid on date 01/01/2020, but until then, may be registered if >it is bundled with another sequence"? > >Doncha love slippery slopes :) Lisa, I do hope this is a joke. But this is a very bad one. This kind of questions after an IETF/LC on a key document for the world by the IESG Member in charge sounds like a pure destruction of the IETF credibility. Because the principle precisely begins and ends with the authority of the IETF Applications Area AD. The entire Internationalised Internet construct is based upon the people's trust that others' will trust the IETF will NEVER say what you say, but that the IETF will make every effort as per its mission to keep its whole set of documents (RFC) fully interoperable with the existing human languages, so the Internet works better. IDNA2003 was NOT interoperable enough with human languages because it was too rigid and "unique". IDNA2008 brought far more flexibility and has proven to be nearly adequate, except on a few points that IDNA2010 will have to address based upon experience, the most important one architecturally wise being the French Majuscules. So, if this is not a joke, I am afraid you got the story deadly wrong. It certainly NOT is in the purview of IDNA designers to make a character pvalid or disallowed, it is their responsibility to permit users to sensibly use the internet in their own language, without confusion, without phishing, in researching if - in their model and according to people, linguists, governements - a character may usually qualify as DISALLOWED or PVALID. And what do they advise to do in such occurences, being respected the authority of the zone manager and of the users, as well as the specificities of the considered sociolinguistic environment. We are certainly not liking slippery slopes when the world stability and the IETF credibility are at stake. Sorry if I misread your mail. But I have increasing difficulties understanding the purpose of this whole set of threads you made introduced. jfc From jefsey@jefsey.com Fri Dec 4 13:31:15 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 85D773A6949 for ; Fri, 4 Dec 2009 13:31:15 -0800 (PST) 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 ZYiECylkwruD for ; Fri, 4 Dec 2009 13:31:14 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 92F2B3A689B for ; Fri, 4 Dec 2009 13:31:14 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1781 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGfjw-0004TY-SG; Fri, 04 Dec 2009 13:31:01 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Dec 2009 20:38:25 +0100 To: Andrew Sullivan From: JFC Morfin In-Reply-To: <20091204134724.GB91905@shinkuro.com> References: <24DA8FCE39E14E40BBAF227CC0B2AF47@ics.forth.gr> <151D2BEC-DF26-4A78-916A-5BDE881B0F77@google.com> <20091204134724.GB91905@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091204213114.92F2B3A689B@core3.amsl.com> Cc: workon@idna2010.org, iucg@ietf.org Subject: Re: [iucg] Bundling of Domain Names and DNAME 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, 04 Dec 2009 21:31:15 -0000 +1 And this is why we just decided to initiate workon@IDNA2010.org now. I wanted to wait for the IESG to have approved the final IDNA2008 text. But obviously Lisa's position amounts to IESG refusing the IDNA concept the WG worked out. So we need IDNA2010, and we need fast if not to give an unfair advantage to Google DNS on the network, the business, the ISP market and try to prevent a DNS war with Microsoft which would definitly kill any DNS innovation/extension for another 25 years. In the long term Unicode, Google, ICANN, Microsoft competition for IANA control we took the Internet Users side a long ago (the debate over RFC 4646). Today, we have a real, validate and working concept which showes we need _none_ of them to navigate the internet more safely, more securely, faster and cheaplier. However, I acknowledge Vint's move is brillant. It was expected at this very date, but I acknowledge it was not expected this way. So, we certainly are still really too small. But, on another side, this should help weak to strong advertising for Interplus, because it already works. jfc At 14:47 04/12/2009, Andrew Sullivan wrote: >On Fri, Dec 04, 2009 at 08:36:50AM -0500, Vint Cerf wrote: > > Vaggelis, > > > > extensions of DNS in the XNAME direction would require creation of a > > new WG for this purpose. > >It wouldn't require a new WG: that's exactly what DNSEXT exists for. >So I think that's why Vaggelis has sent a note to namedroppers. It'd >probably make sense to take that topic over there and leave idnabis >out of the discussion, since the reason for the extension (mirroring >part of a tree to do DNS variants) is just one of the possible uses of >such a mechanism, were it possible to design it safely. (For the same >reason, I send this only to the idnabis list, and not to that of >dnsext.) > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From jefsey@jefsey.com Fri Dec 4 13:31:17 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 5750C28C0F2 for ; Fri, 4 Dec 2009 13:31:17 -0800 (PST) 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 5TSwmndzIbS2 for ; Fri, 4 Dec 2009 13:31:16 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 647FF3A6A05 for ; Fri, 4 Dec 2009 13:31:16 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1780 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGfk0-0004TX-Bz; Fri, 04 Dec 2009 13:31:04 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Dec 2009 21:31:40 +0100 To: iucg@ietf.org,workon@idna2010.org From: jefsey In-Reply-To: <4B1933F4.9010809@abenaki.wabanaki.net> References: <4B1933F4.9010809@abenaki.wabanaki.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091204213116.647FF3A6A05@core3.amsl.com> Cc: Eric Brunner-Williams Subject: Re: [iucg] On graphs and equivalences 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, 04 Dec 2009 21:31:17 -0000 An honnest example of the difficulty for a network engineer to address user needs without proper users specs and a usage middleware. jfc At 17:08 04/12/2009, Eric Brunner-Williams wrote: >The assertion that in Script X a casing property is required to form >persistent resource identifiers appears to be an assumption present in > Vaggelis' note on the desirability of an aliasing mechanism between >two or more directed acyclic subgraphs existing in one or more root >server entries. > >This assertion does not appear to have been proved, and it appears to >be a special case of a requirement to define equivalence classes for >characters, or their sequences, and necessarily any subgraphs anchored >from the nodes where elements of the equivalence classes exist. > >An approach, "intermediate tables", was proposed in-protocol during >the course of the IDN WG. The proposal was not adopted and was not >incorporated in the IDNA2003 specifications. > >Another specification, published as RFC 3743, Joint Engineering Team >(JET) Guidelines for Internationalized Domain Names (IDN) Registration >and Administration for Chinese, Japanese, and Korean, proposed a >solution not dependent upon the correct functioning of the IDNA2003 >protocol. > >I lack the subject matter expertise to form an opinion on the >necessity claim for tonos-free repertoire ("upper case") for the >meaningful formation of resource identifiers, and therefore the >necessity to form character equivalence classes. > >If the necessity claim arises from "words", then it suffers the same >defect that the claims made for other "word properties", in that they >are out of scope for a working group engaged in the specification of >persistent resource identifiers. > >Eric >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From jefsey@jefsey.com Fri Dec 4 13:31:20 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 75B6E3A6949 for ; Fri, 4 Dec 2009 13:31:20 -0800 (PST) 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 A9fRBCh-tkxD for ; Fri, 4 Dec 2009 13:31:19 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id DBB3328C0FF for ; Fri, 4 Dec 2009 13:31:18 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1781 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGfk1-0004TY-Ii; Fri, 04 Dec 2009 13:31:06 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Dec 2009 21:25:36 +0100 To: Eric Brunner-Williams , Erik van der Poel From: JFC Morfin In-Reply-To: <4B1932F6.5070903@abenaki.wabanaki.net> References: <20091203174807.GF85534@shinkuro.com> <8BC845943058D844ABFC73D2220D466508C0054D@nics-mail.sbg.nic.at> <4B1932F6.5070903@abenaki.wabanaki.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091204213118.DBB3328C0FF@core3.amsl.com> Cc: workon@idna2010.org, iucg@ietf.org Subject: Re: [iucg] Additional thoughts on TRANSITIONAL 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, 04 Dec 2009 21:31:20 -0000 +1 At 17:04 04/12/2009, Eric Brunner-Williams wrote: >Cary's letting you off easy. > >Erik van der Poel wrote: > > > PVALID (or CONTEXTJ for 200C/200D). We encourage ICANN to redelegate > > TLDs the registries of which flout our rules. > > >In 25 words or less, explain RFC 2826. > >For extra credit, list the root constellations and the scripts present >in each root and the populations each currently serve. You may use >public registration data as of Q209. > >For extra extra credit, list the scripts and their markets where >mechanisms independent of root constellation offers pervasive support >for scripts other than Latin. Again, You may use public registration >data as of Q209. > >If you were anywhere near the Pitcarin Island, or the Iraq redel >fiascos, you'd be cautious, or wear gloves, and watching you make a >"flout our rules" presentation to the GAC would be entertaining, along >the lines of watching the EU's rep attempt to nail the version of >Unicode used by IDNAbis into a normative GAC text. > >Eric >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From jefsey@jefsey.com Fri Dec 4 14:17:38 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 A3C623A694D for ; Fri, 4 Dec 2009 14:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.381, 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 FtuO6+B+nuMz for ; Fri, 4 Dec 2009 14:17:36 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 444B83A6970 for ; Fri, 4 Dec 2009 14:17:36 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1781 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGfk3-0004TY-UM; Fri, 04 Dec 2009 13:31:08 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Dec 2009 21:28:20 +0100 To: Kim Davies ,Cary Karp , Erik van der Poel From: JFC Morfin In-Reply-To: References: <4B192B68.8060304@nic.museum> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091204221736.444B83A6970@core3.amsl.com> Cc: workon@idna2010.org, iucg@ietf.org Subject: Re: [iucg] Additional thoughts on TRANSITIONAL 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, 04 Dec 2009 22:17:38 -0000 I suggest we add a government section in the IDNA2010 list of topics. This mail could be a good starting point. Cary representing reality, Kim representing ICANN's illusions and hopes. Target: is there a way to conciliate them to the Best Interner Users benefit? jfc At 17:04 04/12/2009, Kim Davies wrote: >On 4/12/09 7:31 AM, "Cary Karp" wrote: > > > > The redelegation of a ccTLD can only be initiated at the request of the > > corresponding national government, and in any situation where that > > assertion might prove incorrect, the redelegation would require that > > government's approval. This is a matter of national sovereignty and it > > is nonsensical to expect ICANN even to contemplate overriding it at the > > urging of the IETF. And, again, if that is an incorrect statement, > > governments will have no difficulty in ensuring that their sovereignty > > prevails. > >While I agree ICANN has an entirely different relationship with ccTLDs than >it has with gTLDs, I think you characterisation of the role of governments >is rather off the mark. Redelegations are usually not initiated by >governments, and redelegations do not require government's approval. Whether >a government has any legal involvement in their ccTLD varies from >country-to-country, some countries have passed laws to nationalise the ccTLD >but AFAIK most have not. > >Sorry for the digression. > >kim > >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From jefsey@jefsey.com Fri Dec 4 14:21:07 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 E309528C0EF for ; Fri, 4 Dec 2009 14:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, 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 9FbVGH9hBAUE for ; Fri, 4 Dec 2009 14:21:06 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 4FEA53A694D for ; Fri, 4 Dec 2009 14:21:06 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1781 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGfk6-0004TY-B0; Fri, 04 Dec 2009 13:31:10 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Dec 2009 22:23:23 +0100 To: Andrew Sullivan , Eric Brunner-Williams From: JFC Morfin In-Reply-To: <20091204161618.GK91905@shinkuro.com> References: <4B1933F4.9010809@abenaki.wabanaki.net> <20091204161618.GK91905@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091204222106.4FEA53A694D@core3.amsl.com> Cc: workon@idna2010.org, iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] On graphs and equivalences 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, 04 Dec 2009 22:21:08 -0000 The whole misunderstanding Vint plays on is that IDNA is a non-Internet application internationalisation of names into internet LDH. IDNA2003 was case unreliable preserving due to the DNS case preserving ability. IDNA2008 is not case preserving, period. This permits IDNAPLUS to build on top of it a user chosen reliable case preservation mechanism. I therefore expect Chrome, Chrome OS and Google DNS to follow the same principle as Interplus. Because Interplus is nothing more than a more complete use of the existing DNS architecture. The problem is that I called for help, so the ICANN namespace would not be devastated, or no one (such as the russian mafia) would take over the naming and the Internet. Google's cute response is to put itself in the challengers position. This will certainly reduce the risks of a russian mafia take over. But this will be Googlenet. Now, we will see Google presentations, such as "gg--". They will work no problem, "gg--" with "ss" and "gs--" with eszett and conversions to the propre "xn--" at Google DNS. The point now is that Google, Microsoft and Interplus standardize within the IETF. Vint banned me to prevent that. I appealed to the IESG and IESG helped me creating the IUCG so at least the debate stays within the IETF and does not switch to ITU as Francis Muguet who died in October has started to introduce it. But it is still small, has no resource, and no good document writter in English yet who knows the 5500 RFC enough. jfc At 17:16 04/12/2009, Andrew Sullivan wrote: >On Fri, Dec 04, 2009 at 11:08:20AM -0500, Eric Brunner-Williams wrote: > > > I lack the subject matter expertise to form an opinion on the > > necessity claim for tonos-free repertoire ("upper case") for the > > meaningful formation of resource identifiers, and therefore the > > necessity to form character equivalence classes. > > > > If the necessity claim arises from "words", then it suffers the same > > defect that the claims made for other "word properties" > >To be fair, we don't need to go that far. The goal of this WG was to >"Internationalize LDH". Since LDH is case-preserving and >case-sensitive, one could (I do not, but one could) argue that some >kind of case-preserving case sensitivity is desirable for an >internationalized version too. Words or the necessity for resource >identifiers then doesn't enter in. > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From jefsey@jefsey.com Fri Dec 4 14:43:14 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 925BD3A6A68 for ; Fri, 4 Dec 2009 14:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=1.272, 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 3UkXiQnrDx63 for ; Fri, 4 Dec 2009 14:43:13 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 615853A6A66 for ; Fri, 4 Dec 2009 14:43:13 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1780 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGfjy-0004TX-5t; Fri, 04 Dec 2009 13:31:02 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Dec 2009 22:30:57 +0100 To: "Vaggelis Segredakis" , "'Erik van der Poel'" From: jefsey In-Reply-To: <24DA8FCE39E14E40BBAF227CC0B2AF47@ics.forth.gr> References: <24DA8FCE39E14E40BBAF227CC0B2AF47@ics.forth.gr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091204224313.615853A6A66@core3.amsl.com> Cc: 'Sotiris Panaretou' , 'Andrew Sullivan' , namedroppers@ops.ietf.org, workon@idna2010.org, iucg@ietf.org, 'Vint Cerf' , 'Olafur Gudmundsson' Subject: Re: [iucg] Bundling of Domain Names and DNAME 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, 04 Dec 2009 22:43:14 -0000 At 14:28 04/12/2009, Vaggelis Segredakis wrote: >Dear Erik, > >Actually it does not matter whether the final sigma is PVALID or not, >although I believe that it will be since both the .gr Registry and .cy >Registry have asked for it. > >We have the same issue with the accent mark "tonos". Almost each word in >Greek has this accent mark in small letters but if you put it in capital >letters the mark is omitted, creating two different xn-- Punycode >translations for each word used as a domain name. > >We Bundle domain names already because of this "tonos" and we face this >bundling issue since 2005 but we had put our hopes on the IDNA revision for >a better solution. Since this is not possible, we need the XNAME bundling >regardless of the final sigma in IDNA2008 situation. Dear Vaggelis, I suggest that you write a description of the issue (or quote one) so we can add it to http://idna2010.org issues to solve. There is most probably no real problem in addressing this kind of issue (similar to French access ent majuscules) but we have an entropy issue: we have to address all this kind of needs in a similar way (cf. RFC 1958) to keep it compact. This is the purpose of IDNA2010: to start from now perhaps defunct IDNA2008 we worked together, and document a Better Usage Document, listing the different possible cases and solutions that everyone can use for operational reference. jfc >Kind Regards, > >Vaggelis Segredakis > >-----Original Message----- >From: Erik van der Poel [mailto:erikv@google.com] >Sent: Thursday, December 03, 2009 7:59 PM >To: Vaggelis Segredakis >Cc: namedroppers@ops.ietf.org; Andrew Sullivan; Olafur Gudmundsson; Vint >Cerf; Sotiris Panaretou; idna-update@alvestrand.no >Subject: Re: Bundling of Domain Names and DNAME > >Vaggelis, thank you for raising this issue on the namedroppers list. > >Namedroppers, I would like to clarify one item below. > >On Thu, Dec 3, 2009 at 7:56 AM, Vaggelis Segredakis >wrote: > > Recently, as a member of the discussion of the IDNABIS WG I tried to help > > resolving these issues by explaining them to that group. However that >group > > is not free to completely re-design the IDNA protocol to something else >but > > rather with small steps to reform it to something with fewer issues. > > Unfortunately, on this process, one of the changes that are implemented >lead > > to even more names that have to be bundled together for each registrant. > > This makes it even more significant to break this chain of cost for the >end > > user. > >The IDNAbis WG drafts have not been published as RFCs yet. Currently, >the drafts make Final Sigma (Unicode U+03C2) PVALID, but this issue is >currently being discussed in the WG. > >Erik > > >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From jefsey@jefsey.com Fri Dec 4 14:46:46 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 E5F873A67D9 for ; Fri, 4 Dec 2009 14:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=1.113, 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 q51JjdweAQHp for ; Fri, 4 Dec 2009 14:46:46 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 000E73A6A68 for ; Fri, 4 Dec 2009 14:46:45 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1781 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGfk9-0004TY-4D; Fri, 04 Dec 2009 13:31:13 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Dec 2009 22:30:03 +0100 To: Cary Karp ,Kim Davies From: JFC Morfin In-Reply-To: <4B193CB1.4040909@nic.museum> References: <4B193CB1.4040909@nic.museum> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091204224646.000E73A6A68@core3.amsl.com> Cc: workon@idna2010.org, arabic Scripts IDNA , IDNA update work , iucg@ietf.org, Erik van der Poel Subject: Re: [iucg] Additional thoughts on TRANSITIONAL 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, 04 Dec 2009 22:46:47 -0000 At 17:45 04/12/2009, Cary Karp wrote: > > Redelegations are usually not initiated by governments, and > > redelegations do not require government's approval. Whether a > > government has any legal involvement in their ccTLD varies from > > country-to-country, some countries have passed laws to nationalise > > the ccTLD but AFAIK most have not. > >Are you suggesting that a letter from ICANN along anything vaguely >resembling the following lines might be conceivable? > >Dear Dr. Merkel, > >This is to inform you that the current delegation of the .DE top-level >domain is going to be rescinded due to the failure of its operator to >comply with the rules about the inclusion of the Esszet in domain names >devised by a working group of the IETF during the preparation of the >IDNABIS protocol. > >We will redelegate the domain to a new operator of our choosing at the >same time and you need not be concerned about any interruption in the >operation of the domain during this process. Cary, do not forget that through the GAC it would be signed by Obama, Sarkozy, Brown, etc. As having answered (as per the French law and Government request for candidacy) that I was a candidate to take over the management of ".fr" (French, published by http://www.lulu.com/content/paperback-book/pni/7143574) I really imagine that I could be sponsored by ICANN due to the way I would commit to support esszet in ".ger.fr". jfc >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From ajs@shinkuro.com Fri Dec 4 15:20:50 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 C76D628C105 for ; Fri, 4 Dec 2009 15:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.393, 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 qLU0m924-d04 for ; Fri, 4 Dec 2009 15:20:49 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A003528C0FF for ; Fri, 4 Dec 2009 15:20:49 -0800 (PST) Received: from [172.16.33.103] (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BE2F72FE8CDD; Fri, 4 Dec 2009 23:20:39 +0000 (UTC) From: Andrew Sullivan To: JFC Morfin In-Reply-To: X-Mailer: iPhone Mail (7D11) References: <24DA8FCE39E14E40BBAF227CC0B2AF47@ics.forth.gr> <151D2BEC-DF26-4A78-916A-5BDE881B0F77@google.com> <20091204134724.GB91905@shinkuro.com> Message-Id: <68F550DF-A658-4227-9958-9948AD1CC3CB@shinkuro.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 4 Dec 2009 18:20:35 -0500 Cc: "workon@idna2010.org" , "iucg@ietf.org" Subject: Re: [iucg] Bundling of Domain Names and DNAME 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, 04 Dec 2009 23:20:50 -0000 What is "Vint's move"? I assure you that no wg chair wants anything more than to get a document out the door and shut down. It's awful being a Chair. Everyone sits on you, and some of them have digestive problems. -- Andrew Sullivan On 2009-12-04, at 14:38, JFC Morfin wrote: > +1 > > And this is why we just decided to initiate workon@IDNA2010.org now. > I wanted to wait for the IESG to have approved the final IDNA2008 > text. But obviously Lisa's position amounts to IESG refusing the > IDNA concept the WG worked out. > > So we need IDNA2010, and we need fast if not to give an unfair > advantage to Google DNS on the network, the business, the ISP market > and try to prevent a DNS war with Microsoft which would definitly > kill any DNS innovation/extension for another 25 years. > > In the long term Unicode, Google, ICANN, Microsoft competition for > IANA control we took the Internet Users side a long ago (the debate > over RFC 4646). Today, we have a real, validate and working concept > which showes we need _none_ of them to navigate the internet more > safely, more securely, faster and cheaplier. However, I acknowledge > Vint's move is brillant. It was expected at this very date, but I > acknowledge it was not expected this way. So, we certainly are still > really too small. But, on another side, this should help weak to > strong advertising for Interplus, because it already works. > > jfc > > At 14:47 04/12/2009, Andrew Sullivan wrote: >> On Fri, Dec 04, 2009 at 08:36:50AM -0500, Vint Cerf wrote: >> > Vaggelis, >> > >> > extensions of DNS in the XNAME direction would require creation >> of a >> > new WG for this purpose. >> >> It wouldn't require a new WG: that's exactly what DNSEXT exists for. >> So I think that's why Vaggelis has sent a note to namedroppers. It'd >> probably make sense to take that topic over there and leave idnabis >> out of the discussion, since the reason for the extension (mirroring >> part of a tree to do DNS variants) is just one of the possible uses >> of >> such a mechanism, were it possible to design it safely. (For the >> same >> reason, I send this only to the idnabis list, and not to that of >> dnsext.) >> >> A >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> _______________________________________________ >> Idna-update mailing list >> Idna-update@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/idna-update > From jefsey@jefsey.com Fri Dec 4 16:47:02 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 82A4428C12C for ; Fri, 4 Dec 2009 16:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 RQvQw+eLy944 for ; Fri, 4 Dec 2009 16:47:01 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id DF3C528C129 for ; Fri, 4 Dec 2009 16:47:01 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:2681 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGinT-0006Td-Pd; Fri, 04 Dec 2009 16:46:52 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 05 Dec 2009 01:46:48 +0100 To: Andrew Sullivan From: jefsey In-Reply-To: <68F550DF-A658-4227-9958-9948AD1CC3CB@shinkuro.com> References: <24DA8FCE39E14E40BBAF227CC0B2AF47@ics.forth.gr> <151D2BEC-DF26-4A78-916A-5BDE881B0F77@google.com> <20091204134724.GB91905@shinkuro.com> <68F550DF-A658-4227-9958-9948AD1CC3CB@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091205004701.DF3C528C129@core3.amsl.com> Cc: "workon@idna2010.org" , "iucg@ietf.org" Subject: Re: [iucg] Bundling of Domain Names and DNAME 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: Sat, 05 Dec 2009 00:47:02 -0000 At 00:20 05/12/2009, Andrew Sullivan wrote: >What is "Vint's move"? I assure you that no wg chair wants anything >more than to get a document out the door and shut down. It's awful >being a Chair. Everyone sits on you, and some of them have digestive >problems. Sure. I am not refering to the WG/IDNABIS Chair. I am refering to the Google Internet VP and ISOC founder who is in the brillant process of trying to take the leadership on the Internet using the same ideas as mine's. Mind you, I have no problem with the move because it could help stabilizing the DNS far faster. But there are a few people upset and anxious all over the world. First time that something happens so unexpectedly bluntly in the Internet history, I suppose. Very very interesting !!! jfc From eblanconil@gmail.com Sun Dec 6 11:52: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 3D96B3A69AF for ; Sun, 6 Dec 2009 11:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.531 X-Spam-Level: X-Spam-Status: No, score=-1.531 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, 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 gEXN+HeZAqWR for ; Sun, 6 Dec 2009 11:52:08 -0800 (PST) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id EDDBE3A69B0 for ; Sun, 6 Dec 2009 11:52:07 -0800 (PST) Received: by ewy3 with SMTP id 3so250579ewy.13 for ; Sun, 06 Dec 2009 11:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=RpFGuubmiWHiY4rXiGRPptPIBktxrniOUkHijvNpBTc=; b=vA7crIqz9jqfhKWoLAuyIilBfle6zCzqu9qw3hFUyj8dnKuy9rV5nTShhtVk/rB1O4 H+3XXw+yDqFT7/SQyJm4HiTGApB1sSb4PlrjcdvWPguQw2aDU+blUHqZ0StL6lr18SgK JvwSlx/KF9onD/PGrQS6Kq6b7GqqysmR+Ki94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MoACEMzvHhDBOefqQOfVkMWvbs+sjf4ORdbZgmGoMhFsKYHeTcBcp5oeLMcioKGbHa zW+h3IStG1tBqNo5Q3qc5bnqQHKIXJMiI/mE3d9hTRniUDvxn2yapnqeRfOlyCy0nmSK AKhdta/HFDoC+YGeo4JQ2iLp5BAAjCXMD3+Dk= MIME-Version: 1.0 Received: by 10.216.93.69 with SMTP id k47mr2009255wef.179.1260129111698; Sun, 06 Dec 2009 11:51:51 -0800 (PST) In-Reply-To: <4B1BF8A6.5020300@abenaki.wabanaki.net> References: <951D9DB2-185D-4C5F-838B-6A79A47B2EDD@shinkuro.com> <4B1A0AF1.2000407@nic.ir> <20091205160148.GB99151@shinkuro.com> <4B1B5A58.9090609@nic.ir> <20091206165848.GC5581@shinkuro.com> <4B1BEA72.9030703@abenaki.wabanaki.net> <200912061817.nB6IHaVe040850@abenaki.wabanaki.net> <4B1BF8A6.5020300@abenaki.wabanaki.net> Date: Sun, 6 Dec 2009 20:51:51 +0100 Message-ID: <6589127a0912061151s78f68fc9o5f4b1f647a81aeb1@mail.gmail.com> From: Elisabeth Blanconil To: Eric Brunner-Williams Content-Type: multipart/alternative; boundary=0016e6d7842312ec8f047a14ace0 Cc: workon@idna2010.org, idna-update@alvestrand.no, internet users contributing group Subject: Re: [iucg] Another thoughts on TRANSITIONAL 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, 06 Dec 2009 19:52:09 -0000 --0016e6d7842312ec8f047a14ace0 Content-Type: text/plain; charset=ISO-8859-1 Jefsey, this is rather a good news! I was rather worried because I did not understand him either! But I thought it took me time too to understand you. After all, this WG is about everyone being able to understand others. It seems we still have a long way to go - at least to be politely interoperable. Cheers! OK? Elisabeth Blanconil 2009/12/6 Eric Brunner-Williams > JFC Morfin wrote: > ... > > Eric, > > I hope I understand you correctly. > > > You don't. You never will. You manifestly can't be taught to think. > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --0016e6d7842312ec8f047a14ace0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey,
this is rather a good news!
I was rather worried because I di= d not understand him either!
But I thought it took me time too to understand you.

After all, this WG is about everyone being able to understand others. It se= ems we still have a long way to go - at least to be politely interoperable.=
Cheers! OK?

Elisabeth Blanconil

2009/12/6 Eric Brunne= r-Williams <ebw@abenaki.wabanaki.net>
JFC Morfin wrote:
...
> Eric,
> I hope I understand you correctly.


You don't. You never will. You manifestly can't be taught to think.=
_________________________________________= ______
Idna-update mailing list
Idna-update@alvestrand.no<= br> http://www.alvestrand.no/mailman/listinfo/idna-update

--0016e6d7842312ec8f047a14ace0-- From psuger@gmail.com Sun Dec 6 13:29: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 9EA613A6782 for ; Sun, 6 Dec 2009 13:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zBI2twShLZxK for ; Sun, 6 Dec 2009 13:29:20 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 49AFD3A63EB for ; Sun, 6 Dec 2009 13:29:20 -0800 (PST) Received: by fxm5 with SMTP id 5so4329647fxm.28 for ; Sun, 06 Dec 2009 13:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zzUyT9DhuTs2apcL+9APRIJo3hNhvN8TxspWLmKzC/o=; b=PnfFeF83foWZbbCES7jL2qzKNvMr4qAohBazeVxW//WRLijqOBbuTXYjeXrP4H3MfI x1GmyKZq9gyEDbfCK6iYPCaJaJvgRKvX2a8apjbwIS0T+rl7fgjmTh17cBhlnB87i7fm GRKOiRtQX/ZrfykHwOlyBRvMLAbPewhn5L1Kw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M8lmKjbq2UPh/aERJVMMImtXJTjJOHrl8XWD1q7gjJmoAQ3hd66JSTn8RgjO/ZPkqr xyPtyTiiMv5GNZpdKp+mUOz5cpZW872vA4a+nAKQtS5En20FXnRrA6v+qRC0X1VT/tA7 SMkkSt63AGPEOC3WBsVKl7fKgFCgBg/nMip3I= MIME-Version: 1.0 Received: by 10.239.168.138 with SMTP id k10mr640143hbe.100.1260134947203; Sun, 06 Dec 2009 13:29:07 -0800 (PST) In-Reply-To: <6589127a0912061151s78f68fc9o5f4b1f647a81aeb1@mail.gmail.com> References: <4B1A0AF1.2000407@nic.ir> <20091205160148.GB99151@shinkuro.com> <4B1B5A58.9090609@nic.ir> <20091206165848.GC5581@shinkuro.com> <4B1BEA72.9030703@abenaki.wabanaki.net> <200912061817.nB6IHaVe040850@abenaki.wabanaki.net> <4B1BF8A6.5020300@abenaki.wabanaki.net> <6589127a0912061151s78f68fc9o5f4b1f647a81aeb1@mail.gmail.com> Date: Sun, 6 Dec 2009 22:29:07 +0100 Message-ID: <4e9b16b30912061329k50bed09fm4e732ee5afcabef9@mail.gmail.com> From: Patrick Suger To: Elisabeth Blanconil Content-Type: multipart/alternative; boundary=0016364995a7e5aa19047a1607b7 Cc: listegenerale@franceatlarge.org, workon@idna2010.org, Eric Brunner-Williams , idna-update@alvestrand.no, internet users contributing group Subject: Re: [iucg] Another thoughts on TRANSITIONAL 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, 06 Dec 2009 21:29:21 -0000 --0016364995a7e5aa19047a1607b7 Content-Type: text/plain; charset=ISO-8859-1 Please do not feed the troll. We are now finished with the IDNA2008 work. We have entered the IDNAPLUS competitive implementation period (at least between Fast Track, My Track and GDNS). WG consensus is not looked for anymore. Patrick Suger. 2009/12/6 Elisabeth Blanconil > Jefsey, > this is rather a good news! > I was rather worried because I did not understand him either! > But I thought it took me time too to understand you. > > After all, this WG is about everyone being able to understand others. It > seems we still have a long way to go - at least to be politely > interoperable. > Cheers! OK? > > Elisabeth Blanconil > > 2009/12/6 Eric Brunner-Williams > > JFC Morfin wrote: >> ... >> > Eric, >> > I hope I understand you correctly. >> >> >> You don't. You never will. You manifestly can't be taught to think. >> _______________________________________________ >> Idna-update mailing list >> Idna-update@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/idna-update >> > > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > > --0016364995a7e5aa19047a1607b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please do not feed the troll. We are now finished with the IDNA2008 work. W= e have entered the IDNAPLUS competitive implementation period (at least bet= ween Fast Track, My Track and GDNS). WG consensus is not looked for anymore= .
Patrick Suger.

2009/12/6 Elisabeth Blanco= nil <eblanconi= l@gmail.com>
Jefsey,
this is rather a good news!
I was rather worried because I di= d not understand him either!
But I thought it took me time too to understand you.

After all, this WG is about everyone being able to understand others. It se= ems we still have a long way to go - at least to be politely interoperable.=
Cheers! OK?

Elisabeth Blanconil

2009/12/6 Eric Brunne= r-Williams <ebw@abenaki.wabanaki.net>
=

JFC Morfin wrote:
...
> Eric,
> I hope I understand you correctly.


You don't. You never will. You manifestly can't be taught to think.=
_______________________________________________
Idna-update mailing list
Idna-update@= alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update


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


--0016364995a7e5aa19047a1607b7-- From jmabdp@gmail.com Sun Dec 6 15:48:36 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 11C3028C0FB; Sun, 6 Dec 2009 15:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=-2.783, BAYES_05=-1.11, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] 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 s8mmo4O6KRHt; Sun, 6 Dec 2009 15:48:34 -0800 (PST) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 3B5813A657C; Sun, 6 Dec 2009 15:48:34 -0800 (PST) Received: by ywh1 with SMTP id 1so8150882ywh.18 for ; Sun, 06 Dec 2009 15:48:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=jFQ5NIHm2MT6yWJcBEDDqXOyExxaPhP2wo0vTvE2jjU=; b=fUbwv7yY6NKiXyzM8oh3DEkz9PhJHnspuXGd9tfNHDgv76Vr4yzzybNxeZP3NXdZEN 8RvNr2locutUW34N4fCUFQL4SWUgSDBZYIk+yV2t1LF+4o+Ow0pPOzmdAjEHVpScKM9F wZPkiooIcOH8tdlQtPMONZEkI7acw5hgqfS/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=A5ZEvcloSySWnuAUCK4T4zp6u5oPtsIOnBq8zw5M6gR77Xxz3fd7Xrxxh2tFZWr/R2 CI7w2gmSA2Yrn7JvEGnV90CzmlQ9Qh4tEtAPwaQAWBRpbHOldNGi3VJMTRGohZBIHQqQ Qs4b4snm0NQQIevu6LrCOxFj+8RjMPv6iqyc8= MIME-Version: 1.0 Received: by 10.100.233.35 with SMTP id f35mr5149600anh.41.1260143301631; Sun, 06 Dec 2009 15:48:21 -0800 (PST) Date: Mon, 7 Dec 2009 00:48:21 +0100 Message-ID: <6aad7a210912061548v147c2034s10b866974cef7edb@mail.gmail.com> From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=001636b2b4d1dc1ea6047a17f942 Cc: workon@idna2010.org, ietf@ietf.org Subject: [iucg] IUCG IDNA2010 SIG 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, 06 Dec 2009 23:48:36 -0000 --001636b2b4d1dc1ea6047a17f942 Content-Type: text/plain; charset=ISO-8859-1 http://iucg.org/wiki/BUD-IDNA2010 The WG/IDNABIS work being conducted on IDNA2008 (i.e. the new standard for Internationalized Domain Names) is now completed. As committed, the IUCG plans to publish an "IDNA2010 Best Usage Document" in order to explain to users how to best take advantage from the IDNA proposition and extensions. The WG text has been reviewed by the IETF/LC. Now, it has to be accepted by the IESG and should have then been deployed via several projects in the coming months. However, competition between these projects has already started. The workon@idna2010.org moderated mailing list created to that end has therefore been activated. We know that this matter is rather sensible. Therefore, the list is tyrannically moderated by its facilitator. Only technically worthy, and polite, contributions will be accepted. The target is not to publish an RFC that would standardize or recommend a practice. It is rather to document the different options that users may have and how they may use them. This will be the first time that such a multiconsensual document will be worked on at IUCG. We, therefore, expect the form of this work to also be experimental. The background is the following: * in a network architecture, multilingualization belongs to the presentation layer. * the Internet has no documented presentation layer. * yet the IDNA2008 proposition, even if not perfect, makes a lot of sense and builds on the IDNA2003 operational experience of half a billion users. * hence, the Internet presentation layer is underlying the IDNA2008 proposition. Therefore, the target is: 1. to uncover and document the Internet presentation layer. 2. to document IDNA within that presentation layer. 3. to explore the new possibilities offered by the presentation layer to IDNA and the Internet. This will be carried out in relation with the parallel work and testing being conducted on the Interplus usage architecture and ML-DNS pile. The only, but very strict, constraint that is imposed on this work is the full respect, down to the code, of the current Internet and a total transparence and neutrality to its end to end processes and services. The target is to use the Internet better. Multilinguistics is understood as the cybernetics of linguistic diversity. Multilingualization is understood as the multilinguistic function that is able to technically support an equal and neutral empowerment of every language and script. Neutrality is taken as being transparent to the technological, operational, and contextual, partial or complete, changes on the end to end path. Universalization is essentially independence from languages and scripts. Globalization is the internationalization of the media, localization of the ends, and langtagization of the content. Internationalization is the reduction of the linguistic bias down to the minimum that is permitted by the underlying language. Along the international usages, contributions will be accepted in the main languages, as soon as a moderator or a sergeant at arms has been designated for that respective language and, initially, in English and French. The convener and initial facilitator of this list is Jean-Michel Bernier de Portzamparc. To subscribe : http://idna2010.org/mailman/listinfo/workon_idna2010.org. IUCG Secretariat --001636b2b4d1dc1ea6047a17f942 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= http://iucg.org/wiki/BUD-IDNA= 2010

= =A0

The WG/IDNABIS work being conducted on IDNA2008 (i.e. the new standard for Internationalized Domain Names) is now completed. As committed= , the IUCG plans to publish an "IDNA2010 Best Usage Document" in or= der to explain to users how to best take advantage from the IDNA proposition an= d extensions.

=A0

The WG text has been reviewed by the IETF/LC. Now, it has to be accepted by the IESG and should have then been deployed via several project= s in the coming months. However, competition between these projects has already started.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

The workon@idna2010.org mode= rated mailing list created to that end has therefore been activated.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

We know that this matter is rather sensible. Therefore, the list is tyrannically moderated by its facilitator. Only technically worthy, and pol= ite, contributions will be accepted.

=A0

The target is not to publish an RFC that would standardize or recommend a practice. It is rather to document the different options that u= sers may have and how they may use them. This will be the first time that such a multiconsensual document will be worked on at IUCG.

=A0

We, therefore, expect the form of this work to also be experimental.

= =A0

The background is the following:

=A0

=A0=A0=A0 * in a network architecture, multilingualization belongs to the presentation layer.=

=A0=A0=A0 * the Internet has no documented presentation layer.

=A0=A0=A0 * yet the IDNA2008 proposition, even if not perfect, makes a lot of sense and builds on the IDNA2003 operational experience of half a billion users.

=A0=A0=A0 * hence, the Internet presentation layer is underlying the IDNA2008 proposition.

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

Therefore, the target is:

=A0

=A0=A0=A0 1. to uncover and document the Internet presentation layer.

=A0=A0=A0 2. to document IDNA within that presentation layer.

=A0=A0=A0 3. to explore the new possibilities offered by the presentation layer to IDNA and the Internet. <= /span>

=A0

This will be carried out in relation with the parallel work and testing being conducted on the Interplus usage architecture and ML-DNS pile= . The only, but very strict, constraint that is imposed on this work is the f= ull respect, down to the code, of the current Internet and a total transparence= and neutrality to its end to end processes and services. The target is to use the Internet better.

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

Multilinguistics is understood as the cybernetics of linguistic diversity. Multilingualization is understood as the multilinguistic functio= n that is able to technically support an equal and neutral empowerment of eve= ry language and script. Neutrality is taken as being transparent to the technological, operational, and contextual, partial or complete, changes on= the end to end path.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

Universalization is essentially independence from languages and scripts.

=A0

Globalization is the internationalization of the media, localization of the ends, and langtagization of the content.

=A0

Internationalization is the reduction of the linguistic bias down to the minimum that is permitted by the underlying language.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

Along the international usages, contributions will be accepted in the main languages, as soon as a moderator or a sergeant at arms has been designated for that respective language and, initially, in English and Fren= ch.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

The convener and initial facilitator of this list is Jean-Michel Bernier de Portzamparc.

=A0

To subscribe : http://idna2010.org/mailman/listinfo/workon_idna2010.org.<= /span>

IUCG Secretariat

--001636b2b4d1dc1ea6047a17f942-- From jmabdp@gmail.com Sun Dec 6 16:16:00 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 1C51C3A6959; Sun, 6 Dec 2009 16:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_05=-1.11, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] 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 dDiuFN4fNiyD; Sun, 6 Dec 2009 16:15:58 -0800 (PST) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 5E1D13A657C; Sun, 6 Dec 2009 16:15:57 -0800 (PST) Received: by ywh1 with SMTP id 1so8197577ywh.18 for ; Sun, 06 Dec 2009 16:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=2naT7068H5gRnU1H1c2+zmxLW8Ns1sVSNevS5rSN66s=; b=CmG5YVZQ69QSja2RQV7S3HpALHC1NIsKyZavku0HZLiQL190NOkYfYK8sZ6roTBH8s jBx4ObKYg6mCFTAm/MhJ2ujTgMQ4Kp/16BzFDBxTNM+nUkgQw0v2irRE3iY8XX1BV5LM mJ62QWO/TGWCUEsnHc7mCkB4BpBBiuCiUEsa8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Vr+jd6d2p5EKHF3uwN1Ch06kfR7Y19CMWjLquf0sUCXZLPLlw3ZTSRRutch+Mrh87U ghRwedLZeMXuhg9cDxoEtr+zZOKGENg1VxBxV8aulNv+O6H4qmN/ds/gkVFt2Remh5Px F71tuYW1TvH4ARK3RkrW2+UAOctzOP7rTzHF8= MIME-Version: 1.0 Received: by 10.100.233.35 with SMTP id f35mr5152210anh.41.1260144944155; Sun, 06 Dec 2009 16:15:44 -0800 (PST) Date: Mon, 7 Dec 2009 01:15:44 +0100 Message-ID: <6aad7a210912061615i78255502n63e92583fd47adae@mail.gmail.com> From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=001636b2b4d1c30bfa047a185b1d Cc: ietf@ietf.org Subject: [iucg] IUCG IDNA2010 SIG 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, 07 Dec 2009 00:16:00 -0000 --001636b2b4d1c30bfa047a185b1d Content-Type: text/plain; charset=ISO-8859-1 http://iucg.org/wiki/BUD-IDNA2010 The WG/IDNABIS work being conducted on IDNA2008 (i.e. the new standard for Internationalized Domain Names) is now completed. As committed, the IUCG plans to publish an "IDNA2010 Best Usage Document" in order to explain to users how to best take advantage from the IDNA proposition and extensions. The WG text has been reviewed by the IETF/LC. Now, it has to be accepted by the IESG and should have then been deployed via several projects in the coming months. However, competition between these projects has already started. The workon@idna2010.org moderated mailing list created to that end has therefore been activated. We know that this matter is rather sensible. Therefore, the list is tyrannically moderated by its facilitator. Only technically worthy, and polite, contributions will be accepted. The target is not to publish an RFC that would standardize or recommend a practice. It is rather to document the different options that users may have and how they may use them. This will be the first time that such a multiconsensual document will be worked on at IUCG. We, therefore, expect the form of this work to also be experimental. The background is the following: * in a network architecture, multilingualization belongs to the presentation layer. * the Internet has no documented presentation layer. * yet the IDNA2008 proposition, even if not perfect, makes a lot of sense and builds on the IDNA2003 operational experience of half a billion users. * hence, the Internet presentation layer is underlying the IDNA2008 proposition. Therefore, the target is: 1. to uncover and document the Internet presentation layer. 2. to document IDNA within that presentation layer. 3. to explore the new possibilities offered by the presentation layer to IDNA and the Internet. This will be carried out in relation with the parallel work and testing being conducted on the Interplus usage architecture and ML-DNS pile. The only, but very strict, constraint that is imposed on this work is the full respect, down to the code, of the current Internet and a total transparence and neutrality to its end to end processes and services. The target is to use the Internet better. Multilinguistics is understood as the cybernetics of linguistic diversity. Multilingualization is understood as the multilinguistic function that is able to technically support an equal and neutral empowerment of every language and script. Neutrality is taken as being transparent to the technological, operational, and contextual, partial or complete, changes on the end to end path. Universalization is essentially independence from languages and scripts. Globalization is the internationalization of the media, localization of the ends, and langtagization of the content. Internationalization is the reduction of the linguistic bias down to the minimum that is permitted by the underlying language. Along the international usages, contributions will be accepted in the main languages, as soon as a moderator or a sergeant at arms has been designated for that respective language and, initially, in English and French. The convener and initial facilitator of this list is Jean-Michel Bernier de Portzamparc. To subscribe : http://idna2010.org/mailman/listinfo/workon_idna2010.org. IUCG Secretariat --001636b2b4d1c30bfa047a185b1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable http://iucg= .org/wiki/BUD-IDNA2010

The WG/IDNABIS work being conducted on IDNA2008 (i.e. the new standard for Internationalized Domain Names) is now completed. As committed, the IUCG plans to publish an "IDNA2010 Best Usage Document" in order = to explain to users how to best take advantage from the IDNA proposition and extensions.

The WG text has been reviewed by the IETF/LC. Now, it has to be accepted by the IESG and should have then been deployed via several projects in the coming months. However, competition between these projects has already started.

The workon@idna201= 0.org moderated mailing list created to that end has therefore been act= ivated.

We know that this matter is rather sensible. Therefore, the list is tyrannically moderated by its facilitator. Only technically worthy, and polite, contributions will be accepted.

The target is not to publish an RFC that would standardize or recommend a practice. It is rather to document the different options that users may have and how they may use them. This will be the first time that such a multiconsensual document will be worked on at IUCG.

We, therefore, expect the form of this work to also be experimental.

The background is the following:

=A0 =A0* in a network architecture, multilingualization belongs to the pre= sentation layer.
=A0 =A0* the Internet has no documented presentation layer.
=A0 =A0* yet the IDNA2008 proposition, even if not perfect, makes a lot of sense and builds on the IDNA2003 operational experience of half a billion users.
=A0 =A0* hence, the Internet presentation layer is underlying the IDNA2008= proposition.

Therefore, the target is:

=A0 =A01. to uncover and document the Internet presentation layer.
=A0 =A02. to document IDNA within that presentation layer.
=A0 =A03. to explore the new possibilities offered by the presentation lay= er to IDNA and the Internet.

This will be carried out in relation with the parallel work and testing being conducted on the Interplus usage architecture and ML-DNS pile. The only, but very strict, constraint that is imposed on this work is the full respect, down to the code, of the current Internet and a total transparence and neutrality to its end to end processes and services. The target is to use the Internet better.

Multilinguistics is understood as the cybernetics of linguistic diversity. Multilingualization is understood as the multilinguistic function that is able to technically support an equal and neutral empowerment of every language and script. Neutrality is taken as being transparent to the technological, operational, and contextual, partial or complete, changes on the end to end path.

Universalization is essentially independence from languages and scripts.
Globalization is the internationalization of the media, localization of the= ends, and langtagization of the content.

Internationalization is the reduction of the linguistic bias down to the mi= nimum that is permitted by the underlying language.

Along the international usages, contributions will be accepted in the main languages, as soon as a moderator or a sergeant at arms has been designated for that respective language and, initially, in English and French.

The convener and initial facilitator of this list is Jean-Michel Bernier de= Portzamparc.

To subscribe : http://idna2010.org/mailman/listinfo/workon_idna= 2010.org.

IUCG Secretariat

--001636b2b4d1c30bfa047a185b1d-- From jmabdp@gmail.com Mon Dec 7 03:38:52 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 A5DC128C153; Mon, 7 Dec 2009 03:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.743 X-Spam-Level: X-Spam-Status: No, score=-2.743 tagged_above=-999 required=5 tests=[AWL=1.855, BAYES_00=-2.599, GB_I_LETTER=-2, 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 W4n-VsK6ukaF; Mon, 7 Dec 2009 03:38:51 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 225F528C12B; Mon, 7 Dec 2009 03:38:51 -0800 (PST) Received: by gxk28 with SMTP id 28so3965408gxk.9 for ; Mon, 07 Dec 2009 03:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=CBwA4+Cwpalo8OQCLoPFbg9vICa6b6xz9H5qfdsDtNM=; b=gadNRrE6jdJnVXHW6xDaG8Hqr32FtLdRzJEQwZjYgZZba9SVXPEbgJ7BgL7Kezq38G ue+Ty1/Pv3CRpSYu2+7gcfogWBkslw9RlT5D4d5HZZj81LwQwAkVBHUVad6rKZBTbuGW NQd/JG68trlDLWmXrWG1VBG0LQYJyjxRmfEjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=cTHouOmM8hA6UkYgEzpc47B1Twy+7RlxrqliKg48ExSYYeB0xXvQplkfk/piY/mLLk Tqq3XfMIizZvrHVO0UvyZcplOtXNEfNkHyg2+gs/8iTMMjgkhhUBpegYRgfgaAEYSvfQ TEfycx3O0kBzyhQyFGrH7f4mOIMtKe0sIEZJ0= MIME-Version: 1.0 Received: by 10.101.3.26 with SMTP id f26mr5256603ani.5.1260185916671; Mon, 07 Dec 2009 03:38:36 -0800 (PST) Date: Mon, 7 Dec 2009 12:38:36 +0100 Message-ID: <6aad7a210912070338x281caae4tfdf9a72f1b5bdaa@mail.gmail.com> From: jean-michel bernier de portzamparc To: IDNA update work , iesg@ietf.org, internet users contributing group Content-Type: multipart/alternative; boundary=001636c594f7ea0928047a21e5f8 Cc: workon@idna2010.org, Vint Cerf , Lisa Dusseault Subject: [iucg] Time has come for IDNA2010 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, 07 Dec 2009 11:38:52 -0000 --001636c594f7ea0928047a21e5f8 Content-Type: text/plain; charset=ISO-8859-1 Dear Colleagues, Eric Brunner-Williams' last mail and the lack of appropriate reaction show, as Patrick Suger wrote it, that the time of consensus is over and that the time of competition has resumed. However, the fundamental work is not completed as shows the lack of consensus we experiment on a simple two letter issue between designers, users, and manufacturers (while French and Latin language majuscules issue, cf. pending I_D, has not even been discussed). This means that he most important architectural options are still left open with three possible (centralised, decentralised, distributed) , overall interoperable but not compatible Internet usage architectures and several published testing projects. This is why, being its IUCG designated facilitator, I hope that we can pursue our work in a coopetitive sprit within the IDNA2010 framework. This is also an attempt to a new kind of deliverable: a multiconsensual better usage documentation (BUD). We will try to KISS and diversified as much as possible. Portzamparc ------------ http://iucg.org/wiki/BUD-IDNA2010 The WG/IDNABIS work being conducted on IDNA2008 (i.e. the new standard for Internationalized Domain Names) is now completed. As committed, the IUCG plans to publish an "IDNA2010 Best Usage Document" in order to explain to users how to best take advantage from the IDNA proposition and extensions. The WG text has been reviewed by the IETF/LC. Now, it has to be accepted by the IESG and should have then been deployed via several projects in the coming months. However, competition between these projects has already started. The workon@idna2010.org moderated mailing list created to that end has therefore been activated. We know that this matter is rather sensible. Therefore, the list is tyrannically moderated by its facilitator. Only technically worthy, and polite, contributions will be accepted. The target is not to publish an RFC that would standardize or recommend a practice. It is rather to document the different options that users may have and how they may use them. This will be the first time that such a multiconsensual document will be worked on at IUCG. We, therefore, expect the form of this work to also be experimental. The background is the following: * in a network architecture, multilingualization belongs to the presentation layer. * the Internet has no documented presentation layer. * yet the IDNA2008 proposition, even if not perfect, makes a lot of sense and builds on the IDNA2003 operational experience of half a billion users. * hence, the Internet presentation layer is underlying the IDNA2008 proposition. Therefore, the target is: 1. to uncover and document the Internet presentation layer. 2. to document IDNA within that presentation layer. 3. to explore the new possibilities offered by the presentation layer to IDNA and the Internet. This will be carried out in relation with the parallel work and testing being conducted on the Interplus usage architecture and ML-DNS pile. The only, but very strict, constraint that is imposed on this work is the full respect, down to the code, of the current Internet and a total transparence and neutrality to its end to end processes and services. The target is to use the Internet better. Multilinguistics is understood as the cybernetics of linguistic diversity. Multilingualization is understood as the multilinguistic function that is able to technically support an equal and neutral empowerment of every language and script. Neutrality is taken as being transparent to the technological, operational, and contextual, partial or complete, changes on the end to end path. Universalization is essentially independence from languages and scripts. Globalization is the internationalization of the media, localization of the ends, and langtagization of the content. Internationalization is the reduction of the linguistic bias down to the minimum that is permitted by the underlying language. Along the international usages, contributions will be accepted in the main languages, as soon as a moderator or a sergeant at arms has been designated for that respective language and, initially, in English and French. The convener and initial facilitator of this list is Jean-Michel Bernier de Portzamparc. To subscribe : http://idna2010.org/mailman/listinfo/workon_idna2010.org. IUCG Secretariat --001636c594f7ea0928047a21e5f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Colleagues,

Eric Brunner-Williams' last mail and the lack of appropriate reaction s= how, as Patrick Suger wrote it, that the time of consensus is over and that= the time of competition has resumed.

However, the fundamental work is not completed as shows the lack of consens= us we experiment on a simple two letter issue between designers, users, and= manufacturers (while French and Latin language majuscules issue, cf. pendi= ng I_D, has not even been discussed). This means that he most important arc= hitectural options are still left open with three possible (centralised, de= centralised, distributed) , overall interoperable but not compatible Intern= et usage architectures and several published testing projects. This is why,= being its IUCG designated facilitator, I hope that we can pursue our work = in a coopetitive sprit within the IDNA2010 framework.

This is also an attempt to a new kind of deliverable: a multiconsensual bet= ter usage documentation (BUD). We will try to KISS and diversified as much = as possible.
Portzamparc

------------

http://iucg.org/wiki/BUD-IDNA= 2010

The WG/IDNABIS work being conducted on IDNA2008 (i.e. the new standard = for Internationalized Domain Names) is now completed. As committed, the IUC= G plans to publish an "IDNA2010 Best Usage Document" in order to = explain to users how to best take advantage from the IDNA proposition and e= xtensions.

The WG text has been reviewed by the IETF/LC. Now, it has to be accepted by= the IESG and should have then been deployed via several projects in the co= ming months. However, competition between these projects has already starte= d.

The workon@idna2010.org moderate= d mailing list created to that end has therefore been activated.

We know that this matter is rather sensible. Therefore, the list is tyranni= cally moderated by its facilitator. Only technically worthy, and polite, co= ntributions will be accepted.

The target is not to publish an RFC that would standardize or recommend a p= ractice. It is rather to document the different options that users may have= and how they may use them. This will be the first time that such a multico= nsensual document will be worked on at IUCG.

We, therefore, expect the form of this work to also be experimental.
The background is the following:

=A0=A0=A0 * in a network architecture, multilingualization belongs to the p= resentation layer.
=A0=A0=A0 * the Internet has no documented presentation layer.
=A0=A0=A0 * yet the IDNA2008 proposition, even if not perfect, makes a lot = of sense and builds on the IDNA2003 operational experience of half a billio= n users.
=A0=A0=A0 * hence, the Internet presentation layer is underlying the IDNA20= 08 proposition.

Therefore, the target is:

=A0=A0=A0 1. to uncover and document the Internet presentation layer.
=A0=A0=A0 2. to document IDNA within that presentation layer.
=A0=A0=A0 3. to explore the new possibilities offered by the presentation l= ayer to IDNA and the Internet.

This will be carried out in relation with the parallel work and testing bei= ng conducted on the Interplus usage architecture and ML-DNS pile. The only,= but very strict, constraint that is imposed on this work is the full respe= ct, down to the code, of the current Internet and a total transparence and = neutrality to its end to end processes and services. The target is to use t= he Internet better.

Multilinguistics is understood as the cybernetics of linguistic diversity. = Multilingualization is understood as the multilinguistic function that is a= ble to technically support an equal and neutral empowerment of every langua= ge and script. Neutrality is taken as being transparent to the technologica= l, operational, and contextual, partial or complete, changes on the end to = end path.

Universalization is essentially independence from languages and scripts.
Globalization is the internationalization of the media, localization of the= ends, and langtagization of the content.

Internationalization is the reduction of the linguistic bias down to the mi= nimum that is permitted by the underlying language.

Along the international usages, contributions will be accepted in the main = languages, as soon as a moderator or a sergeant at arms has been designated= for that respective language and, initially, in English and French.

The convener and initial facilitator of this list is Jean-Michel Bernier de= Portzamparc.

To subscribe : http://idna2010.org/mailman/listinfo/workon_idna2010.org.
<= br> IUCG Secretariat

--001636c594f7ea0928047a21e5f8-- From jefsey@jefsey.com Mon Dec 7 04:37:33 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 DB40128C14D; Mon, 7 Dec 2009 04:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_20=-0.74, 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 7khLjo6AGpbv; Mon, 7 Dec 2009 04:37:33 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 265B428C122; Mon, 7 Dec 2009 04:37:33 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1219 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NHcq3-0000St-Kb; Mon, 07 Dec 2009 04:37:16 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Dec 2009 13:37:08 +0100 To: Pete Resnick ,Gervase Markham , Lisa Dusseault From: jefsey In-Reply-To: <4B1CA36A.60101@qualcomm.com> References: <4B137E86.5060806@alvestrand.no> <20091201140034.GA71984@shinkuro.com> <4B153832.1020803@abenaki.wabanaki.net> <4B17D6D5.60506@mozilla.org> <4B1CA36A.60101@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091207123733.265B428C122@core3.amsl.com> Cc: workon@idna2010.org, iucg@ietf.org, iesg@ietf.org Subject: Re: [iucg] 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: Mon, 07 Dec 2009 12:37:33 -0000 At 07:40 07/12/2009, Pete Resnick wrote: >On 12/3/09 9:18 AM, Gervase Markham wrote: > > On 02/12/09 10:06, Lisa Dusseault wrote: > > > >> One slightly more solid question for browsers is, would it be entirely > >> crazy to have different mapping algorithms for typed-in domain names > >> than for links followed? There might be a locale-dependent mapping as > >> well as a global mapping. (I assume that having every established > >> locale mapping installed would be complete craziness.) > >> > > IMO crazy. People type URLs into web browsers. Other people type URLs > > into HTML documents. We can't have the same letters in those two > > locations taking you to different places. > > > >Generally staying out of this discussion, but: If we were considering to >do this correctly (IMO), typed-in domains with DISALLOWED characters >would get mapped, and links followed would get "Bite Me!" in big bold >letters and the equivalent of an NXDOMAIN. Anything that takes typed >input that maps should dynamically "correct" to PVALID things, and >anything that is taking data should scream bloody murder if the domain >labels are not all PVALID. > >Yes, I know I'm not convincing anyone of this. But it's the right thing >to do. > >Back to my hidey-hole. We are in agreement. I add this to the "recipes" for IDNA2010. The real issue is that IDNA is conceptually wrong unless 1. you only use a single browser. This is why I can only accept it as a default. 2. you understant it as part of an interplus like reading of the Internet. "Application" then stands for a pseudo-network layer common application. Otherwise you will possibly have a different location for each user application, depending on the libraries they have been compiled with. Best. jfc From eblanconil@gmail.com Tue Dec 8 11:17:50 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 2CB1D3A6A21 for ; Tue, 8 Dec 2009 11:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] 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 V6a5xVzACDgi for ; Tue, 8 Dec 2009 11:17:28 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 5CAA53A67EC for ; Tue, 8 Dec 2009 11:17:13 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so1216115fgg.13 for ; Tue, 08 Dec 2009 11:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6GuclAikl10XUFpi41PbQtAGHeI00iCEE6AEpM3McDc=; b=TouRPYLjDenvlcMp1ae60pR+4nhS107A+LrXMJ8CapNOmuUBYBGh+apw1BFADaLJ21 d93OjV6UoymaT8Fs9p55A3vubIAkawcDh8s2/X+HSXQlTsX52Ie1dz7L6HW8XAh1z6js hRucFijyZ7FuH4zi1C6lyzw/6v+kR2ci/5iMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M9QnJvdgB4Zmo2CbJlhxBMIzHBNCLbPU7Er/TZTfn5ePI3X+DnBa+Xh5sdf9e/u8A9 uQkkZ5Zl1TZtH+qofEdP6glfUzF6sM7xh7w8Xcg9k5QZv2NZiV7sNN6qVATfX7fp9C7P d2l+GMUny4lMk+4BhlEdrnW8YAighU5FKRjFw= MIME-Version: 1.0 Received: by 10.216.87.80 with SMTP id x58mr2991795wee.92.1260299821400; Tue, 08 Dec 2009 11:17:01 -0800 (PST) In-Reply-To: <30b660a20912080757g1f97df7cj3e054ecffd808ddc@mail.gmail.com> References: <20091203174807.GF85534@shinkuro.com> <8BC845943058D844ABFC73D2220D466508C0054D@nics-mail.sbg.nic.at> <30b660a20912041345s1a5f71abj7252ed1ccd190644@mail.gmail.com> <4B1E1FE4.5040103@it.aoyama.ac.jp> <30b660a20912080757g1f97df7cj3e054ecffd808ddc@mail.gmail.com> Date: Tue, 8 Dec 2009 20:17:01 +0100 Message-ID: <6589127a0912081117u56111126o84566a9a3a438989@mail.gmail.com> From: Elisabeth Blanconil To: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= Content-Type: multipart/alternative; boundary=0016e6d624692a4525047a3c6b70 Cc: workon@idna2010.org, idna-update@alvestrand.no, internet users contributing group Subject: Re: [iucg] MAYBE-TRANSITIONAL, a historical tale 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, 08 Dec 2009 19:17:51 -0000 --0016e6d624692a4525047a3c6b70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Mark, This is great! This is like organizing three Y2K!!! Very exciting. Some suggestions. Some may seem odd, but we need to be practical. Europe ha= s started registering IDNs a few days ago. Fast Track members will start in a few weeks. So we have to make sure they should support their non-IDNA2003 registrants, or they should wait for 2015. - untill 2013 IDNA will continue to resolve IPv4 addresses but from 2015 on it will only resolve IPv6. - it will partly be French compatible in 2013 and will provide full French support from 2015. - the cdTLD (characters deviant TLD) ICANN committee should supervise applications compatibility with the the prevailing temporary standard. - no TLD will be formed in using deviation characters before 2019 in order to allow the remaining 1% population not to be over embarassed. - Greek, Macedonian, Austrian, German, Helevetic, Luxemburghese, Lichensteinese, European, Polish, French, Deutch, Belgium, Governments and Administrations should be told to make sure that e-government forms adapt t= o the UTP (Unicode Transition Plan). Same for banking security applications. Same for every application using some kind of IRI. - to make hundred millions of people aware at low cost, we could propose th= e EU Multilingualisation Commissary to make 2013 and 2015 the SSS Sigma & Eszett years. We also have to find a way to police the transition, otherwise we may have many problems (I am sure ICANN is to commission a 2 million dollars study o= n their identification/evaluation). Elisabeh Blanconil 2009/12/8 Mark Davis =E2=98=95 > > Here's a modified proposal, a bit rough yet. > Live page: http://www.macchiato.com/unicode/idna/transition-proposal > > Problem > > We would like to have the 4 deviation characters be valid, at some point. The key problem is that we don't want current URLs in web pages, etc. to go to two different locations depending on the browser, nor do we want joe@fu=C3=9Fball.com to go sometimes to joe@fu=C3=9Fball.comand sometimes to joe@fussball.com. Even once IDNA2008 is approved, for a long time a majorit= y of the implementations will still be IDNA2003, so this also goes for new label registrations during the transition period. > > Proposal > > IDNA2008 changes as follows: > > The 4 deviation characters get the property PVALID_AFTER_2015 > The requirements are: > > On registration, PVALID_AFTER_2015 is equivalent to PVALID > On lookup, PVALID_AFTER_2015 is treated as DISALLOWED up until 2016 Jan 1= , 00:00:00 GMT, and treated as PVALID thereafter. > > Implementations must not map the characters after the switchover date. > > Implementations that map the characters before that date, must map as in IDNA2003. > > The goal is to > > allow the 4 character to become valid, as soon as possible; > avoid the 'nightmare' scenario of the same URL going to two different locations, as much as possible. > > Scenarios > > Let's see what happens with fu=C3=9Fball.xxx over time, where xxx is some registry (eg .de, .blogspot.com, or others). Background: essentially all browsers and other major implementations are planning to map for compatibility. We'll look at browsers, but this also applies to email, etc. > > Early 2010 (just as IDNA2008 is approved) > > At this time the world browsers are 100% IDNA2003 > > browsers map fu=C3=9Fball.xxx to fussball.xxx. > registries can start accepting eszett, and should bundle with ss. > fu=C3=9Fball shows up as fussball in the address bar > > note: it is only by convention that fussball is seen in the address bar i= n this case; a browser could also display fu=C3=9Fball, as in UTS46. > > results: > > if the registry bundles, both fu=C3=9Fball.xxx and fussball.xxx go to the= same owner. > if the registry doesn't bundle, both fu=C3=9Fball.xxx and fussball.xxx go= to the same owner. > > The odd IDNA2008 browser that doesn't map just fails, because =C3=9F is n= ot PVALID; it doesn't take fu=C3=9Fball.xxx to a different location than the v= ast majority of browsers. > > In 2013 > > At this time the world browsers are 50% IDNA2003, 50% IDNA2008 > > same as above. No ambiguity in results. > > In 2016 Feb > > At this time the world browsers are 1% IDNA2003, 99% IDNA2008 > > 99% of browsers switch to not mapping fu=C3=9Fball.xxx. > Registries no longer need to bundle; they can have different owners for fu=C3=9Fball.xxx and fussball.xxx. > fu=C3=9Fball shows up as fu=C3=9Fball in the address bar > results: > > if the registry bundles, both fu=C3=9Fball.xxx and fussball.xxx go to the= same owner. > if the registry doesn't bundle, fu=C3=9Fball.xxx and fussball.xxx go to different owners. > > The odd IDNA2003 browser that is left goes to the wrong location for the affected languages; people that use them need to upgrade. > > Mark > > > On Tue, Dec 8, 2009 at 01:44, "Martin J. D=C3=BCrst" wrote: >> >> I agree with Mark that while there are similarities between MAYBE and TRANSITIONAL, there are also huge differences. >> >> One difference, which Mark has mentioned, is the number of characters affected. >> >> A second difference is that there would only be one transition from TRANSITIONAL to PVALID, not a series of transitions from MAYBE to PVALID. >> >> A third difference is that MAYBE was essentially saying "we don't have a clue now, we may have later". In my understanding (I didn't participate in any meeting), one of the main reasons brought by the Unicode side against MAYBE was that if it's MAYBE, we can as well look at the thing and decide now. For TRANSITIONAL, we may know exactly what we want to do, it just doesn't fit into PVALID and DISALLOWED. >> >> BTW, I don't think that any of the dynamic lookup schemes proposed by Andrew or Eric are feasible, they quite are simply overengineered. We need something much simpler, even if this temporarily goes against user convenience. >> >> Regards, Martin. >> >> On 2009/12/05 6:45, Mark Davis =E2=98=95 wrote: >>> >>> I agree with you that there are many similarities between the MAYBE and >>> TRANSITIONAL. MAYBE at the time wasn't suitable because it was applied to a >>> huge number of characters. However, applying the concept (with a few >>> changes) to these 4 characters for a transitional period is, I think, >>> feasible. >>> >>> Mark >>> >>> >>> On Fri, Dec 4, 2009 at 12:40, John C Klensin wrote: >>> >>>> Once upon a time, not really that long ago, there was a proposal >>>> to differentiate what is now PVALID by including MAYBE YES and >>>> MAYBE NO categories. Anyone interested should try to find a >>>> copy of draft-klensin-idnabis-issues-06.txt and earlier. The >>>> general model, in today's vocabulary, was to put characters (and >>>> groups of characters) that we weren't sure about into categories >>>> that would encourage different handling on registration and >>>> looking from characters about which we were more certain, to >>>> permit later reclassification, and to arrange for controlled >>>> transitions. There was consensus for removing those categories >>>> because they made things too fragile, because they would require >>>> that all registries and applications check for updates and >>>> changes frequently (which would be too fragile), and so on. >>>> >>>> In practice, the only real difference between MAYBE and the sort >>>> of implied TRANSITIONAL you imply (or the explicit versions >>>> others have suggested) is that MAYBE would have laid out the >>>> "this is likely to change" aspect of the situation more clearly, >>>> while the idea you outline above raises all of the issues that >>>> the WG has discussed about transitions from DISALLOWED to PVALID >>>> (and decided that reclassification should require a catastrophic >>>> situation). >>>> >>>> If I remember correctly, both you and Mark were at the meeting >>>> at which the decision to drop MAYBE was made and were among >>>> those pushing for that decision, pretty much on the basis >>>> outlined above. >>>> >>>> While I don't object to revisiting that general idea -- under >>>> the identification of TRANSITIONAL or otherwise-- if the WG >>>> really feels that it wants to go there and that the old model >>>> might be worth the aggravation that caused it to be dropped the >>>> last time around, I hope that everyone does understand that >>>> TRANSITIONAL, as you and others have described it, is very close >>>> to that old and discarded idea... close enough that we might >>>> even be able to borrow text from documents that are now more >>>> than 18 months old. >>>> >>>> best, >>>> john >>>> >>>> p.s. I'm not going to comment at any length on the "global >>>> mappings" part of your proposal because I think everything has >>>> been said already. Having required global mappings is >>>> equivalent to _almost_ having U-label<-> A-label symmetry. >>>> And, of all mappings, "map to nothing" is the worst: while part >>>> of the problem with a mapping between "=C3=9F" and "ss" is that one >>>> cannot tell by looking at "ss" afterward whether the registrant >>>> intended "ss" or "=C3=9F", one at least knows that "x" or "ab" was >>>> not intended. With "map to nothing", the character that was >>>> eliminated could, in principle, have appeared in any position in >>>> any domain name label. >>>> >>>> >>>> >>>> --On Friday, December 04, 2009 04:11 -0800 Erik van der Poel >>>> wrote: >>>> >>>>> Here is another proposal that is dead simple, yet allows >>>>> implementations to take advantage of a machine-readable file, >>>>> and does not involve "flag days" (dates at which we change >>>>> something). >>>>> >>>>> Instead of having a machine-readable file at each host, we >>>>> have two global files at iana.org. One file is similar to >>>>> Patrik's table with entries like: >>>>> >>>>> 00DF ; DISALLOWED # LATIN SMALL LETTER SHARP S >>>>> 03C2 ; DISALLOWED # GREEK SMALL LETTER FINAL SIGMA >>>>> 200C ; DISALLOWED # ZERO WIDTH NON-JOINER >>>>> 200D ; DISALLOWED # ZERO WIDTH JOINER >>>>> >>>>> There is no new value called TRANSITIONAL. The infamous 4 >>>>> characters (above) start with the value DISALLOWED. Later, we >>>>> change them to PVALID (or CONTEXTJ for 200C/200D). We >>>>> encourage ICANN to redelegate TLDs the registries of which >>>>> flout our rules. >>>> >>>>> The other file is for global mappings. Not language-specific >>>>> mappings. The format might be similar to RFC 3454's: >>>>> >>>>> 0041; 0061; Case map >>>>> 00AD; ; Map to nothing >>>>> >>>>> The absence of a character from this file means that there is >>>>> no mapping for that character. It maps to itself. The infamous >>>>> ... >>>> >>>> _______________________________________________ >>>> Idna-update mailing list >>>> Idna-update@alvestrand.no >>>> http://www.alvestrand.no/mailman/listinfo/idna-update >>>> >>> >>> >>> -----------------------------------------------------------------------= - >>> >>> _______________________________________________ >>> Idna-update mailing list >>> Idna-update@alvestrand.no >>> http://www.alvestrand.no/mailman/listinfo/idna-update >> >> -- >> #-# Martin J. D=C3=BCrst, Professor, Aoyama Gakuin University >> #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > > --0016e6d624692a4525047a3c6b70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Mark,
This is great!=C2=A0 This is like organizing three Y2K!!! Ver= y exciting.

Some suggestions. Some may seem odd, but we need to be p= ractical. Europe has started registering IDNs a few days ago. Fast Track me= mbers will start in a few weeks. So we have to make sure they should suppor= t their non-IDNA2003 registrants, or they should wait for 2015.

- untill 2013 IDNA will continue to resolve IPv4 addresses but from 201= 5 on it will only resolve IPv6.
- it will partly be French compatible in= 2013 and will provide full French support from 2015.
- the cdTLD (chara= cters deviant TLD) ICANN committee should supervise applications compatibil= ity with the the prevailing temporary standard.
- no TLD will be formed in using deviation characters before 2019 in order = to allow the remaining 1% population not to be over embarassed.
- Greek,= Macedonian, Austrian, German, Helevetic, Luxemburghese, Lichensteinese, Eu= ropean, Polish, French, Deutch, Belgium, Governments and Administrations sh= ould be told to make sure that e-government forms adapt to the UTP (Unicode= Transition Plan). Same for banking security applications. Same for every a= pplication using some kind of IRI.
- to make hundred millions of people aware at low cost, we could propose th= e EU Multilingualisation Commissary to make 2013 and 2015 the SSS Sigma &am= p; Eszett years.

We also have to find a way to police the transition= , otherwise we may have many problems (I am sure ICANN is to commission a 2= million dollars study on their identification/evaluation).

Elisabeh Blanconil

2009/12/8 Mark Davis =E2=98=95 <mark@macchiato.com>
>
> Here= 's a modified proposal, a bit rough yet.
> Live page:=C2=A0http://www.= macchiato.com/unicode/idna/transition-proposal
>
> Problem
>
> We would like to have the 4 deviation = characters be valid, at some point. The key problem is that we don't wa= nt current URLs in web pages, etc. to go to two different locations dependi= ng on the browser, nor do we want j= oe@fu=C3=9Fball.com to go=C2=A0sometimes=C2=A0to joe@fu=C3=9Fball.com and=C2=A0sometimes=C2=A0to joe@fussball.com. Even once IDNA2008 is = approved, for a long time a majority of the implementations will still be I= DNA2003, so this also goes for new label registrations during the transitio= n period.
>
> Proposal
>
> IDNA2008 changes as follows:
><= br>> The 4 deviation characters get the property PVALID_AFTER_2015
&g= t; The requirements are:
>
> On registration, PVALID_AFTER_2015= is equivalent to PVALID
> On lookup, PVALID_AFTER_2015 is treated as DISALLOWED up until 2016 Ja= n 1, 00:00:00 GMT, and treated as PVALID thereafter.
>
> Implem= entations must not map the characters after the switchover date.
> > Implementations that map the characters before that date, must map as = in IDNA2003.
>
> The goal is to=C2=A0
>
> allow the= 4 character to become valid, as soon as possible;=C2=A0
> avoid =C2= =A0the 'nightmare' scenario of the same URL going to two different = locations, as much as possible.
>
> Scenarios
>
> Let's see what happens with fu= =C3=9Fball.xxx over time, where xxx is some registry (eg .de, .blogspot.com, or others). Background: essentially a= ll browsers and other major implementations are planning to map for compati= bility. We'll look at browsers, but this also applies to email, etc. >
> Early 2010 (just as IDNA2008 is approved)
>
> At t= his time the world browsers are 100% IDNA2003
>
> browsers map = fu=C3=9Fball.xxx to fussball.xxx.
> registries can start accepting es= zett, and should bundle with ss.
> fu=C3=9Fball shows up as fussball in the address bar
>
> n= ote: it is only by convention that fussball is seen in the address bar in t= his case; a browser could also display fu=C3=9Fball, as in UTS46.
>> results:
>
> if the registry bundles, both fu=C3=9Fball.xxx and fussball.xx= x go to the same owner.
> if the registry doesn't bundle, both fu= =C3=9Fball.xxx and fussball.xxx go to the same owner.
>
> The o= dd IDNA2008 browser that doesn't map just fails, because =C3=9F is not = PVALID; it doesn't take fu=C3=9Fball.xxx to a different location than t= he vast majority of browsers.
>
> In 2013
>
> At this time the world browsers are 50= % IDNA2003, 50% IDNA2008
>
> same as above. No ambiguity in res= ults.
>
> In 2016 Feb
>
> At this time the world br= owsers are 1% IDNA2003, 99% IDNA2008
>
> 99% of browsers switch to not mapping fu=C3=9Fball.xxx.
>= ; Registries no longer need to bundle; they can have different owners for f= u=C3=9Fball.xxx and fussball.xxx.
> fu=C3=9Fball shows up as fu=C3=9F= ball in the address bar
> results:
>
> if the registry bundles, both fu=C3=9Fball.xx= x and fussball.xxx go to the same owner.
> if the registry doesn'= t bundle, fu=C3=9Fball.xxx and fussball.xxx go to different owners.
>=
> The odd IDNA2003 browser that is left goes to the wrong location f= or the affected languages; people that use them need to upgrade.
>
> Mark
>
>
> On Tue, Dec 8, 2009 at 01:44, &qu= ot;Martin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp> wrote:
>>
>> I agree with= Mark that while there are similarities between MAYBE and TRANSITIONAL, the= re are also huge differences.
>>
>> One difference, which Mark has mentioned, is the numbe= r of characters affected.
>>
>> A second difference is th= at there would only be one transition from TRANSITIONAL to PVALID, not a se= ries of transitions from MAYBE to PVALID.
>>
>> A third difference is that MAYBE was essentially sayin= g "we don't have a clue now, we may have later". In my unders= tanding (I didn't participate in any meeting), one of the main reasons = brought by the Unicode side against MAYBE was that if it's MAYBE, we ca= n as well look at the thing and decide now. For TRANSITIONAL, we may know e= xactly what we want to do, it just doesn't fit into PVALID and DISALLOW= ED.
>>
>> BTW, I don't think that any of the dynamic lookup = schemes proposed by Andrew or Eric are feasible, they quite are simply over= engineered. We need something much simpler, even if this temporarily goes a= gainst user convenience.
>>
>> Regards, =C2=A0 Martin.
>>
>> On 200= 9/12/05 6:45, Mark Davis =E2=98=95 wrote:
>>>
>>> I= agree with you that there are many similarities between the MAYBE and
&= gt;>> TRANSITIONAL. MAYBE at the time wasn't suitable because it = was applied to a
>>> huge number of characters. However, applying the concept (with= a few
>>> changes) to these 4 characters for a transitional pe= riod is, I think,
>>> feasible.
>>>
>>>= Mark
>>>
>>>
>>> On Fri, Dec 4, 2009 at 12:40, = John C Klensin<klensin@jck.com>= ; =C2=A0wrote:
>>>
>>>> Once upon a time, not re= ally that long ago, there was a proposal
>>>> to differentiate what is now PVALID by including MAYBE YES= and
>>>> MAYBE NO categories. =C2=A0 Anyone interested shou= ld try to find a
>>>> copy of draft-klensin-idnabis-issues-0= 6.txt and earlier. =C2=A0The
>>>> general model, in today's vocabulary, was to put chara= cters (and
>>>> groups of characters) that we weren't su= re about into categories
>>>> that would encourage different= handling on registration and
>>>> looking from characters about which we were more certain, = to
>>>> permit later reclassification, and to arrange for co= ntrolled
>>>> transitions. =C2=A0There was consensus for rem= oving those categories
>>>> because they made things too fragile, because they would r= equire
>>>> that all registries and applications check for u= pdates and
>>>> changes frequently (which would be too fragi= le), and so on.
>>>>
>>>> In practice, the only real difference = between MAYBE and the sort
>>>> of implied TRANSITIONAL you = imply (or the explicit versions
>>>> others have suggested) = is that MAYBE would have laid out the
>>>> "this is likely to change" aspect of the situati= on more clearly,
>>>> while the idea you outline above raise= s all of the issues that
>>>> the WG has discussed about tra= nsitions from DISALLOWED to PVALID
>>>> (and decided that reclassification should require a catast= rophic
>>>> situation).
>>>>
>>>&= gt; If I remember correctly, both you and Mark were at the meeting
>&= gt;>> at which the decision to drop MAYBE was made and were among
>>>> those pushing for that decision, pretty much on the basis<= br>>>>> outlined above.
>>>>
>>>>= While I don't object to revisiting that general idea -- under
>&= gt;>> the identification of TRANSITIONAL or otherwise-- if the WG
>>>> really feels that it wants to go there and that the old mo= del
>>>> might be worth the aggravation that caused it to be= dropped the
>>>> last time around, I hope that everyone doe= s understand that
>>>> TRANSITIONAL, as you and others have described it, is very= close
>>>> to that old and discarded idea... close enough t= hat we might
>>>> even be able to borrow text from documents= that are now more
>>>> than 18 months old.
>>>>
>>>>= ; best,
>>>> =C2=A0 john
>>>>
>>>= > p.s. I'm not going to comment at any length on the "global >>>> mappings" part of your proposal because I think every= thing has
>>>> been said already. =C2=A0Having required glob= al mappings is
>>>> equivalent to _almost_ having U-label<= ;-> =C2=A0A-label symmetry.
>>>> And, of all mappings, "map to nothing" is the wo= rst: while part
>>>> of the problem with a mapping between &= quot;=C3=9F" and "ss" is that one
>>>> cannot= tell by looking at "ss" afterward whether the registrant
>>>> intended "ss" or "=C3=9F", one at leas= t knows that "x" or "ab" was
>>>> not in= tended. =C2=A0With "map to nothing", the character that was
&g= t;>>> eliminated could, in principle, have appeared in any positio= n in
>>>> any domain name label.
>>>>
>>>= >
>>>>
>>>> --On Friday, December 04, 2009= 04:11 -0800 Erik van der Poel
>>>> <erikv@google.com> =C2=A0wrote:
>>>>
>>>>> Here is another proposal that is d= ead simple, yet allows
>>>>> implementations to take adva= ntage of a machine-readable file,
>>>>> and does not invo= lve "flag days" (dates at which we change
>>>>> something).
>>>>>
>>>>= ;> Instead of having a machine-readable file at each host, we
>>= ;>>> have two global files at iana.org= . One file is similar to
>>>>> Patrik's table with entries like:
>>>&= gt;>
>>>>> 00DF =C2=A0 =C2=A0 =C2=A0 ; DISALLOWED =C2= =A0# LATIN SMALL LETTER SHARP S
>>>>> 03C2 =C2=A0 =C2=A0 = =C2=A0 ; DISALLOWED =C2=A0# GREEK SMALL LETTER FINAL SIGMA
>>>>> 200C =C2=A0 =C2=A0 =C2=A0 ; DISALLOWED =C2=A0# ZERO WI= DTH NON-JOINER
>>>>> 200D =C2=A0 =C2=A0 =C2=A0 ; DISALLOW= ED =C2=A0# ZERO WIDTH JOINER
>>>>>
>>>>>= ; There is no new value called TRANSITIONAL. The infamous 4
>>>>> characters (above) start with the value DISALLOWED. La= ter, we
>>>>> change them to PVALID (or CONTEXTJ for 200C= /200D). We
>>>>> encourage ICANN to redelegate TLDs the r= egistries of which
>>>>> flout our rules.
>>>>
>>>&g= t;> The other file is for global mappings. Not language-specific
>= >>>> mappings. The format might be similar to RFC 3454's: >>>>>
>>>>> 0041; 0061; Case map
>&g= t;>>> 00AD; ; Map to nothing
>>>>>
>>&g= t;>> The absence of a character from this file means that there is >>>>> no mapping for that character. It maps to itself. The = infamous
>>>>> ...
>>>>
>>>>= ; _______________________________________________
>>>> Idna-= update mailing list
>>>> Idna-update@a= lvestrand.no
>>>> http://www.alvestrand.no/mailman/listinfo/idna-= update
>>>>
>>>
>>>
>>> ----------= --------------------------------------------------------------
>>&= gt;
>>> _______________________________________________
>>> Idna-update mailing list
>>> Idna-update@alvestrand.no
>>> http://www.alv= estrand.no/mailman/listinfo/idna-update
>>
>> --
>> #-# Martin J. D=C3=BCrst, Professor, Ao= yama Gakuin University
>> #-# http://www.sw.it.aoyama.ac.jp =C2=A0 mailto:duerst@it.aoyama.ac.jp
>
>
> _______________________________________________
>= ; Idna-update mailing list
> Idna-update@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo= /idna-update


--0016e6d624692a4525047a3c6b70-- From dr.brottier@gmail.com Tue Dec 8 17:32: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 C74063A6A20 for ; Tue, 8 Dec 2009 17:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PSHh3qAYy3lF for ; Tue, 8 Dec 2009 17:32:53 -0800 (PST) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id D82413A6A0F for ; Tue, 8 Dec 2009 17:32:52 -0800 (PST) Received: by ewy1 with SMTP id 1so3573616ewy.28 for ; Tue, 08 Dec 2009 17:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=k8ilteR1Xv0xn5+IF/G4QgplAPAt89dmlRo/zZI6ULQ=; b=GMl8vnLpFCzdebBv759ObegRtmzj0Fp9bshd56/i/k8t/RXtoT4xZlDvGkIduhUTNH bEM7sjU7nCY/MGmDGLhfkTiTQIE7GxzfWieyYZ9hkwcN0GnLCqpt4PbhedwLLHq+Fl+p XmPL7vaYi0T9Grxrfs5ajaryRpbOkh8sSG2JY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nE3p+43qZjO1H0mTxxtWMRqMQcE+EnN3QsZV/ptijkK9123INA5c33xo0JJhCgrk/2 9Dl1PNXszP4WZ5LkOT3yZXRq7TzHLKL7zVxgyweWFwiwbA24jWyeDqc7xVzFbHFisn2g 2vEPLwV6qMzsSbCzvrg7wYjQDUsIKtFelwgbo= MIME-Version: 1.0 Received: by 10.216.89.209 with SMTP id c59mr413669wef.181.1260322357328; Tue, 08 Dec 2009 17:32:37 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Dec 2009 02:32:37 +0100 Message-ID: From: Brottier To: workon@idna2010.org Content-Type: multipart/alternative; boundary=0016e6dab056693ac9047a41aa6f Cc: idna-update@alvestrand.no, iucg@ietf.org Subject: Re: [iucg] IDNA2003/2008 transition 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, 09 Dec 2009 01:35:12 -0000 --0016e6dab056693ac9047a41aa6f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, I meant : 2009/12/9 Maxime Brottier > I have ___been___ explained some of the basic of the IDNA problem. Life i= s > an incremental set of adaptations until it comes to a conflicting > situation. It then resolves it through a "catastrophe" (cf. Ren=E9 Thom's > theory) or/and in a disruptive way (clean sheet) before it resume a new > fractal equilibrium if it did not found it directly. > --=20 Dr. Brottier INRTA --0016e6dab056693ac9047a41aa6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, I meant :

2009/12/9 Maxime Brottie= r <dr.brottie= r@gmail.com>
I have ___been___ explained some of the basic of the IDNA problem. Life is = an incremental set of adaptations until it comes to a=A0 conflicting situat= ion. It then resolves it through a "catastrophe" (cf. Ren=E9 Thom= 's theory) or/and in a disruptive way (clean sheet) before it resume a = new fractal equilibrium if it did not found it directly.
--
Dr. Brottier
INRTA
--0016e6dab056693ac9047a41aa6f-- From jefsey@jefsey.com Tue Dec 8 20:30: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 0E1A03A6902 for ; Tue, 8 Dec 2009 20:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=-1.236, BAYES_50=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 gwfEV0T8gFhy for ; Tue, 8 Dec 2009 20:30:00 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 0E0723A68B8 for ; Tue, 8 Dec 2009 20:30:00 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:2834 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NIEBL-0006ED-ID; Tue, 08 Dec 2009 20:29:48 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Dec 2009 05:28:17 +0100 To: Brottier ,workon@idna2010.org From: jefsey In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit 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: <20091209043000.0E0723A68B8@core3.amsl.com> Cc: iucg@ietf.org Subject: Re: [iucg] IDNA2003/2008/2010 transition 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, 09 Dec 2009 04:30:01 -0000 Cher Drax, Bienvenue ! Merci pour cette contribution qui fait bien le point sur la logique propre de la situation. Merci d'avoir aussi souligné l'aspect du double nommage (accents/sans accents) et des aspects adressage que cela représente. Pour ce qui concerne la position de Google, je crois qu'il faut attendre la conclusion promise par Vint Cerf. Il ne faut pas, je crois, systèmatiquement une volonté de contrôle de la part de Google, mais sans doute une forte lassitude à ce que cela ne bouge pas. J'ai la même. A la fin il faut que tout cela bouge !!!! Il faut une petite équipe de commandos développeurs pour faire avancer les choses. Puis tester. Le point sur les IDNgTLD est bien. C'est le projet Multilinc pour un ULD ("user level domain", en fait un TLD mais déclarés par les fichiers netlocales) par entité linguistique. Et donc des centaines de premiers niveaux euro-asiano-africains qu'il sera difficile de déloger. Mais chaque chose en son temps. Pour l'instant il faudrait que je trouve un développeur C sous Windows pour faire un outil d'installation opérationnel de BIND et de ses additions. Cordialement ! jfc At 02:16 09/12/2009, Brottier wrote: >My advice - but again I am just coming from the outer space and I do >not know you yet. My advice then, would be: >1) to differentiate the linguist requirements from your concerns - >because they are the same in case/for everyone and you are no linguists. >2) to seriously consider the needs of users, specially when they >have the capacity to forget about you and create havoc. >3) to only discuss one layer at a time. In this case, you want to >discuss how the IDNA can support what (1) and (2) demand. > >I am not a network engineer. But I heard some explanations which >make sense to me. There is a basic flaw in your model: the diversity >of possible IDNA modules. Not only in the network, but also on the >same machine; may be even in the same utilization. This is an >additional reason for you to go fast (before there are too many >incompatible modules). Then to stabilize on a case by case basis. >Between Google, Users and ICANN Fast Track (including motivated test >IDNgTLDs). Otherwise IMHO your problem will not be the Greek and >German "s's", but a game over decided by Asia and Users. From jmabdp@gmail.com Wed Dec 9 18:33:40 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 2D6EB3A6945 for ; Wed, 9 Dec 2009 18:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, 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 zeQdNqR3ZkTB for ; Wed, 9 Dec 2009 18:33:38 -0800 (PST) Received: from mail-yw0-f201.google.com (mail-yw0-f201.google.com [209.85.211.201]) by core3.amsl.com (Postfix) with ESMTP id 4B0203A6829 for ; Wed, 9 Dec 2009 18:33:38 -0800 (PST) Received: by ywh39 with SMTP id 39so3425233ywh.17 for ; Wed, 09 Dec 2009 18:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=S65JKPqqBInzcUSHg8cHFLDlDiSWO+MMzX9J+qZwAjQ=; b=shmRHuujgYC9GEpI68wzMh4BodzKhC64SbIS/gKVBLu9Qqa0RgGXH7d/kYmxFyHMNf ZXlP/vyvISux45vf7Cj8H5R9eMGA6bivJqyyDPJrmCe2k5mktCh2lFhw2OYIUGgiQInv +FcaEplcd/TIvK0qfhDuQ+mZpfWN6IYfOqleU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VwXaKRnOddgh4zgRTlGxXyrc0iuWei16+Gl3qV9nav9okxT/y8njs3CGuIJ04eHy11 8eipj/mPf9a45eqbE9QsriWrX9x69aGCGLnLjRJMfeYvntckOTR78VjfWsaztoTqMuLz r5wOhMAcIcp7Mb1Ze4YXmpq0Ghu2npNSlWGmk= MIME-Version: 1.0 Received: by 10.101.3.36 with SMTP id f36mr8899871ani.197.1260412404120; Wed, 09 Dec 2009 18:33:24 -0800 (PST) In-Reply-To: <200912100110.nBA1Agw10772@birdie.sybase.com> References: <200912100110.nBA1Agw10772@birdie.sybase.com> Date: Thu, 10 Dec 2009 03:33:24 +0100 Message-ID: <6aad7a210912091833l6f60a4dah5efce528319a47b@mail.gmail.com> From: jean-michel bernier de portzamparc To: Kenneth Whistler Content-Type: multipart/alternative; boundary=0016368e29359e3b44047a56a182 Cc: workon@idna2010.org, IDNA update work , internet users contributing group Subject: Re: [iucg] Prohibiting mapping of PVALID characters 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, 10 Dec 2009 02:33:40 -0000 --0016368e29359e3b44047a56a182 Content-Type: text/plain; charset=ISO-8859-1 Dear colleagues, fascinating is the way our Unicode fellow Members are going to "oppose the charter, disregard a consensus, reverse a 80% feed back, force the Chair to "change his mind" and most probably its consensus evaluation, imposing their interest to their commercial competition, and writing themseleves a paper legitimacy against the demand of their own users they most probably are certain they can influence in the same manner". Also fascinating to realize that all this small group of "60 Hz" people effort is void. The 60hzians' strategy already failed on TATWEEL. This was due to the reasonable positions of Siavash Shahshahani and Roozbeh Pournader. Users' interest and number and technical influence is moving to the workon@idna2010.org subscribers diversity. Portzamparc NB. Microsoft's position regarding the French language has now been archived as an important pre-experimentation input http://iucg.org/wiki/Microsoft_IRT_the_French_language_orthotypography - comments welcome. 2009/12/10 Kenneth Whistler > Paul, > > > >Protocol, 5.2: > > > > > >5.2. Conversion to Unicode > > > > > >The string is converted from the local character set into > > >Unicode, if it is not already in Unicode. Depending on local > > >needs, this conversion may involve mapping some characters > > >into other characters as well as coding conversions... > > >The results MUST be a Unicode string in NFC form. > > > > > > > > >Strings don't magically get to be "in NFC form", without > > >being mapped (via normalization algorithm) from whatever form > > >they started out as, *into* NFC form. > > > > In this case, yes they do. That "MUST" is probably wrong; I believe > > that the statement is meant to say "The results will be a > > Unicode string in NFC form". > > > > John, et. al.: is my understanding correct here? > > I repeat: strings do not turn into NFC form by magic. They > are mapped by the normalization algorithm. And that mapping > involves, necessarily, PVALID --> PVALID characters in > this case. > > And "the results" will not be a "Unicode string in NFC form" > unless it is mapped to that. (Except of course, by accident, > if it happens to start out as NFC in the first place.) > > I think what you may be trying to get at is a requirement that > the only valid *input* to the label processing is a string > which is already a Unicode string in NFC form -- and that > how it got to be that way and indeed whether it started out > as a string in SJIS or 8859-7 or whatever, is beyond the > protocol's scope of caring. > > But if that is the case, then why are we talking about trying > to add into Section 5.2 a prohibition (a MUST NOT) against > mapping PVALID characters? Because manifestly, for any > actual implementation to meet the requirement of having > Unicode strings in NFC format as valid input for the label > processing, it MUST map strings (including PVALID > characters) using the Unicode normalization algorithm. > > I understand that maybe you want to say that that isn't > a requirement *in* the protocol -- it is simply a requirement > on the well-formedness of valid input to be handled as > labels. And maybe I don't understand how you distribute > the MUSTs, SHOULDs and wills around the document to accomplish > that. > > But my essential point here is that you cannot have you cake > and eat it too -- trying to prohibit mapping of PVALID > characters in Section 5.2 at the same time that you > are requiring mapping of PVALID characters in Section 5.2 -- > however the exact protocol wordsmanship of that gets > worked out. > > Maybe you can, for example, prohibit *case* mapping of PVALID > characters in Section 5.2, while requiring canonical > normalization mapping of PVALID characters to NFC. That > at least would be a coherent position. But you cannot > just prohibit mapping and require mapping of the same > class of characters, without being more discriminating > in what you mean. > > --Ken > > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --0016368e29359e3b44047a56a182 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear colleagues,

fascinating is the way our Unicode fellow Members are going to "oppose= the charter, disregard a consensus, reverse a 80% feed back, force the Cha= ir to "change his mind" and most probably its consensus evaluatio= n, imposing their interest to their commercial competition, and writing the= mseleves a paper legitimacy against the demand of their own users they most= probably are=A0 certain they can influence in the same manner".=A0
Also fascinating to realize that all this small group of "60 Hz" = people effort is void. The 60hzians' strategy already failed on TATWEEL= . This was due to the reasonable positions of Siavash Shahshahani and Roozb= eh Pournader. Users' interest and number and technical influence is mov= ing to the workon@idna2010.org s= ubscribers diversity.

Portzamparc

NB. Microsoft's position regarding the French language has now been arc= hived as an important pre-experimentation input http://iucg.org/wik= i/Microsoft_IRT_the_French_language_orthotypography - comments welcome.=


2009/12/10 Kenneth Whistler <kenw@sybase.com>=
Paul,

> >Protocol, 5.2:
> >
> >5.2. Conversion to Unicode
> >
> >The string is converted from the local character set into
> >Unicode, if it is not already in Unicode. Depending on local
> >needs, this conversion may involve mapping some characters
> >into other characters as well as coding conversions...
> >The results MUST be a Unicode string in NFC form.
> >
> >
> >Strings don't magically get to be "in NFC form", wit= hout
> >being mapped (via normalization algorithm) from whatever form
> >they started out as, *into* NFC form.
>
> In this case, yes they do. That "MUST" is probably wrong; I = believe
> that the statement is meant to say "The results will be a
> Unicode string in NFC form".
>
> John, et. al.: is my understanding correct here?

I repeat: strings do not turn into NFC form by magic. They
are mapped by the normalization algorithm. And that mapping
involves, necessarily, PVALID --> PVALID characters in
this case.

And "the results" will not be a "Unicode string in NFC form&= quot;
unless it is mapped to that. (Except of course, by accident,
if it happens to start out as NFC in the first place.)

I think what you may be trying to get at is a requirement that
the only valid *input* to the label processing is a string
which is already a Unicode string in NFC form -- and that
how it got to be that way and indeed whether it started out
as a string in SJIS or 8859-7 or whatever, is beyond the
protocol's scope of caring.

But if that is the case, then why are we talking about trying
to add into Section 5.2 a prohibition (a MUST NOT) against
mapping PVALID characters? Because manifestly, for any
actual implementation to meet the requirement of having
Unicode strings in NFC format as valid input for the label
processing, it MUST map strings (including PVALID
characters) using the Unicode normalization algorithm.

I understand that maybe you want to say that that isn't
a requirement *in* the protocol -- it is simply a requirement
on the well-formedness of valid input to be handled as
labels. And maybe I don't understand how you distribute
the MUSTs, SHOULDs and wills around the document to accomplish
that.

But my essential point here is that you cannot have you cake
and eat it too -- trying to prohibit mapping of PVALID
characters in Section 5.2 at the same time that you
are requiring mapping of PVALID characters in Section 5.2 --
however the exact protocol wordsmanship of that gets
worked out.

Maybe you can, for example, prohibit *case* mapping of PVALID
characters in Section 5.2, while requiring canonical
normalization mapping of PVALID characters to NFC. That
at least would be a coherent position. But you cannot
just prohibit mapping and require mapping of the same
class of characters, without being more discriminating
in what you mean.

--Ken


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

--0016368e29359e3b44047a56a182-- From jefsey@jefsey.com Wed Dec 9 20:03: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 6E0293A69B0 for ; Wed, 9 Dec 2009 20:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 6ZCoas80jQpn for ; Wed, 9 Dec 2009 20:03:53 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 375EF3A695A for ; Wed, 9 Dec 2009 20:03:53 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:3112 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NIaFe-0007P3-Fu; Wed, 09 Dec 2009 20:03:40 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Dec 2009 05:03:33 +0100 To: internet users contributing group , Kenneth Whistler From: JFC Morfin In-Reply-To: <6aad7a210912091833l6f60a4dah5efce528319a47b@mail.gmail.com > References: <200912100110.nBA1Agw10772@birdie.sybase.com> <6aad7a210912091833l6f60a4dah5efce528319a47b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091210040353.375EF3A695A@core3.amsl.com> Cc: workon@idna2010.org, internet users contributing group , arabic Scripts IDNA Subject: Re: [iucg] Prohibiting mapping of PVALID characters 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, 10 Dec 2009 04:03:54 -0000 At 03:33 10/12/2009, jean-michel bernier de portzamparc wrote: >fascinating is the way our Unicode fellow Members are going to >"oppose the charter, disregard a consensus, reverse a 80% feed back, >force the Chair to "change his mind" and most probably its consensus >evaluation, imposing their interest to their commercial competition, >and writing themseleves a paper legitimacy against the demand of >their own users they most probably are certain they can influence >in the same manner". Thank you to quote me! However, the current effort is _NOT_ void !!! The Internet standard process requires a certain decorum, otherwise the IETF would be flooded. We known very well that the Chair would try to insert one "MUST" or two between the IETF/LC and the IESG. The current debate is about why he wants to do it, and what IESG will think and decide about it. The issue in front of the IESG at this occasion is the following : who should have the IETF leadership (cf. RFC 3935 which describes the leadership and its role): - (a) those who consider the better for the machines - (b) those who consider the better for the people or - (c) those who try to uncover the best for both - (c) those who consider the better for their own agenda This is not a trivial matter. It MUST be treated with the greatest care. And we will certainly appeal if it was not, because we all need a clear and documented position which is missing in RFC 3935. RFC 3935 says that the IETF must influence those who design, use and manage the Internet for it to work better. But it does not say better for who, and what better means. We MUST know it. This is no contention. This is necessity. For example, we cannot talk of network neutrality if we do not state that before. This also is true for ISOC and ICANN. So, we might have to escalate an appeal to ISOC if we do get a clear answer (we being the Internet community). Life is necessarily made of decisions that some people will take as bias. This Internet has a linguistic bias, we must know which is its priority bias. - we known the Chair favors "a". James Seng has been very clear about it and he confirmed. - politically most of people favor "b". We have people like Patrick Yeu reminding us all the day long. - we are many to feel (specially due to Fast Track and IDNgTLDs) that ICANN favors "d", and we cannot accept that as stable until it is clarified - but if we want to serve people with something which works "c" is necessary. This is why the current debate and its review by the IESG (and IAB, and ISOC if we had to escalate an appeal of it) is very important and MUST be very seriously considered. Also, technically a new fractal element just came in with Andrew Sullivan. I wrote a Draft on IDNA being a smooth Transition paradigm for the IETF. Another on IETF precautionary duty. Andrew has introduced the concept of a transition in this transition. Then Shawn Steele just introduced the idea of a transition _within_ an IETF consensus as acceptable, depending on the outcome of further debate. This is rather new. Disturbing on a large scale, but may be vital on a microecosystem one It is too bad that we wasted so much time. All the WG work could have been wraped-up in three months, and most of the time spent on the two fundamental questions we now have to see addressed in the new Internet context (greatest change on 40 years, says ICANN). - who is the IETF working for? what does "better" mean for the Internet ? - wht about transition as a part of the Internet architecture and IETF process? We must listen, ask, require clarifications to be sure we all understand each others on these points. This can call for a lot of time if the points are disregarded (three appeals). Or can be very quick. The document that Vint promised will a first key indication. jfc From jmabdp@gmail.com Thu Dec 10 16:51:02 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 AE81C3A685E for ; Thu, 10 Dec 2009 16:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, 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 nC3c5JvpUUQL for ; Thu, 10 Dec 2009 16:51:02 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 31D623A683D for ; Thu, 10 Dec 2009 16:51:01 -0800 (PST) Received: by yxe30 with SMTP id 30so422641yxe.29 for ; Thu, 10 Dec 2009 16:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=D6NAHV4q9dIYksaZvWzKZ7cgc1faNqbHYqhricRJBIk=; b=pkEDfaB+/EzdbZeDAP2vAS+05V54sVf6aS4jq0CphcnRmKhHUCpAfi/1yT4dD17ORB uum40PXaXZEFy1Mfj0F/r6KvRZST825XkqK3UkIya8i3s0RAJLZ6Gw8DzpmgTBfHV4G4 tb0mhAUqitHj0VgDoO7CHYXGC0tLUUz/5g7yc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ZqpHyMMzaC3k+EjVeIpyUN+K29UnNtNH7JIjE87rIYCT+nO8q7WI9cgrFqFRGfXt8L Uo+v5TgVKWuwTgYjP4pRKw53K5DWSW7vHUUzB/dCPxYHbrgajZPfhtGtEaPe979vOtl8 S/jvGf3V8dEm5K589oZnrdMRZG0x1QsfPPgfk= MIME-Version: 1.0 Received: by 10.101.190.12 with SMTP id s12mr1150704anp.31.1260492645622; Thu, 10 Dec 2009 16:50:45 -0800 (PST) Date: Fri, 11 Dec 2009 01:50:45 +0100 Message-ID: <6aad7a210912101650w7b8a56efoc8b4fbed89adc774@mail.gmail.com> From: jean-michel bernier de portzamparc To: workon@idna2010.org Content-Type: multipart/alternative; boundary=00163691fd40626582047a695031 Cc: IDNA update work , internet users contributing group Subject: [iucg] starting points 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, 11 Dec 2009 00:51:02 -0000 --00163691fd40626582047a695031 Content-Type: text/plain; charset=ISO-8859-1 Dear colleagues, I suggest that we start by discussing the basic principles of our working framework in order to document IDNA2010, which is to be an open, better usage wrap-up of IDNA2008/2003. A. we establish, as a principle, that we do not discuss IDNA or build from IDNA, but rather describe the IDNA2010 conventions, and then make sure that they conform, or are transparent, to IDNA2008 B. in so doing, we adopt a pragmatic unsophisticated straightforward approach that is adequate for end users from all walks of life and cultures. Portzamparc. --00163691fd40626582047a695031 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear colleagues,
I suggest that we start by discussing the basic principles of our working f= ramework in order to document IDNA2010, which is to be an open, better usag= e wrap-up of IDNA2008/2003.

A. we establish, as a principle, that we do not discuss IDNA or build from = IDNA, but rather describe the IDNA2010 conventions, and then make sure that= they conform, or are transparent, to IDNA2008

B. in so doing, we adopt a pragmatic unsophisticated straightforward approa= ch=A0 that is adequate for end users from all walks of life and cultures. <= br>
Portzamparc. --00163691fd40626582047a695031-- From jefsey@jefsey.com Thu Dec 10 17:28: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 CCED43A693B for ; Thu, 10 Dec 2009 17:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] 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 WInY41E2CsJC for ; Thu, 10 Dec 2009 17:28:12 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id F00363A6848 for ; Thu, 10 Dec 2009 17:28:11 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1408 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NIuIO-0004iA-AK; Thu, 10 Dec 2009 17:27:48 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Dec 2009 02:27:43 +0100 To: IDNA2010 Documentation From: JFC Morfin In-Reply-To: <6aad7a210912101650w7b8a56efoc8b4fbed89adc774@mail.gmail.co m> References: <6aad7a210912101650w7b8a56efoc8b4fbed89adc774@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091211012811.F00363A6848@core3.amsl.com> Cc: internet users contributing group , arabic Scripts IDNA Subject: Re: [iucg] [workon] starting points 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, 11 Dec 2009 01:28:12 -0000 At 01:50 11/12/2009, jean-michel bernier de portzamparc wrote: >Dear colleagues, >I suggest that we start by discussing the basic principles of our >working framework in order to document IDNA2010, which is to be an >open, better usage wrap-up of IDNA2008/2003. So we establish the context. Not the rationale? Suits me if we also jump at some running code and test users. Could be faster and simpler. I tend to modelize too much :-). >A. we establish, as a principle, that we do not discuss IDNA or >build from IDNA, but rather describe the IDNA2010 conventions, and >then make sure that they conform, or are transparent, to IDNA2008 I committed to build on top of IDNA2008, this is your show. I understand that if I am to appeal against IDNA2008 on "technical background" this might create a confusion. I am working on a position statement that puts the ball in Vint's field. A little more complicated because ICANN is not playing fair in all this, but rough position: if you do not impeach network neutrality (now or in the future due to jurisprudence) I am OK. If you do, we opposed enough the idea as an architectural violation, not to accept it now. In any case, the background question: who decides of human cultures - IETF, people or both in common - does not affect the protocols as you name it. It affects its deployment and permit ICANN [Fast Track] and Google [GDNS] to over influence the market in a centralised/decentralised direction which contradicts the decentralised nature of usage, and the possibility to establish users conventions. As in charge of the Project.FRA, the test for me is simple: when at the earliest .FRA can be in the NTIA Root file? If this is in May 2010 it is OK, if not there will be a problem. Same for the Multilinc zones. >B. in so doing, we adopt a pragmatic unsophisticated straightforward >approach that is adequate for end users from all walks of life and cultures. Here are the straightforward starting points that I am suggesting: 1. "Protocols" are the procedures that are documented by the IETF. We call "Conventions" the mutual understandings insuring Interplus "b2b" (i.e. "[inter]box2box", "[inter]boitaboite") interintelligibility. 2. UDNs are whatever users may enter in an application that will eventually lead to an Internet Protocol IPv4 or IPv6 address resolution. 3. LDNs are whatever local usages/zone rules are supposed to massage/restrict UDNs into. 4. ADNs are whatever applications may accept in the domain name locations of the IETF protocols. 5. IDNs are "Interplus Domain Names", i.e. whatever both the Internet Name to Address resolution system (currently the "DNS") _and_ the Interplus will accept as valid inputs. 6. DNs are whatever the Internet Name to Address resolution system (currently the "DNS") accepts as valid inputs. 7. Every IDN registration is based upon the WYRISYG convention ("what you register is what you get") that does not imply any IDN specific responsibility. jfc From jmabdp@gmail.com Thu Dec 10 18:40:14 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 635DE3A69AA for ; Thu, 10 Dec 2009 18:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, SARE_MILLIONSOF=0.315] 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 YbDEtjXqsEkK for ; Thu, 10 Dec 2009 18:40:12 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id AE9B23A68C1 for ; Thu, 10 Dec 2009 18:40:11 -0800 (PST) Received: by yxe30 with SMTP id 30so501679yxe.29 for ; Thu, 10 Dec 2009 18:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=r695AtpIF83E5NaGkfatgYB3OEH5YY8Rg04UQ9OfyiQ=; b=R1xMHivWKPuAK6sruxIG9k3BFn70kJe4OlmjhfLdCSl0rwfiYNEQubz+20syHJ/XMg tcn6ctjilHTeasWbN4t7ZDjnQBspK51RhMrwG7whQJnN9aFsPjthchHQPGRo15X7mn/N FJWR2Mx4Iyaf6Rj9h00O5mUV9GrSlt1PEDtV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UNVxfes+rOA+IHISvwAkuV4cZypKPDnDBp+mb4Yb/q33DEdysiYRL1XHdJKnTYRg/R Gzn8yZRCCOze0F7w2WxKXkSDoq/iSS22rRSn4KUNJ4WBAX/rxeFcZM/pLsDKtmzE6vV3 24qK1BPA3802TjZ1scssIfqjaxfvUaaUcVcuM= MIME-Version: 1.0 Received: by 10.101.151.30 with SMTP id d30mr1184338ano.135.1260499188412; Thu, 10 Dec 2009 18:39:48 -0800 (PST) In-Reply-To: <20091211012811.F00363A6848@core3.amsl.com> References: <6aad7a210912101650w7b8a56efoc8b4fbed89adc774@mail.gmail.com> <20091211012811.F00363A6848@core3.amsl.com> Date: Fri, 11 Dec 2009 03:39:48 +0100 Message-ID: <6aad7a210912101839l7b7e509t40619cd8d6764886@mail.gmail.com> From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=001636c927aa5d8a7d047a6ad619 Cc: IDNA2010 Documentation , arabic Scripts IDNA Subject: Re: [iucg] [workon] starting points 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, 11 Dec 2009 02:40:14 -0000 --001636c927aa5d8a7d047a6ad619 Content-Type: text/plain; charset=ISO-8859-1 2009/12/11 Paul Hoffman At 1:50 AM +0100 12/11/09, jean-michel bernier de portzamparc wrote: >Dear colleagues, >I suggest that we start by discussing the basic principles of our working framework in order to document IDNA2010, which is to be an open, better usage wrap-up of IDNA2008/2003. Please remove the idna-update@alvestrand.no from these messages and any replies. It is completely inappropriate for the WG. Thanks! Dear Paul, I am sorry. This is strictly carried according to the IUCG non-WG mission and charter. We are to help structured contributions of Internet Users to the work of Internet Engineers. Our concerns are the user side continuation of this WG Charter: "Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards- compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies". The interest of workon@idna2010.org (which was established a few weeks ago) is in discussing the usage transition between IDNA2003 (with hundred of millions of users) and the proposed IDNA2008 that is now completed (cf. the Chair). The problem is now with us. We have gathered people interested in discussing it of different origin and responsibility. We start working because there are several delayed experimentations and projects (this WG was supposed to last a few months and complete its work one year ago). It now turns out that an "after last minute" debate has eventually started on matter we consider in our scope and of importance. . We certainly want to cooperate and make sure no unnecessary misunderstanding happens (both ways) while we are in the process of taking the con over. 2009/12/11 JFC Morfin > At 01:50 11/12/2009, jean-michel bernier de portzamparc wrote: > >> Dear colleagues, >> I suggest that we start by discussing the basic principles of our working >> framework in order to document IDNA2010, which is to be an open, better >> usage wrap-up of IDNA2008/2003. >> > > OK. > > A. we establish, as a principle, that we do not discuss IDNA or build from >> IDNA, but rather describe the IDNA2010 conventions, and then make sure that >> they conform, or are transparent, to IDNA2008 >> > > I committed to build on top of IDNA2008, this is your show. I understand > that if I am to appeal against IDNA2008 on "technical background" this might > create a confusion. I am working on a position statement that puts the ball > in Vint's field. A little more complicated because ICANN is not playing fair > in all this, but rough position: if you do not impeach network neutrality > (now or in the future due to jurisprudence) I am OK. If you do, we opposed > enough the idea as an architectural violation, not to accept it now. > We are waiting for it. At least one ccTLD has expressed its interest to review it with you. > In any case, the background question: who decides of human cultures - IETF, > people or both in common - does not affect the protocols as you name it. It > affects its deployment and permit ICANN [Fast Track] and Google [GDNS] to > over influence the market in a centralised/decentralised direction which > contradicts the decentralised nature of usage, and the possibility to > establish users conventions. As in charge of the Project.FRA, the test for > me is simple: when at the earliest .FRA can be in the NTIA Root file? If > this is in May 2010 it is OK, if not there will be a problem. Same for the > Multilinc zones. > > > B. in so doing, we adopt a pragmatic unsophisticated straightforward >> approach that is adequate for end users from all walks of life and >> cultures. >> > > Here are the straightforward starting points that I am suggesting: > > 1. "Protocols" are the procedures that are documented by the IETF. We call > "Conventions" the mutual understandings insuring Interplus "b2b" (i.e. > "[inter]box2box", "[inter]boitaboite") interintelligibility. > Yes. We had agreed that yesterday to avoid confision between IUCG and IETD deliverables. > > 2. UDNs are whatever users may enter in an application that will eventually > lead to an Internet Protocol IPv4 or IPv6 address resolution. > > 3. LDNs are whatever local usages/zone rules are supposed to > massage/restrict UDNs into. > > 4. ADNs are whatever applications may accept in the domain name locations > of the IETF protocols. > > 5. IDNs are "Interplus Domain Names", i.e. whatever both the Internet Name > to Address resolution system (currently the "DNS") _and_ the Interplus will > accept as valid inputs. > > 6. DNs are whatever the Internet Name to Address resolution system > (currently the "DNS") accepts as valid inputs. > > 7. Every IDN registration is based upon the WYRISYG convention ("what you > register is what you get") that does not imply any IDN specific > responsibility. > This is an important point. It certainly addresses the WG debate in an Internet User straightfroward manner. The responsibility (and autonomous decision) is left to the User. Thank you Mr. Engineer and Mrs. Zone Manager. We are grown boys, we have consultants, we have many different needs you never considered. This really is what we want. I like the formula as it clearly expresses that we do not want any "simplifying" complex confusion. Question is: is WYRIWYG an acceptable position? Portzamparc --001636c927aa5d8a7d047a6ad619 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/12/11 Paul Hoffman <phoffman@imc.org>
At 1:50 AM +010= 0 12/11/09, jean-michel bernier de portzamparc wrote:
>Dear colleagues,
>I suggest that we start by discussing the basic principles of our working framework in order to document IDNA2010, which is to be an open, better usage wrap-up of IDNA2008/2003.

Please remove the idna-u= pdate@alvestrand.no from these messages and any replies. It is complete= ly inappropriate for the WG. Thanks!

Dear Paul,

I am sorry. This is strictly carried according to the IUCG non-WG mission a= nd charter. We are to help structured contributions of Internet Users to th= e work of Internet Engineers. Our concerns are the user side continuation o= f this WG Charter: "Subject to the more general constraints described = above, the WG is permitted to consider changes that are not strictly backwa= rds- compatible.=A0 For any such change that is recommended, it is expected= to document the reasons for the change, the characters affected, and possi= ble transition strategies".

The interest of workon@idna2010.org<= /a> (which was established a few weeks ago) is in discussing the usage tran= sition between IDNA2003 (with hundred of millions of users) and the propose= d IDNA2008 that is now completed (cf. the Chair). The problem is now with u= s. We have gathered people interested in discussing it of different origin = and responsibility. We start working because there are several delayed expe= rimentations and projects (this WG was supposed to last a few months and co= mplete its work one year ago). It now turns out that an "after last mi= nute" debate has eventually started on matter we consider in our scope= and of importance. .

We certainly want to cooperate and make sure no unnecessary misunderstandin= g happens (both ways) while we are in the process of taking the con over.

2009/12/11 JFC Morfin = <jefsey@jefsey.com>
At 01:50 11/12/2009, jean-michel bernier de portzamparc w= rote:
Dear colleagues,
I suggest that we start by discussing the basic principles of our working f= ramework in order to document IDNA2010, which is to be an open, better usag= e wrap-up of IDNA2008/2003.


OK. =A0

A. we establish, as a principle, that we do not discuss IDNA or build from = IDNA, but rather describe the IDNA2010 conventions, and then make sure that= they conform, or are transparent, to IDNA2008

I committed to build on top of IDNA2008, this is your show. I understand th= at if I am to appeal against IDNA2008 on "technical background" t= his might create a confusion. I am working on a position statement that put= s the ball in Vint's field. A little more complicated because ICANN is = not playing fair in all this, but rough position: if you do not impeach net= work neutrality (now or in the future due to jurisprudence) I am OK. If you= do, we opposed enough the idea as an architectural violation, not to accep= t it now.

We are waiting for it.
At least one ccTLD has expr= essed its interest to review it with you.


In any case, the background question: who decides of human cultures - IETF,= people or both in common - does not affect the protocols as you name it. I= t affects its deployment and permit ICANN [Fast Track] and Google [GDNS] to= over influence the market in a centralised/decentralised direction which c= ontradicts the decentralised nature of usage, and the possibility to establ= ish users conventions. As in charge of the Project.FRA, the test for me is = simple: when at the earliest .FRA can be in the NTIA Root file? If this is = in May 2010 it is OK, if not there will be a problem. Same for the Multilin= c zones.


B. in so doing, we adopt a pragmatic unsophisticated straightforward approa= ch =A0that is adequate for end users from all walks of life and cultures.

Here are the straightforward starting points that I am suggesting:

1. "Protocols" are the procedures that are documented by the IETF= . We call "Conventions" the mutual understandings insuring Interp= lus "b2b" (i.e. "[inter]box2box", "[inter]boitaboi= te") interintelligibility.

Yes. We had agreed that yesterday to avoid confision = between IUCG and IETD deliverables.
=A0

2. UDNs are whatever users may enter in an application that will eventually= lead to an Internet Protocol IPv4 or IPv6 address resolution.

3. LDNs are whatever local usages/zone rules are supposed to massage/restri= ct UDNs into.

4. ADNs are whatever applications may accept in the domain name locations o= f the IETF protocols.

5. IDNs are "Interplus Domain Names", i.e. whatever both the Inte= rnet Name to Address resolution system (currently the "DNS") _and= _ the Interplus will accept as valid inputs.

6. DNs are whatever the Internet Name to Address resolution system (current= ly the "DNS") accepts as valid inputs.

7. Every IDN registration is based upon the WYRISYG convention ("what = you register is what you get") that does not imply any IDN specific re= sponsibility.

This is an important point. It certainly addresses the WG debate in an Inte= rnet User straightfroward manner. The responsibility (and autonomous decisi= on) is left to the User. Thank you Mr. Engineer and Mrs. Zone Manager. We a= re grown boys, we have consultants, we have many different needs you never = considered. This really is what we want. I like the formula as it clearly e= xpresses that we do not want any "simplifying" complex confusion.=

Question is: is WYRIWYG an acceptable position?

Portzamparc
=
--001636c927aa5d8a7d047a6ad619-- From jefsey@jefsey.com Thu Dec 10 20:37:49 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 21F813A691D; Thu, 10 Dec 2009 20:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 8xfwGqGHAYSI; Thu, 10 Dec 2009 20:37:47 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id DC1BC3A68B9; Thu, 10 Dec 2009 20:37:47 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:2259 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NIxFy-0004GT-6A; Thu, 10 Dec 2009 20:37:30 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Dec 2009 05:37:24 +0100 To: iesg@ietf.org From: jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091211043747.DC1BC3A68B9@core3.amsl.com> Cc: John C Klensin , "patrik@frobbit.se" , Vint Cerf , iucg@ietf.org, Lisa Dusseault Subject: [iucg] The same problem once more 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, 11 Dec 2009 04:37:49 -0000 Dear IESG Members, We known very well that the WG/IDNABIS Chair would try to insert one "MUST" or two, between the IETF/LC appoving a no "MUST" (hence technically flexible) document set and the IESG. This is what is currently attempted. Now, we have progressed a lot since the first BCP47 days. Our duty and our ability is to understand why he wants so much to do it, what are his architectural grounds (we feel they are rooted in a centralized evaluation of the influence the Internet would need from his point of viw, but we may be wrong), and what the IESG will think and decide about it. This is not an easy task for you. But it is a fundamental point that must eventually be clarified. So I we are not anymore obliged to progressively and painstakingly force the clarification. The true issue in front of the IESG at this occasion is again the following: "who should hold the IETF leadership (cf. RFC 3935 describes the leadership and its role): - (a) those who consider what is better for the machines - (b) those who consider what is better for the people - (c) those who try to uncover the best for both or, - (c) those who consider what is better for their own agenda." This is not a trivial matter and the more we are to go multicultural the more it becomes the top issue. It MUST now be treated and it MUST be now answered with the greatest care. We will certainly appeal if this was not the case. Not because I would love it. Nor by habit. But because we all/the world need a formal and documented position that is clearly missing in RFC 3935. And we need that position because it is an important part of the IETF architecture and strategic credibility. RFC 3935 states that the IETF must influence those who design, use, and manage the Internet in such a way as to make the Internet work better. However, it does not state as to what is better for who or what 'better' actually means. We MUST know that answer. There is no contention here. This is an architectural imperative. For example, we cannot talk of network neutrality if we do not state a response to that question beforehand. This also is true for ISOC and ICANN. Therefore, we might have to escalate an appeal to the ISOC if we do not receive a clear answer from them ('we' being the Internet community). Life is necessarily made of decisions that some people will view as a bias. The Internet has a linguistic bias (ASCII English, RFC 3935: "The IETF uses the English language for its work is because of its utility for working in a global context"). We know that and the work we carried those two last years must help addressing it. We know the IETF has a cultural bias (RFC 3935: The Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. ... These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create)." We need to know if the IETF wants to impose its views to the world by the mean of its not value-neutral technology. We also must know what its priority bias is. - we known that the Chair favors the "a" group. James Seng has been very clear about it and he confirmed. - politically most of people and business users claim they belong to "b" group. We have people like Patrick Yeu in France reminding us all day long. - we are an increasing number who feel (especially due to the Fast Track and IDNgTLDs disloyalty) that ICANN is under "d" influcene. This is something we cannot accept as stable until it is further clarified. - but if we want to serve people with something that works, then "c" is necessarily to arbitrate. This is the current "after the limit" debate that occured at the WG/IDNABIS. Its review by the IESG (and IAB, and ISOC and GAC if we have to appeal and then to escalate a first appeall) is very important and MUST be very seriously considered. On pure technical feasibility grounds (we do not want another IPv6 or DNSSEC saga). Because we keep in mind that imposing cultural changes on technical grounds is an architectural layer violation that will certainly not work on the long term. In addition, a new fractal element just technically came in with Andrew Sullivan. I wrote a Draft on IDNA as a smooth Transition paradigm for the IETF and another one on IETF precautionary duty. During what I call the WYRIWIG (what you register is what you get) debate, Andrew Sullivan has introduced the concept of a transition within this transition. Still more recently, Shawn Steele introduced the idea of a transition _within_ an IETF consensus as acceptable, depending on the outcome of further debates and who is considered as a "valid" participant or as "noise". This possibility of "iterative reversion of selective consensus" is rather new at the IETF and might conflict or even oppose with the rough consensus fundamentals (a consensus is no more something of which the AD can build archives). Transitioning is a rather difficult processus we consider for years at the global internet level and scale. It may also be very important to consider it at the "initial conditions" scale of the system of a WG. This is a general dynamization of the Internet culture. It is interesting and exciting. But this definitly is no part of the WG/IDNABIS Charter. It is too bad that we have wasted so much time. All of the WG work could have been wrapped-up in just three months as documented in the Charter. Most of the time we used could have been spent on (in the very pertinent to the matter case of internationalization) the two fundamental questions that we now have to see addressed by the WG/INDABIS. In the new Internet context (greatest change in 40 years, says ICANN, which may blurr the intuitive references). - who is the IETF working for? What does "better" mean for the Internet? - what about a transition as a part of the Internet architecture and the IETF process? We all must listen, ask, and require clarifications in order to be sure that we all understand each other on all of these points. This can require a lot of time if the points are disregarded. We cannot afford this. If this was the case this would have to be ported again (there is unfortunately no other way to timely obtain answers on such matters) by three appeals plus a call to the GAC and an open community debate. Alternatively, it can be very quick, if we all agree (WG, IESG, IAB, ICANN, IDNgTLD, Internet Users, ISOC, GAC). The document that Vint has promised will provide a first key indication. jefsey morfin From vint@google.com Fri Dec 11 03:52:59 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 BA5A13A6774 for ; Fri, 11 Dec 2009 03:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 aJS8B6HlrsuF for ; Fri, 11 Dec 2009 03:52:58 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 8B1223A6827 for ; Fri, 11 Dec 2009 03:52:58 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id nBBBqkIo023969 for ; Fri, 11 Dec 2009 03:52:46 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260532367; bh=2+K2tYzqSP/FSSA0A2E5uUoimP8=; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References; b=YzD/goARIaKLq2Zekvu1/BwNqVHOwMkt7yc4ETb6EHju10AMlpn6uPAn2CybPPeXF yO2ND8VDaPG9xzQ/S0Xtw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=cc:message-id:from:to:in-reply-to:content-type: content-transfer-encoding:mime-version:subject:date:references:x-mailer:x-system-of-record; b=x1Sow73CrxWkQq9WOH275by4M5aUv+YQwVv9N6HOSKq4Qrgp5MgGHZSArT9KHbcKT Tr8LE5okp7S6q7Dbacn0Q== Received: from qw-out-2122.google.com (qwb9.prod.google.com [10.241.193.73]) by wpaz21.hot.corp.google.com with ESMTP id nBBBqhB0022021 for ; Fri, 11 Dec 2009 03:52:43 -0800 Received: by qw-out-2122.google.com with SMTP id 9so179500qwb.55 for ; Fri, 11 Dec 2009 03:52:43 -0800 (PST) Received: by 10.224.69.161 with SMTP id z33mr788364qai.59.1260532362904; Fri, 11 Dec 2009 03:52:42 -0800 (PST) Received: from vint-macbookpro.home (static-72-66-6-47.washdc.fios.verizon.net [72.66.6.47]) by mx.google.com with ESMTPS id 21sm1498886qyk.12.2009.12.11.03.52.41 (version=SSLv3 cipher=RC4-MD5); Fri, 11 Dec 2009 03:52:41 -0800 (PST) Message-Id: <84CF0DA1-F225-4FBC-A282-11F5C43AAADC@google.com> From: Vint Cerf To: jean-michel bernier de portzamparc In-Reply-To: <6aad7a210912101650w7b8a56efoc8b4fbed89adc774@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Dec 2009 06:52:40 -0500 References: <6aad7a210912101650w7b8a56efoc8b4fbed89adc774@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-System-Of-Record: true Cc: workon@idna2010.org, internet users contributing group , lisa Dusseault Subject: Re: [iucg] starting points 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, 11 Dec 2009 11:52:59 -0000 Jean-Michel, please remove idna-update from your distribution list. If you want to discuss "IDNA2010" it is NOT on the IDNABIS agenda but you are free to discuss off list. vint On Dec 10, 2009, at 7:50 PM, jean-michel bernier de portzamparc wrote: > Dear colleagues, > I suggest that we start by discussing the basic principles of our > working framework in order to document IDNA2010, which is to be an > open, better usage wrap-up of IDNA2008/2003. > > A. we establish, as a principle, that we do not discuss IDNA or > build from IDNA, but rather describe the IDNA2010 conventions, and > then make sure that they conform, or are transparent, to IDNA2008 > > B. in so doing, we adopt a pragmatic unsophisticated straightforward > approach that is adequate for end users from all walks of life and > cultures. > > Portzamparc. _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update From jefsey@jefsey.com Sat Dec 12 14:30:00 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 38ED13A67FE for ; Sat, 12 Dec 2009 14:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_50=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 VRzqv4WrKgvb for ; Sat, 12 Dec 2009 14:29:59 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 812603A659A for ; Sat, 12 Dec 2009 14:29:59 -0800 (PST) Received: from 2.115.94-79.rev.gaoland.net ([79.94.115.2]:1243 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NJaT1-0001Wd-3L; Sat, 12 Dec 2009 14:29:35 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 12 Dec 2009 23:29:30 +0100 To: workon@idna2010.org From: jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091212222959.812603A659A@core3.amsl.com> Cc: iucg@ietf.org Subject: [iucg] Further to Paul Hoffman's mail 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: Sat, 12 Dec 2009 22:30:00 -0000 Dear Colleagues, further to Paul Hoffman's mail and a similar mail from Vint Cerf a very productive dialog has developped with the WG/IDNABIS Chair (Vint Cerff), the Application AD (Lisa Dussault), the IETF Chair (Russ Housley) and the facilitator of this list (JM de Portzamparc). We have not only reached a complete agreement on what was a qui pro quo, but made progresses to better evaluate the IDNA context and its practical organization. This is the first time that an IETF group of users is involved in the study and the wrting of best practices. The main problem we have is that we all expected a faster approval of the WG/IDNABIS document set by the IESG. This would have matched the ICANN precipitation and kilotons of documents with a very seriously worked on IETF back-ground. It would implicitely have said "who is what" (IETF, users, ICANN) and who is authoritative in the various parts of IDNA (network, interplus, users). Every concerned IETF leader is therefore aware that we need that response by approval of the IDNA document set or appeal to the IESG. No one objects. The position I maintain is that the IUCG : - can only meet the ICANN position because they also are users, - think it is premature, - wants an IETF clear definition of the zone of architectural authority (network, interplus, user machines, applications). - object to the ICANN denial of IDNgTLD projects as detrimental to a good Multilingual Internet deployment. It is like if ".us" had been the only TLD in town when they started the DNS. Regards. jfc morfin Chair, IUCG From jmabdp@gmail.com Wed Dec 16 18:04:45 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 5EE203A67B1 for ; Wed, 16 Dec 2009 18:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=-0.455, 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 DsJ0ZYftsUVV for ; Wed, 16 Dec 2009 18:04:41 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id A4CC93A63D3 for ; Wed, 16 Dec 2009 18:04:41 -0800 (PST) Received: by ywh15 with SMTP id 15so1737932ywh.5 for ; Wed, 16 Dec 2009 18:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=blBtWPNwUyBXbkANTmvdYpwMQqs4Al7P0CEmkxovKcI=; b=vFIhvo6aqdGt3GjjMOdslLEHMZo0baektVYtmWxT3I/l5vIR87tNk0dE+vzfIjaE6Q 1FZHHbMqDkA6CQHCEsSHiQXiCljJkgRnvr7nlRD1ytiSJIfDl9xkKV70fLWhiSxdefVX qgojNduLG/kMzdnEUyRzzZwBw1Y8c13AhOfOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=hGziwVtGu5XoiPiRCfxPbROsgBWudtrmZkeg7Z9gpTQhyVyqm2qDim8bnpmjTsPhLo kkhlWO8hVCe60Pujt21t87RLdCPCGrjxwoi7DG+lRyT6wuoC/OCPdIFIi8YCtOIA4D8o vONyJNDTMj2zDIvflfGrilblPbJ6ACI4zsDSQ= MIME-Version: 1.0 Received: by 10.101.173.7 with SMTP id a7mr2757963anp.157.1261015464130; Wed, 16 Dec 2009 18:04:24 -0800 (PST) Date: Thu, 17 Dec 2009 03:04:24 +0100 Message-ID: <6aad7a210912161804m4c99f07ao498fbf3a6b3a18f4@mail.gmail.com> From: jean-michel bernier de portzamparc To: Cary Karp Content-Type: multipart/alternative; boundary=001636c92c68cbbb1e047ae30a71 Cc: IDNA2010 Documentation , IDNA update work , Tina Dam , internet users contributing group Subject: [iucg] PostWG IDNA2008 implementation, transition and deployment document preparation 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, 17 Dec 2009 02:04:45 -0000 --001636c92c68cbbb1e047ae30a71 Content-Type: text/plain; charset=ISO-8859-1 Dear Cary, from the different mails exchanged on this list, I understand that : - you want two different wehicles for (1) the protocol (IDNA2008 document set produced by this WG) and (2) guidelines/BCP to assist in implementing and transitionning its introduction. - Tina Dam is in charge of issuing a new set of guidelines that will apply to Fast Track participants. - in this endeavor you are playing a role equivalent to an IETF AD - the ICANN BoD has a role equivalent to the IESG in order to approve the document (hence the Ombudsman is the appeal procedure). - Tina Dam is going to run six meetings on the guidelines starting January 11th - you will report this meetings the transition propositions discussed on this list. As you know, I am the facilitator of the workon@idna2010.org mailing list that targets the publication of a BCP on the implementation, transition and deployment of IDNA2008. I understand that in first phase you are concerned by a politically limited number of IDNccTLDs. Our own target is similar. However it is more general since it targets billions of existing or future zone Managers who are going to actually use the IDNA system. There is by nature a broad difference and at the same time a necessary complementarity between IDNA within the Internet governance and operations and within the users' applications architectures. 1. I therefore approve Vint position "I would argue that the WG has completed its technical work on the standards and that the transition question is moved to the ICANN Guidelines group for analysis and consideration" if these questions have also already moved to the IUCG IDNA2010. 2. I suppose you have no objection that we consider the best way to liaise about our complementary works. If this may help: (1) the workon@idna2010.orgmailing list is open to everyone. (2) I will actually keep the work low on this strictly moderated list until the production of a computer assisted communication general review I_D that will permit to clearly locate IDNA related issues. 3. Our approval of Vint position extends to not finalize any position until the IDNA2008 document set has been published as RFC, allowing a full review by the IESG, possible appeals if the text had been conceptually modified on some points during the review process and requests for guidance to the IAB in the case some transition mechanisms did conflict with other existing RFCs. Best regards JM Bernier de Portzamparc --001636c92c68cbbb1e047ae30a71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Cary,

from the different mails exchanged on this list, I unders= tand that :

- you want two different wehicles for (1) the protocol (= IDNA2008 document set produced by this WG) and (2) guidelines/BCP to assist= in implementing and transitionning its introduction.
- Tina Dam is in charge of issuing a new set of guidelines that will apply = to Fast Track participants.
- in this endeavor you are playing a role equivalent to an IETF AD
- the ICANN BoD has a role equivalent to the IESG in order to approve the d= ocument (hence the Ombudsman is the appeal procedure).
- Tina Dam is going to run six meetings on the guidelines starting January = 11th
- you will report this meetings the transition propositions discussed on th= is list.

As you know, I am the facilitator of the workon@idna2010.org mailing list that targets the publication of a= BCP on the implementation, transition and deployment of IDNA2008. I unders= tand that in first phase you are concerned by a politically limited number = of IDNccTLDs. Our own target is similar. However it is more general since i= t targets billions of existing or future zone Managers who are going to act= ually use the IDNA system.

There is by nature a broad difference and at the same time a necessary comp= lementarity between IDNA within the Internet governance and operations and = within the users' applications architectures.

1. I therefore approve Vint position "I would argue that the WG has co= mpleted its technical work on the standards and that the transition questio= n is moved to the ICANN Guidelines group for analysis and consideration&quo= t; if these questions have also already moved to the IUCG IDNA2010.

2. I suppose you have no objection that we consider the best way to liaise = about our complementary works. If this may help: (1) the workon@idna2010.org mailing list is open to everyo= ne. (2) I will actually keep the work low on this strictly moderated list u= ntil the production of a computer assisted communication general review I_D= that will permit to clearly locate IDNA related issues.

3. Our approval of Vint position extends to not finalize any position until= the IDNA2008 document set has been published as RFC, allowing a full revie= w by the IESG, possible appeals if the text had been conceptually modified = on some points during the review process and requests for guidance to the I= AB in the case some transition mechanisms did conflict with other existing = RFCs.

Best regards
JM Bernier de Portzamparc --001636c92c68cbbb1e047ae30a71-- From jefsey@jefsey.com Thu Dec 17 19:16:04 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 C09663A692F for ; Thu, 17 Dec 2009 19:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_50=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 LzyA-Q9a9E6I for ; Thu, 17 Dec 2009 19:16:04 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id EAC053A690C for ; Thu, 17 Dec 2009 19:16:03 -0800 (PST) Received: from 89-158-60-224.rev.dartybox.com ([89.158.60.224]:4236 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NLTJT-0000ey-GE; Thu, 17 Dec 2009 19:15:32 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 18 Dec 2009 04:15:24 +0100 To: jmabdp@google.com,Tina Dam , Cary Karp From: jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091218031603.EAC053A690C@core3.amsl.com> Cc: workon@idna2010.org, Vint Cerf , iucg@ietf.org, Lisa Dusseault , "idna-arabicscript@lists.irnic.ir" Subject: [iucg] Clarification on ICANN and IDNs 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, 18 Dec 2009 03:16:04 -0000 Tina, Cary, Jean-Michel, I would like to suggest you keep this kind of debate out of the WG/IDNABIS mailing list, unless you think Vint Cerf and Cary Karp are wrong stating that: - the IDNA2008 text is completed. - we have entered the testing and operational documentation phase. 1. Jean-Michel, please remember that ICANN is not the IETF. They are not in charge of the technology nor to make the Internet work, or be used, better. They are in charge of the contracts they signed with gTLDs and some ccTLDs. Their objective is to sign more ccTLD contracts. They use IDNs and competition between IDNccTLD and IDNgTLD projects to help this objective. You may object to this, but this is the ICANN mission and policy. Also, you are an Internet User, not an ICANN User, as you pertinently noted it. 2. Jean-Michel and Cary, please also remember that you have rather different points of view over the same thing. Cary's culture respects the selective ICANN's contracting strategy. ICANN decides of a move, proposes, selects, contracts. .MUSEUM is the result of such a selection process. Jean-Michel's culture is open to all, on a first come first serve, no vote no king, no selection, and no discrimination but rough consensus and running code. What is surprising to him is the denial of IDNgTLD process on an equal basis to FAST TRACK. 3. Tina, if we want to reach a good cooperation over a BCP IDNA2010 on the implementation, transition, and deployment of IDNA2008, I think we have to proceed jointly and in the open. We have to mutually understand each others. I committed to produce a general framework as an I_D in the coming two weeks. I suggest that we put everything on hold until I produce that document, ICANN documents its IDNA implementation team, stratey and mailing lists as you proposed (we will get it on the http:/:inda2010.org) and IESG approves the IDNA2008 WG/IDNABIS document set. jfc From jmabdp@gmail.com Sun Dec 20 14:31: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 784A13A6842 for ; Sun, 20 Dec 2009 14:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[AWL=-1.854, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6] 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 LL79I85F5BQO for ; Sun, 20 Dec 2009 14:31:08 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 0602D3A62C1 for ; Sun, 20 Dec 2009 14:31:07 -0800 (PST) Received: by gxk28 with SMTP id 28so4505273gxk.9 for ; Sun, 20 Dec 2009 14:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Hhh65OCJPDUpdnvnYqAZ9fHNyeBj1vmgbpevD4Mod/o=; b=IuVW2AqsIT0Zo8deRb6k1x60ttw7CCRbRAskfhBsnMF5fFcIt3CcsytGYFEVKAt4U7 bh9vM0V5cPnaTHXKdPaJZxZ2DiNkuFmJvzpqHxT6PWP+NXog4gAAXn2b1UW2vB/0IcQ0 U/xOuFU/hI00ktj/D9nVBjtFxW44HsOGXSMmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ajJAHvEMV2T+fowGKAhKgX0p7TVocgh5RJnOWZi9rSeOURcpqrVkSGQ5wg04PlrdxN y7bpxVbG2niuekPnKCB9BOoVkS+O1deFmrbnuzBBz8ZyEQA1nSpirZxehLia8HIQzTLi sMrzO5lBPZ/s6DvedkRhmX0fnJ2uK8+HZWtDw= MIME-Version: 1.0 Received: by 10.101.138.1 with SMTP id q1mr2342489ann.148.1261348247808; Sun, 20 Dec 2009 14:30:47 -0800 (PST) In-Reply-To: <6aad7a210912201126p6e643e1cve486ee197b5ff78c@mail.gmail.com> References: <6aad7a210912201126p6e643e1cve486ee197b5ff78c@mail.gmail.com> Date: Sun, 20 Dec 2009 23:30:47 +0100 Message-ID: <6aad7a210912201430m11254973t3a4f83638f7935e@mail.gmail.com> From: jean-michel bernier de portzamparc To: IDNA2010 Documentation Content-Type: multipart/alternative; boundary=0016e68ee2bc3fac9e047b308625 Cc: internet users contributing group Subject: [iucg] Fwd: IDNA 2008 network neutrality, security, operations and equal treatment 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, 20 Dec 2009 22:31:12 -0000 --0016e68ee2bc3fac9e047b308625 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Workon@IDNA2010 participants, The debate within the WG/IDNABIS is not closed in spite everything technica= l being finished. For the time being, ICANN tries to transfer the discussion on IDNA2008 implementation to its own closed committee on IDNs. This is objected but we need to have good reasons why, for ICANN to accept, otherwise we will have to conflict. We have discussed with Jefsey and organised the following action: we have sent the attached mail to Lisa Dussault - the IETF Application AD who supervises the WG/IDNABIS - copy to the WG Chair and Members. This is a general answers to her mails (sending so many mails is very seldom for an A= D at that stage). This will permit us to claim that in spite the Last Calls are finished, we still could contribute (responding to question of the AD) with the possibility of an Appeal to the IESG would we not be satisfied (as we agree with the questions raised by the AD, we cannot be technically satisfied except by a guidance of the IAB and by a removal of the ICANN involvement). This means that we can delay ICANN with this (plus work) until there is a real debate engaged over what IDNA2008 implies between IETF, ICANN, Asia, Google, and us. To well understand the problem. - IDNA2008 is a very good protocol (just a few things to tune - our job). - it also is a part of the IDNA architecture. The IDNA architecture devised by IAB for IDNA2003 was constrained. IDNA2008 removes much of the constraints. It means that IDNA2008 undermines the IDNA2003 architecture - they did not realized that. So, devising an IDNA2008 architecture was not a part of the WG/IDNABIS mission. The Chair was initially very clear about it= . This is why we created this mailing list with that usage architecture to consider. The result most probaly will put ICANN aside - unless they cooperate and devise new services they can bring to users. For the time being ICANN tries to take responsibility and workout something less constraining for them. IETF engineers cannot oppose ICANN however they know ICANN cannot succeed. Some are upset. Others enjoy the fun. Others wait for Jefsey to publish an I_D (Draft) describing how he sees "interplus" being the solution. I committed to keep this mailing list silent except for information from Jefsey and me. I want to underline that this kind of situation is very uncommon. It result= s from the complexity and to the impact of the matter. We need everyone to carefully consider. Much is at stake. Not only money. Best regards to all. Portzamparc ---------- Forwarded message ---------- From: jean-michel bernier de portzamparc Date: 2009/12/20 Subject: IDNA 2008 network neutrality, security, operations and equal treatment To: Lisa Dusseault Cc: Vint Cerf , IDNA update work Dear Lisa, It took a few days for france@large to consider all your mails in attachment. We found that they raise three fundamental problems that have not been discussed yet but that now needs to be addressed prior to any publication of the IDNA2008 documentation set. These problems are the network neutrality, security, and operative independence that are to be enhanced or at least respected when introducing IDNA2008. However, IDNA2008 is Internet neutral; it can be tested, introduced, and supported in a non-neutral manner. IDNA2008 is both a protocol and architecture. The protocol security aspects are covered in the current security section, but the architectural security aspects are not discussed. Moreover: - IDNA2008 represents a substantial technical progress of the Unicode globalization towards a Multilingual Internet (represented for example by a= n independence from a Unicode specific version and reduced mapping at protoco= l level). This means a better support of specific namespaces that currently are, can be operated, or are to be built, outside of the area of ICANN's governance (as prepared by the ICANN ICP-3 document, france@large has applied through a two-year community test). This in particular includes non-IDNA presentations, non class "IN" classes. - RFC 3935 assigns the IETF with the responsibility for a much broader Internet than the ICANN footprint, i.e. "A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it. The term includes both the "core Internet" (ISP networks) and "edge Internet"(corporate and private networks, often connected via firewalls, NA= T boxes, application layer gateways and similar devices). The Internet is a truly global network, reaching into just about every country in the world. The IETF community wants the Internet to succeed because we believe that th= e existence of the Internet, and its influence on economics, communication, and education, will help us to build a better human society." We do not have the time, technical capacity or experimental background no= w to tackle this issue at an IETF standardization level. However, the IETF MUST make it clear that if the resolution of IDNA operational and architectural issues is delayed and possibly delegated to ICANN's (*) IDN Guidelines Committee (cf. WG Chair 19 December 2009 mail) or is assumed by the IUCG open special interest group for an IDNA2010 BCP on the implementation, transition, and deployment of IDNA2008 ( http://idna2010.or= g), some principles must be clearly and consistently spelled and be respected b= y these entities because they belong to the IETF rights, duties, and values. The first of them is that these entities must be open to any interested individual. - The WG/IDNABIS Charter states: "It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions." At the WG/IDNABIS, we considered the technical exceptions within the protocol definitions and minimized them. However, there are other exceptions that may arise in the protocol experimentation, deployment, and various applications that can lead (as you have yourself noted) to conflicts on the same user machine, within the same usage, the same application or the same network governance area. Our mission is to document how to avoid such technical, security and operational problems or to list them in the security section with the principles that should be followed in order to best protect Internet Users. - The WG/IDNABIS Charter also states: "The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system". This is true at every level of the DNS: this is also true for the first level. This means that this WG must ensure that its document set and its consequences are not possibly used to disturb the current use and operation of the domain name system at architectural, security, and operational levels. This is not the case. The documents should at least include the mention of these risks, and how they should be defeated or that further work on the issue is to be carried. - The IETF is not involved with the "current use and operation of the domai= n name system", except for one major exception. This exception is the management of the IANA registry. This is described in RFC 2860 and RFC 5226 (which obsoletes RFC 2424). There are two main cases involving the IETF's direct responsibility to the point where it can exercise its ability to cancel the IETF/ICANN MOU: ---- in case of experimentation by ICANN and/or IETF ---- in case of a conflict between the standard and the way ICANN applies an IETF standard. There are non-ICANN entities which may de facto or legally share or assume the IANA's role to the legitimate benefit of some IDN internet communities; they will be called IDNO (IDN Organizations). There are expressed concerns and demonstrated situations where ICANN, or other IDNO, that the current use and operation of the domain name system might be disturbed. There are three classes of (possible) situations where this happens: - the lack of distribution equilibrium between the kind of potential difficulties to experiment, analyze, and address that is due to the limitations imposed by ICANN to participate in its experimentation which is restricted to non-roman IDNccTLDs. It is to be expected that most of the ne= w difficulties to experiment will be located ---- at IDNgTLDs along with more innovative uses and the lack of a governmental authority to sustain their naming policy, ---- at bidi TLDs, ---- and at roman TLD where the orthotypography is not fully supported (as Latin language TLDs, and especially French). - These TLDs MUST either be a part of the ICANN experimentation on an equal footing basis, or an IETF sponsored complementary experimentation should be organized by adding a batch of experimental TLDs in the root file towards t= o warranty an equal chance of access to experimental operations and sales, on a first come first serve basis (**). - the commercial discrimination that is imposed by ICANN=92s internal rule= s between candidates to IDNg/ccTLD on IDNA and root capacity related technica= l grounds (after two years of an official public campaign denying such limitations and an offer to register gTLD candidates (with 500 candidates being persistently rumored)). This is in clear contradiction with the WTO rules and the international agreements concerning the Technical Barriers to Trade. Due to the RFC 5226 (2424) on the "first come, first serve" principl= e in IANA registration and the RFC 2860, the IETF could find itself involved in a lengthy international commerce case that could affect the credibility of its international responsibility capacity and further delay IDNs for years to come. - new Internet architectural readings, such as "Interplus", which was introduced by the IUCG, based upon IDNA2008 findings. This WG should add in the security section that this potential risk has been identified, the IUCG was requested to document "Interplus like" architectural frameworks, and i= t will rest with ICANN, IETF, and the appropriate IDNO and Internet User representations to address it. RFC 3935 assigns the IETF with the goal to make the Internet work better: "The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds". Standards are well defined in RFC 3935: "As used here, the term describes a specification of a protocol, system behaviour or procedure that has a uniqu= e identifier, and where the IETF has agreed that "if you want to do this thing, this is the description of how to do it". It does not imply any attempt by the IETF to mandate its use, or any attempt to police its usage = - only that "if you say that you are doing this according to this standard, do it this way". The benefit of a standard to the Internet is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users." As a result, this WG should make it clear that any derivative work where additional neutrality, security, or operational additional constraints that is based upon privately contracted situations that would not fully respect "its description of how to do it", including its principles for derivative work, might not be interoperable and, therefore, should not be attempted by ICANN and IDNA having entered into a comparable MoU with the IETF. This restriction is a consequence of the IETF RFC 2860 obligations to properly advise ICANN. RFC 3935 also states: "The Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create." What is discussed in this very memo shows that IDNA2008 may lead to important, yet potentially disruptive, innovations that the IETF, ICANN, IDNOs and Internet Users should collectively evaluate and canalize. IDNA200= 8 permits misuses that they all should oppose in unison. Jean-Michel de Portzamparc (*) The WG/IDNABIS Chair wrote on 2009/12/29 that: "It has been suggested that a better forum in which to deal with IDNA2003 and IDNA2008 incompatibility is the ICANN IDN Guidelines Committee. That may be a better forum with broader participation than the IDNABIS working group in which th= e TR46 proposal or other proposals may be discussed. If we adopt Cary Karp's offer, your observations, below, would be input into the Guidelines committee discussions." For years, none of the participants to this note ha= s succeeded to participate to the ICANN process on an individual basis or through an ICANN constituency. (**) france@large has answered the French Government pending public call fo= r candidates to manage the ".fr" namespace (This answer has been published as a book and can be found at http://www.lulu.com/content/paperback-book/pni/7143574). As part of this response it noted its interest to manage the ".tf" TLD and to orient it towards French litterature (Textes Fran=E7ais). It also is one of the technical sponsors of Project.FRA and a Member of the A-FRA ( http://a-fra.org). The gTLD policy published by ICANN since its Paris meeting permitted ".FRA" to start proposing French IDNs in parallel with AFNIC (".fr") even if the French Government continued to procrastinate or did not retain france@large as the operator of ".fr" or of "tf". The recent policy change introduced by ICANN, in turn procratisnating about gTLDs, gives AFNIC (.fr) an unfair advantage in deploying French IDNs. Moreover if French language orthotypography is not properly supported. Repeated documented requests and a pending I_D on the way to support them ( http://www.ietf.org/id/draft-iucg-punyplus-03.txt) was systematically ignored by the Chair and you. Project.FRA has a three phase deployment plan: A. free test ULD (user level domain) in Interplus class IU (Internet Users) B. non-profit non-free ULD zone in class IU C. non-profit commercial IDNgTLD also in class IN and IU. Phase A is now in pre-operations. Phase B will be initiated as soon as the IDNA2010 BCP on the implementation, transition, and deployment of IDNA2008 is completed. Phase C should have been initiated as soon as ".fra" is in th= e ICANN Root file as a regular gTLD. Its purpose is to pay for the Phase A an= d B voluntary and experimental project. ---------------------------------------- At 21:33 01/12/2009, Lisa Dusseault wrote: One example I discussed with Patrik yesterday, was whether locale might affect mapping. I'd like to get better insight into the general understanding of that. 1. Could locale determine whether a PVALID character should be mapped into another PVALID character prior to following the rules to turn into an ALABEL? I believe the consensus answer is probably SHOULD NOT or MUST NOT because that would make domains with that valid character unreachable by software using those locale rules. 2. Could locale determine whether, or how, a DISALLOWED character is mapped into a PVALID character prior to getting an ALABEL? For example: - in locale Laputa, disallowed character (x230) is not used in the local language, so it's not mapped, an error occurs so a user seeing that in a Web page can't reach any actual domain - in locale Balnibarbi, (x230) is considered to be the same as O, so it's mapped to 'o', and a Balnibarbi user reaches domains containing o's - in locale Glubbdubdrig, (x230) is considered to be the capitalized version of (x231) and a Glubbdubdrig user reaches a different set of domains containing 's Note that none of these locale rules would necessarily make domains containing completely unreachable to their users -- a Web page containing a link with would be looked up without mapping that character to another (assuming the conclusion of point 1 above). If I'm reading between the lines correctly, communication is hampered between people who are writing under the assumption that this kind of locale-dependent scenario is going to happen, and people who are writing under the assumption that this kind of locale-dependent scenario ought to be forbidden and nobody would try such a crazy thing. At 22:04 01/12/2009, Lisa Dusseault wrote: I don't believe we know what the WG consensus position is around how strongly pre-lookup mappings are recommended and in what use cases, and how compatible optional pre-lookup mappings are with IDNA2003 in-protocol mapping. Agreeing with you to a large extent Vint, I believe there is a strong consensus in the WG that mappings "aren't part of the protocol", meaning mapping shouldn't be required in all cases. Certainly, registries shouldn't be required to automatically map any character into any other character before registering the mapped domain name: better to make the domain name holder be explicit about the exact domain name they are registering. We have also referred to use cases involving client software doing lookup of domains that are already supposed to be valid, in which context an invalid character would simply be a software error rather than a situation that required mapping. In this matter, we have consensus to do something different in IDNA2008 vs IDNA2003. I believe we also do have consensus in the equivalence of A-label and U-label forms and transformation in either direction. After that it gets confusingly nuanced. We even discussed having a different term for optional, pre-lookup mapping of user-typed-in domain names, including links found in HTML typed in by the HTML author. I believe we do have consensus in the WG that this type of helpful mapping is going to be implemented, for example in Web browsers, as being a user experience that is preferred over a dialog interruption or error. So that leaves us with a great deal of progress in IDNA2008, and a lot that is decided by WG consensus, but still with a gap in our total consensus. Some people would prefer that optional, pre-lookup mapping be wide open. Others would prefer would that although pre-lookup mapping should be optional, IF it is done, it MUST be done one way. There's even room for a middle ground where there might be more than one recommended standard set of mappings, but they should be done as a matter of standardization and not as a matter of full implementer discretion, if at all possible. There is room for splitting the mappings territory up per-application: perhaps domains in HTTP URLs and browser address bars should be mapped one way, but other types of URLs could follow "no mappings allowed" rules. Finally, we have the options around transition strategies (such as bundling recommendations) that might allow us to come to consensus regarding these optional pre-lookup mapping questions. I appreciate all the discussion that is leading us to a better understanding of the issues around those last issues, and developing consensus regarding those last options. At 16:06 02/12/2009, Lisa Dusseault wrote: I'd like to try to unpack some of the different use cases we're talking about a little more. ISTM that use cases where the person following the link is the person who is typing it in, are use cases that locale-dependent mapping might be most useful. If I'm in a locale where (x230) is considered to be the capitalized version of o (ASCII o), it might very well be most helpful to make that mapping. Use cases where the same user is typing in the domain names that then looks them up include: - typing links in the address bar - typing mail address in the To field of an email - Writing a Web page, blog post or email, wherein I check that the links work before posting/sending my document In contrast, the use case where the person looking up the domain F .example is not the person who typed it in, then in most cases we no longer know the intent or locale of the person who typed in the domain. It may be the same locale as the person who is looking up the domain but it may not be. The person who typed in the domain may have intended f .example or foo.example, and may have tested that before sending/posting the link, but we no longer have that information. Use cases include: - Following a HTTP link in any Web page, document, blog post, email, etc - Using a mailto link (explicit or implicit), e.g. when one person sends me another person's email address We probably would all agree that people follow links while Web browsing far more often than they type them in, and even when typing in, auto-complete probably drastically reduces the new cases of from-scratch mapping and lookup. However, we probably have quite different assumptions about how much Internet activity takes place among users of a consistent locale. Can we assume that Patrik wants interpreted as because he communicates mostly in Swedish with Swedish users and mostly reads Swedish Web pages? Or must we assume that Patrik also gets email from german and swiss senders, and also reads Web pages (perhaps in English!) written by German users who expected different mappingsH[H H\=99\[ avily on our mod= el of a user, and whether we're using ourselves as hypothetical examples or not. One slightly more solid question for browsers is, would it be entirely crazy to have different mapping algorithms for typed-in domain names than for links followed? There might be a locale-dependent mapping as well as a global mapping. (I assume that having every established locale mapping installed would be complete craziness.) Another question is: when posted links are followed, how often do we know the locale where the link was authored? Not that the browser following the link would necessarily be able to apply the mappings of the locale in which it was authored, but would it be slightly better to apply a global mapping than a mapping from a different locale? Do any authoring software clients fix up links as the user types? When I type a link in a document, the authoring software often makes that link active. Is there any software that automatedly lower-cases? If so, would such software also be likely to map to PVALID characters before the doc is finished? At 20:35 02/12/2009, Lisa Dusseault wrote: I don't see where that principle begins and ends. If it were entirely true= , zone operators would be entirely free to register xn--garbage as a domain, entirely free to register DISALLOWED characters. Since it is in the purview of IDNA designers to make a character valid or disallowed, wouldn't also be in the purview of IDNA designers to say something like "This character becomes valid on date 01/01/2020", right? S= o why wouldn't it be in the purview of IDNA designers to also say something like "This character becomes fully valid on date 01/01/2020, but until then= , may be registered if it is bundled with another sequence"? Doncha love slippery slopes At 00:15 03/12/2009, Lisa Dusseault wrote: >>Would someone who understands IETF process better than I do please explai= n why the discussion >> of that character needs to proceed any further? Even if this is a rhetorical question, I'll bite. It's because the IETF makes decisions by rough consensus and running code. Rough consensus is among informed participants as well as experts and people in certain positions of authority or responsibility. Running code certainly brings in browser/client implementation history and current client implementation concerns. It is not only operators of the countries where those languages are most spoken, that have collateral effects from the status of the characters of those languages in IDNA. At 01:46 03/12/2009, Lisa Dusseault wrote: Your argument is a fair argument to try to influence the consensus, but it is not a fair argument to overrule a consensus (not that I'm saying you are doing that). We do rely on most IETF participants being constructive most of the time. We just have no other process besides appealing to people who are forming the consensus to look at running code, reality, security concerns and so on. At 05:01 03/12/2009, Lisa Dusseault wrote: I did claim that running code was an important influence on a WG consensus, by tradition, habit and official encouragement. - First, that doesn't mean it's the only influence, or the most important influence in some considerations. - Second, the term is used both strictly, as in to demonstrate interoperability directly, and also loosely. By loose interpretations of "running code" you could claim that how a country uses a character in printed books was a form of deployed code that can be used as factual evidence. At 23:41 04/12/2009, Lisa Dusseault wrote: I've been having trouble understanding how TRANSITIONAL characters that could not be mapped or looked up by clients would help us out here. (You'r= e not the only one Erik, I was just thinking of this offline) If I understand correctly, Web browsers in particular visit a corpus of Web pages with links that they would like to not only continue to support, but also continue to resolve to the same host (absent other changes). So on th= e day that somebody upgrades to the new version of a browser with IDNA2008, their link destinations for TRANSITIONAL characters do not change. "Do not change" also means that the user doesn't suddenly start getting an error trying to follow a link with a TRANSITIONAL character in the domain. I agree that in some models, an error is better than going to an indeterminate destination. But only in some models. To the user, upgradin= g their browser and suddenly having links with in domains fail where it succeeded the day before, does not seem like a real upgrade. --0016e68ee2bc3fac9e047b308625 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Workon@IDNA2010 participants,

The debate within the WG/IDNABIS = is not closed in spite everything technical being finished.

For the= time being, ICANN tries to transfer the discussion on IDNA2008 implementat= ion to its own closed committee on IDNs. This is objected but we need to ha= ve good reasons why, for ICANN to accept, otherwise we will have to conflic= t.

We have discussed with Jefsey and organised the following action: we ha= ve sent the attached mail to Lisa Dussault - the IETF Application AD who su= pervises the WG/IDNABIS - copy to the WG Chair and Members. This is a gener= al answers to her mails (sending so many mails is very seldom for an AD at = that stage).

This will permit us to claim that in spite the Last Calls are finished,= we still could contribute (responding to question of the AD) with the poss= ibility of an Appeal to the IESG would we not be satisfied (as we agree wit= h the questions raised by the AD, we cannot be technically satisfied except= by a guidance of the IAB and by a removal of the ICANN involvement). This = means that we can delay ICANN with this (plus work) until there is a real d= ebate engaged over what IDNA2008 implies between IETF, ICANN, Asia, Google,= and us.

To well understand the problem.

- IDNA2008 is a very good protoc= ol (just a few things to tune - our job).

- it also is a part of the= IDNA architecture. The IDNA architecture devised by IAB for IDNA2003 was c= onstrained. IDNA2008 removes much of the constraints. It means that IDNA200= 8 undermines the IDNA2003 architecture - they did not realized that. So, de= vising an IDNA2008 architecture was not a part of the WG/IDNABIS mission. T= he Chair was initially very clear about it.

This is why we created this mailing list with that usage architecture t= o consider. The result most probaly will put ICANN aside - unless they coop= erate and devise new services they can bring to users. For the time being I= CANN tries to take responsibility and workout something less constraining f= or them. IETF engineers cannot oppose ICANN however they know ICANN cannot = succeed. Some are upset. Others enjoy the fun. Others wait for Jefsey to pu= blish an I_D (Draft) describing how he sees "interplus" being the= solution.

I committed to keep this mailing list silent except for information fro= m Jefsey and me.

I want to underline that this kind of situation is = very uncommon. It results from the complexity and to the impact of the matt= er. We need everyone to carefully consider. Much is at stake. Not only mone= y.

Best regards to all.

Portzamparc

---------- Forwarded message ----------
From: jean-michel bernier de portzamparc <jmabdp@gmail.com>
Date: 2009/12/20
Subject: IDNA 2008 network neutrality, security, operat= ions and equal treatment
To: Lisa Dusseault <lisa.dusseault@gmail.com>
Cc: Vint Cerf <<= a href=3D"mailto:vint@google.com">vint@google.com>, IDNA update work= <idna-update@alvestrand.no= >


Dear Lisa,

It took a few days for france@large to consider a= ll your mails in attachment. We found that they raise three fundamental pro= blems that have not been discussed yet but that now needs to be addressed p= rior to any publication of the IDNA2008 documentation set.

These problems are the network neutrality, security, and operative inde= pendence that are to be enhanced or at least respected when introducing IDN= A2008. However, IDNA2008 is Internet neutral; it can be tested, introduced,= and supported in a non-neutral manner. IDNA2008 is both a protocol and arc= hitecture. The protocol security aspects are covered in the current securit= y section, but the architectural security aspects are not discussed.

Moreover:

- IDNA2008 represents a substantial technical progress= of the Unicode globalization towards a Multilingual Internet (represented = for example by an independence from a Unicode specific version and reduced = mapping at protocol level). This means a better support of specific namespa= ces that currently are, can be operated, or are to be built, outside of the= area of ICANN's governance (as prepared by the ICANN ICP-3 document, f= rance@large has applied through a two-year community test). This in particu= lar includes non-IDNA presentations, non class "IN" classes.

- RFC 3935 assigns the IETF with the responsibility for a much broader = Internet than the ICANN footprint, i.e.=A0 "A large, heterogeneous col= lection of interconnected systems that can be used for communication of man= y different types between any interested parties connected to it.=A0 The te= rm includes both the "core Internet" (ISP networks) and "edg= e Internet"(corporate and private networks, often connected via firewa= lls, NAT boxes, application layer gateways and similar devices).=A0 The Int= ernet is a truly global network, reaching into just about every country in = the world. The IETF community wants the Internet to succeed because we beli= eve that the existence of the Internet, and its influence on economics, com= munication, and education, will help us to build a better human society.&qu= ot;

=A0 We do not have the time, technical capacity or experimental backgro= und now to tackle this issue at an IETF standardization level. However, the= IETF MUST make it clear that if the resolution of IDNA operational and arc= hitectural issues is delayed and possibly delegated to ICANN's (*) IDN = Guidelines Committee (cf. WG Chair 19 December 2009 mail) or is assumed by = the IUCG open special interest group for an IDNA2010 BCP on the implementat= ion, transition, and deployment of IDNA2008 ( http://idna2010.org), some principles must be clea= rly and consistently spelled and be respected by these entities because the= y belong to the IETF rights, duties, and values. The first of them is that = these entities must be open to any interested individual.

- The WG/IDNABIS Charter states: "It is recognized that some expli= cit exceptions may be necessary in any case, but attempts will be made to m= inimize these exceptions." At the WG/IDNABIS, we considered the techni= cal exceptions within the protocol definitions and minimized them. However,= there are other exceptions that may arise in the protocol experimentation,= deployment, and various applications that can lead (as you have yourself n= oted) to conflicts on the same user machine, within the same usage, the sam= e application or the same network governance area. Our mission is to docume= nt how to avoid such technical, security and operational problems or to lis= t them in the security section with the principles that should be followed = in order to best protect Internet Users.
=A0
- The WG/IDNABIS Charter also states: "The constraints of the o= riginal IDN WG still apply to IDNABIS, namely to avoid disturbing the curre= nt use and operation of the domain name system". This is true at every= level of the DNS: this is also true for the first level. This means that t= his WG must ensure that its document set and its consequences are not possi= bly used to disturb the current use and operation of the domain name system= at architectural, security, and operational levels. This is not the case. = The documents should at least include the mention of these risks, and how t= hey should be defeated or that further work on the issue is to be carried.= =A0=A0

- The IETF is not involved with the "current use and operation of = the domain name system", except for one major exception. This exceptio= n is the management of the IANA registry. This is described in RFC 2860 and= RFC 5226 (which obsoletes RFC 2424). There are two main cases involving th= e IETF's direct responsibility to the point where it can exercise its a= bility to cancel the IETF/ICANN MOU:
=A0
----=A0 in case of experimentation by ICANN and/or IETF
----=A0 i= n case of a conflict between the standard and the way ICANN applies an IETF= standard.


There are non-ICANN entities which may de facto or le= gally share or assume the IANA's role to the legitimate benefit of some= IDN internet communities; they will be called IDNO (IDN Organizations).
There are expressed concerns and demonstrated situations where ICANN, o= r other IDNO, that the current use and operation of the domain name system = might be disturbed. There are three classes of (possible) situations where = this happens:
=A0
- the lack of distribution equilibrium between the kind of potential= difficulties to experiment, analyze, and address that is due to the limita= tions imposed by ICANN to participate in its experimentation which is restr= icted to non-roman IDNccTLDs. It is to be expected that most of the new dif= ficulties to experiment will be located

---- at IDNgTLDs along with more innovative uses and the lack of a gove= rnmental authority to sustain their naming policy,
---- at bidi TLDs, ---- and at roman TLD where the orthotypography is not fully supported (a= s Latin language TLDs, and especially French).

- These TLDs MUST either be a part of the ICANN experimentation on an e= qual footing basis, or an IETF sponsored complementary experimentation shou= ld be organized by adding a batch of experimental TLDs in the root file tow= ards to warranty an equal chance of access to experimental operations and s= ales, on a first come first serve basis (**).
=A0
-=A0 the commercial discrimination that is imposed by ICANN=92s inte= rnal rules between candidates to IDNg/ccTLD on IDNA and root capacity relat= ed technical grounds (after two years of an official public campaign denyin= g such limitations and an offer to register gTLD candidates (with 500 candi= dates being persistently rumored)). This is in clear contradiction with the= WTO rules and the international agreements concerning the Technical Barrie= rs to Trade. Due to the RFC 5226 (2424) on the "first come, first serv= e" principle in IANA registration and the RFC 2860, the IETF could fin= d itself involved in a lengthy international commerce case that could affec= t the credibility of its international responsibility capacity and further = delay IDNs for years to come.
=A0
- new Internet architectural readings, such as "Interplus"= , which was introduced by the IUCG, based upon IDNA2008 findings. This WG s= hould add in the security section that this potential risk has been identif= ied, the IUCG was requested to document "Interplus like"=A0 archi= tectural frameworks, and it will rest with ICANN, IETF, and the appropriate= IDNO and Internet User representations to address it.
=A0

RFC 3935 assigns the IETF with the goal to make the Internet wor= k better: "The mission of the IETF is to produce high quality, relevan= t technical and engineering documents that influence the way people design,= use, and manage the Internet in such a way as to make the Internet work be= tter.=A0 These documents include protocol standards, best current practices= , and informational documents of various kinds".
=A0
Standards are well defined in RFC 3935: "As used here, the term= describes a specification of a protocol, system behaviour or procedure tha= t has a unique identifier, and where the IETF has agreed that "if you = want to do this thing, this is the description of how to do it".=A0 It= does not imply any attempt by the IETF to mandate its use, or any attempt = to police its usage - only that "if you say that you are doing=A0 this= according to this standard, do it this way".=A0 The benefit of a stan= dard to the Internet is in interoperability - that multiple products implem= enting a standard are able to work together in order to deliver valuable fu= nctions to the Internet's users."
=A0
As a result, this WG should make it clear that any derivative work w= here additional neutrality, security, or operational additional constraints= that is based upon privately contracted situations that would not fully re= spect "its description of how to do it", including its principles= for derivative work, might not be interoperable and, therefore, should not= be attempted by ICANN and IDNA having entered into a comparable MoU with t= he IETF. This restriction is a consequence of the IETF RFC 2860 obligations= to properly advise ICANN.

RFC 3935 also states: "The Internet isn't value-neutral, and n= either is the IETF.=A0 We want the Internet to be useful for communities th= at share our commitment to openness and fairness.=A0 We embrace technical c= oncepts such as decentralized control, edge-user empowerment and sharing of= resources, because those concepts resonate with the core values of the IET= F community.=A0 These concepts have little to do with the technology that&#= 39;s possible, and much to do with the technology that we choose to create.= "
=A0
What is discussed in this very memo shows that IDNA2008 may lead to = important, yet potentially disruptive, innovations that the IETF, ICANN, ID= NOs and Internet Users should collectively evaluate and canalize. IDNA2008 = permits misuses that they all should oppose in unison.

Jean-Michel de Portzamparc

(*) The WG/IDNABIS Chair wrote on 200= 9/12/29 that: "It has been suggested that a better forum in which to d= eal with IDNA2003 and IDNA2008 incompatibility is the ICANN IDN Guidelines = Committee. That may be a better forum with broader participation than the I= DNABIS working group in which the TR46 proposal or other proposals may be d= iscussed. If we adopt Cary Karp's offer, your observations, below, woul= d be input into the Guidelines committee discussions." For years, none= of the participants to this note has succeeded to participate to the ICANN= process on an individual basis or through an ICANN constituency.

(**) france@large has answered the French Government pending public cal= l for candidates to manage the ".fr" namespace (This answer has b= een published as a book and can be found at http://www.lulu.com/c= ontent/paperback-book/pni/7143574). As part of this response it noted i= ts interest to manage the ".tf" TLD and to orient it towards Fren= ch litterature (Textes Fran=E7ais). It also is one of the technical sponsor= s of Project.FRA and a Member of the A-FRA (http://a-fra.org). The gTLD policy published by ICANN s= ince its Paris meeting permitted ".FRA" to start proposing French= IDNs in parallel with AFNIC (".fr") even if the French Governmen= t continued to procrastinate or did not retain france@large as the operator= of ".fr" or of "tf". The recent policy change introduc= ed by ICANN, in turn procratisnating about gTLDs, gives AFNIC (.fr) an unfa= ir advantage in deploying French IDNs. Moreover if French language orthotyp= ography is not properly supported. Repeated documented requests and a pendi= ng I_D on the way to support them (http://www.ietf.org/id/draft-iucg-p= unyplus-03.txt) was systematically ignored by the Chair and you.

Project.FRA has a three phase deployment plan:
A. free test ULD (use= r level domain) in Interplus class IU (Internet Users)
B. non-profit no= n-free ULD zone in class IU
C. non-profit commercial IDNgTLD also in cla= ss IN and IU.

Phase A is now in pre-operations. Phase B will be initiated as soon as = the IDNA2010 BCP on the implementation, transition, and deployment of IDNA2= 008 is completed. Phase C should have been initiated as soon as ".fra&= quot; is in the ICANN Root file as a regular gTLD. Its purpose is to pay fo= r the Phase A and B voluntary and experimental project.


=A0----------------------------------------

At 21:33 01/12/2= 009, Lisa Dusseault wrote:
One example I discussed with Patrik yesterday= , was whether locale
might affect mapping. I'd like to get better in= sight into the general
understanding of that.

1. Could locale determine whether a PVALID ch= aracter should be mapped
into another PVALID character prior to followin= g the rules to turn
into an ALABEL?=A0 I believe the consensus answer is= probably SHOULD NOT
or MUST NOT because that would make domains with that valid character
un= reachable by software using those locale rules.

2. Could locale dete= rmine whether, or how, a DISALLOWED character is
mapped into a PVALID ch= aracter prior to getting an ALABEL?=A0 For
example:
=A0- in locale Laputa, disallowed character (x230) is not used = in the
local language, so it's not mapped, an error occurs so a user= seeing
that in a Web page can't reach any actual domain
=A0- in = locale Balnibarbi, (x230) is considered to be the same as O,
so it's mapped to 'o', and a Balnibarbi user reaches domainscontaining o's
=A0- in locale Glubbdubdrig, (x230) is considered to= be the
capitalized version of (x231) and a Glubbdubdrig user reaches a<= br> different set of domains containing 's

Note that none of these l= ocale rules would necessarily make domains
containing completely unreach= able to their users -- a Web page
containing a link with would be looked= up without mapping that
character to another (assuming the conclusion of point 1 above).

If = I'm reading between the lines correctly, communication is hampered
b= etween people who are writing under the assumption that this kind of
locale-dependent scenario is going to happen, and people who are
writing= under the assumption that this kind of locale-dependent
scenario ought = to be forbidden and nobody would try such a crazy
thing.


At 22:04 01/12/2009, Lisa Dusseault wrote:
I don't believe we know w= hat the WG consensus position is around how
strongly pre-lookup mappings= are recommended and in what use cases,
and how compatible optional pre-= lookup mappings are with IDNA2003
in-protocol mapping.

Agreeing with you to a large extent Vint, I bel= ieve there is a strong
consensus in the WG that mappings "aren'= t part of the protocol",
meaning mapping shouldn't be required = in all cases. Certainly,
registries shouldn't be required to automatically map any character
= into any other character before registering the mapped domain name:
bett= er to make the domain name holder be explicit about the exact
domain nam= e they are registering.=A0 We have also referred to use cases
involving client software doing lookup of domains that are already
suppo= sed to be valid, in which context an invalid character would
simply be a= software error rather than a situation that required
mapping. In this m= atter, we have consensus to do something different
in IDNA2008 vs IDNA2003.

I believe we also do have consensus in the = equivalence of A-label and
U-label forms and transformation in either di= rection.

After that it gets confusingly nuanced.=A0 We even discusse= d having a
different term for optional, pre-lookup mapping of user-typed-in
domain = names, including links found in HTML typed in by the HTML
author.=A0 I b= elieve we do have consensus in the WG that this type of
helpful mapping = is going to be implemented, for example in Web
browsers, as being a user experience that is preferred over a dialog
int= erruption or error.

So that leaves us with a great deal of progress = in IDNA2008, and a lot
that is decided by WG consensus, but still with a= gap in our total
consensus.=A0 Some people would prefer that optional, pre-lookup mappingbe wide open.=A0 Others would prefer would that although pre-lookup
map= ping should be optional, IF it is done, it MUST be done one way.
There&#= 39;s even room for a middle ground where there might be more than
one recommended standard set of mappings, but they should be done as a
m= atter of standardization and not as a matter of full implementer
discret= ion, if at all possible.=A0 There is room for splitting the
mappings ter= ritory up per-application: perhaps domains in HTTP URLs
and browser address bars should be mapped one way, but other types of
UR= Ls could follow "no mappings allowed" rules.

Finally, we h= ave the options around transition strategies (such as
bundling recommend= ations) that might allow us to come to consensus
regarding these optional pre-lookup mapping questions.

I appreciate = all the discussion that is leading us to a better
understanding of the i= ssues around those last issues, and developing
consensus regarding those= last options.


At 16:06 02/12/2009, Lisa Dusseault wrote:
I'd like to try t= o unpack some of the different use cases we're
talking about a littl= e more.

ISTM that use cases where the person following the link is t= he person
who is typing it in, are use cases that locale-dependent mapping might
b= e most useful.=A0 If I'm in a locale where (x230) is considered to bethe capitalized version of o (ASCII o),=A0 it might very well be most
helpful to make that mapping.=A0 Use cases where the same user is typingin the domain names that then looks them up include:
=A0- typing links = in the address bar
=A0- typing mail address in the To field of an email<= br> =A0- Writing a Web page, blog post or email, wherein I check that the
li= nks work before posting/sending my document

In contrast, the use cas= e where the person looking up the domain
F .example is not the person wh= o typed it in, then in most cases we
no longer know the intent or locale of the person who typed in the
domai= n.=A0 It may be the same locale as the person who is looking up the
doma= in but it may not be.=A0 The person who typed in the domain may have
int= ended f .example or foo.example, and may have tested that before
sending/posting the link, but we no longer have that information.=A0 Usecases include:
=A0- Following a HTTP link in any Web page, document, bl= og post, email, etc
=A0- Using a mailto link (explicit or implicit), e.g= . when one person
sends me another person's email address

We probably would all ag= ree that people follow links while Web
browsing far more often than they= type them in, and even when typing
in, auto-complete probably drastical= ly reduces the new cases of
from-scratch mapping and lookup.

However, we probably have quite dif= ferent assumptions about how much
Internet activity takes place among us= ers of a consistent locale.=A0 Can
we assume that Patrik wants interpret= ed as because he communicates
mostly in Swedish with Swedish users and mostly reads Swedish Web
pages?= =A0 Or must we assume that Patrik also gets email from german and
swiss = senders, and also reads Web pages (perhaps in English!) written
by Germa= n users who expected different mappingsH[H H\=99\[ avily on our model of a = user, and whether we're using ourselves as hypothetical examples or not= .

One slightly more solid question for browsers is, would it be entirely<= br>crazy to have different mapping algorithms for typed-in domain names
= than for links followed?=A0 There might be a locale-dependent mapping as well as a global mapping.=A0 (I assume that having every established
loc= ale mapping installed would be complete craziness.)

Another question= is: when posted links are followed, how often do we
know the locale whe= re the link was authored?=A0 Not that the browser
following the link would necessarily be able to apply the mappings of
th= e locale in which it was authored, but would it be slightly better
to ap= ply a global mapping than a mapping from a different locale?

Do any = authoring software clients fix up links as the user types?
When I type a link in a document, the authoring software often makes
tha= t link active.=A0 Is there any software that automatedly lower-cases?
= =A0If so, would such software also be likely to map to PVALID characters before the doc is finished?

At 20:35 02/12/2009, Lisa Dusseault wrote:
I don't see where tha= t principle begins and ends.=A0 If it were entirely true, zone operators wo= uld be entirely free to register xn--garbage as a domain, entirely free to = register DISALLOWED characters.

Since it is in the purview of IDNA designers to make a character valid = or disallowed,=A0 wouldn't also be in the purview of IDNA designers to = say something like "This character becomes valid on date 01/01/2020&qu= ot;, right?=A0 So why wouldn't it be in the purview of IDNA designers t= o also say something like "This character becomes fully valid on date = 01/01/2020, but until then, may be registered if it is bundled with another= sequence"?

Doncha love slippery slopes


At 00:15 03/12/2009, Lisa Dusse= ault wrote:
>>Would someone who understands IETF process better th= an I do please explain why the discussion
>> of that character ne= eds to proceed any further?


Even if this is a rhetorical question, I'll bite.=A0 It's b= ecause the IETF makes decisions by rough consensus and running code.=A0 Rou= gh consensus is among informed participants as well as experts and people i= n certain positions of authority or responsibility.=A0 Running code certain= ly brings in browser/client implementation history and current client imple= mentation concerns.=A0 It is not only operators of the countries where thos= e languages are most spoken, that have collateral effects from the status o= f the characters of those languages in IDNA.


At 01:46 03/12/2009, Lisa Dusseault wrote:
Your argument is a fa= ir argument to try to influence the consensus, but it is not a fair argumen= t to overrule a consensus (not that I'm saying you are doing that).=A0= =A0 We do rely on most IETF participants being constructive most of the tim= e.=A0 We just have no other process besides appealing to people who are for= ming the consensus to look at running code, reality, security concerns and = so on.


At 05:01 03/12/2009, Lisa Dusseault wrote:
I did claim that runn= ing code was an important influence on a WG consensus, by tradition, habit = and official encouragement.=A0
=A0- First, that doesn't mean it'= ;s the only influence, or the most important influence in some consideratio= ns.
=A0- Second, the term is used both strictly, as in to demonstrate interoper= ability directly, and also loosely. By loose interpretations of "runni= ng code" you could claim that how a country uses a character in printe= d books was a form of deployed code that can be used as factual evidence.= =A0


At 23:41 04/12/2009, Lisa Dusseault wrote:
I've been having = trouble understanding how TRANSITIONAL characters that could not be mapped = or looked up by clients would help us out here.=A0 (You're not the only= one Erik, I was just thinking of this offline)

If I understand correctly, Web browsers in particular visit a corpus of= Web pages with links that they would like to not only continue to support,= but also continue to resolve to the same host (absent other changes).=A0 S= o on the day that somebody upgrades to the new version of a browser with ID= NA2008, their link destinations for TRANSITIONAL characters do not change.<= br>
"Do not change" also means that the user doesn't suddenly= start getting an error trying to follow a link with a TRANSITIONAL charact= er in the domain.

I agree that in some models, an error is better th= an going to an indeterminate destination.=A0 But only in some models.=A0 To= the user, upgrading their browser and suddenly having links with in domain= s fail where it succeeded the day before, does not seem like a real upgrade= .

=A0


--0016e68ee2bc3fac9e047b308625-- From mfberny@gmail.com Tue Dec 22 04:52:42 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 32D1D3A688B for ; Tue, 22 Dec 2009 04:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.902 X-Spam-Level: X-Spam-Status: No, score=0.902 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_8BIT_HEADER=0.3] 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 qz8sEGNgpYxz for ; Tue, 22 Dec 2009 04:52:41 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id BB7913A683D for ; Tue, 22 Dec 2009 04:52:40 -0800 (PST) Received: by ewy6 with SMTP id 6so4097357ewy.29 for ; Tue, 22 Dec 2009 04:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vNsJ0/58TS5mCwW9d36qPnJkO8hQo18efFsfl7jEtYk=; b=jOmdqE1PKDxpinoG16BqAieMeULbccFEj7rpHa8LlHD0TwImwZcTJG7D0OFjnGs3WA iSZTFMJivNO4adZcchdpukXgGecPMRwFAc3b5h0vKg9pxwih1xDh4Znq1dwT712uGvmU KSQXh1XgrccJKFWhKudF8fi4iDykqqaCo2ocM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g9E47ALlcS2xx6ycu2PCeJH3xthFi/RrvkkL6wI4RsVCT5/CoKv5qLsmt2suoMOQBZ rvgVwVGpRkY2c0EoV4ZMLfCEiWu0e+hBplIojR7liqXWtJjEHenzOMdcSxR5tJNL0ENc 7mpEZc21xICZdpQqaSeJcB4lnPmT5xwpmsohc= MIME-Version: 1.0 Received: by 10.213.24.24 with SMTP id t24mr9990890ebb.90.1261486339459; Tue, 22 Dec 2009 04:52:19 -0800 (PST) In-Reply-To: <0F891B58-E576-4C64-96FC-0D816AE28572@frobbit.se> References: <200912220228.nBM2S3w04147@birdie.sybase.com> <0F891B58-E576-4C64-96FC-0D816AE28572@frobbit.se> Date: Tue, 22 Dec 2009 13:52:19 +0100 Message-ID: <58ee45520912220452k1f9d0b8fn18422ea79336010c@mail.gmail.com> From: Marie-France Berny To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/alternative; boundary=000e0cdfc5be270b40047b50ad2f Cc: Vint Cerf , workon@idna2010.org, idna-update@alvestrand.no, internet users contributing group , Kenneth Whistler Subject: Re: [iucg] idna-mapping update 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, 22 Dec 2009 12:52:42 -0000 --000e0cdfc5be270b40047b50ad2f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Patrik, I shut my mouth for a long for two reasons. (1) As a Jedi (Jefsey's Disciple) I will not be listen to. (2) Because I felt that what characterizes the termination of this WG is confusion. You, Harald, John came with the demand for a job to be done. That job was confirmed by the IESG and IAB under the form of a Charter. Jefsey asked if the Charter or the Users' need was the limit. Vint answered the Charter. They opposed when Vint wanted the IETF to be the limit. That was corrected. And we had a very satisfactory solution. Unexpectedly that solution was opposed by the AD using out the limit questions (no-mapping says the Charter, why asks the AD; IDNA says the Charter, will IDNA work asks the AD; minimize the transition issues says th= e Charter; what about the aesthetics of GG's (Greek and German "s"s) asks the AD, etc.). In the meanwhile ICANN has upset the better half of the world in stating that its non-roman ccTLDs Fast Track was the new limit. A new limit they committed to describe publicly but do not so far, in spite of the support of the Chair. 2009/12/22 Patrik F=E4ltstr=F6m But, more importantly, TR46 is a Unicode Document. Not an IETF document. Discussions about that document should be in the proper venue. And Unicode Consortium just like ICANN is waiting for us in IETF to "just be done" so they (and W3C and whatever else) can do "their job". I am pretty sure I think we have enough good text in the mappings document and in rationale. We talk about transition, we talk about mappings etc, but...I do not think IETF is the correct venue for that work. Sure, we have a pretty good document. However there are people who dislike that it is so pretty good. So they made it lame. Not obsolete, but lame, because it is part of architecture, and that architecture (IDNA) is lame. W= e all know that the AD's questions are pertinent. But this IETF/WG was NOT th= e venue retained for that work. The good venue is either: - the IAB, if we want the solution to be an act of God. However, would the IAB be a multilinguistic god we would know it for a long. - the IETF Users. This currently means ICANN, GDNS, Asia, IUCG, may be ITU on one side and the manufacturers (Browsers), services (Search Engines) and Internet Users on other sides. Patrick Suger told the AD position does not make technical sense: to forwar= d the document set and question the Mapping document the document set consensus is built upon. True. However, it makes a pretty governance sens. It spells out to the IESG: "her= e is the whole problem, due to ICANN Seoul policy u-turn, Unicode incertitudes, Microsoft push, Asian absence, IUCG possible extended architecture and appeals, we cannot address it smoothly anymore at WG level as we all hoped and worked it out. They are going to oppose at an architectural level which may rebuild the whole Internet as ICANN and IUCG claim it does. I cannot address this alone in three months." IMHO, until IESG discusses it on January 7th we can have a nice familly Xma= s time, and for some to pray for the Internet Users not to have a real IDNA2010 solution by their own that would actually enforce IDNA2008 and ... French Majuscules (be sure nothing will be spared to you as long as Project.FRA cannot be in the root before AFNIC sells IDNs, and that IDNs ar= e case sensitive as our real target (Intersem) requires it, sorry but French speakers [from everywhere] aslo are stubborn :-)) Merry Xmas to all. Marie-France Berny (JD) --000e0cdfc5be270b40047b50ad2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Patrik,

I shut my mouth for a long f= or two reasons. (1) As a Jedi (Jefsey's Disciple) I will not be listen = to. (2) Because I felt that what characterizes the termination of this WG i= s confusion.

=A0You, Harald, John came with the demand for a job to be done. That jo= b was confirmed by the IESG and IAB under the form of a Charter. Jefsey ask= ed if the Charter or the Users' need was the limit. Vint answered the C= harter. They opposed when Vint wanted the IETF to be the limit. That was co= rrected. And we had a very satisfactory solution.

Unexpectedly that solution was opposed by the AD using out the limit qu= estions (no-mapping says the Charter, why asks the AD; IDNA says the Charte= r, will IDNA work asks the AD; minimize the transition issues says the Char= ter; what about the aesthetics of GG's (Greek and German "s"s= ) asks the AD, etc.). In the meanwhile ICANN has upset the better half of t= he world in stating that its non-roman ccTLDs Fast Track was the new limit= . A new limit they committed to describe publicly but do not so far, in spi= te of the support of the Chair.

2009/12/22 Patrik F=E4ltstr=F6m <patrik@frobbit.se= >
But, more importantly, TR46 is a Unicode Document. Not an IETF document. Discussions about that document should be in the proper venue. And Unicode Consortium just like ICANN is waiting for us in IETF to "just be done" so they (and W3C and whatever else) can do &quo= t;their job".

I am pretty sure I think we have enough good text in the mappings document and in rationale. We talk about transition, we talk about mappings etc, but...I do not think IETF is the correct venue for that work.

Sure, we have a pretty good document. However there are = people who dislike that it is so pretty good. So they made it lame. Not obs= olete, but lame, because it is part of architecture, and that architecture = (IDNA) is lame. We all know that the AD's questions are pertinent. But = this IETF/WG was NOT the venue retained for that work. The good venue is ei= ther:

- the IAB, if we want the solution to be an act of God. However, would = the IAB be a multilinguistic god we would know it for a long.
- the IETF= Users. This currently means ICANN, GDNS, Asia, IUCG, may be ITU on one sid= e and the manufacturers (Browsers), services (Search Engines) and Internet = Users on other sides.

Patrick Suger told the AD position does not make technical sense: to fo= rward the document set and question the Mapping document the document set c= onsensus is built upon. True.

However, it makes a pretty governance = sens. It spells out to the IESG: "here is the whole problem, due to IC= ANN Seoul policy u-turn, Unicode incertitudes, Microsoft push, Asian absenc= e, IUCG possible extended architecture and appeals, we cannot address it sm= oothly anymore at WG level as we all hoped and worked it out. They are goin= g to oppose at an architectural level which may rebuild the whole Internet = as ICANN and IUCG claim it does. I cannot address this alone in three month= s."

IMHO, until IESG discusses it on January 7th we can have a nice familly= Xmas time, and for some to pray for the Internet Users not to have a real = IDNA2010 solution by their own that would actually enforce IDNA2008 and ...= French Majuscules (be sure nothing will be spared to you as long as Projec= t.FRA cannot be in the root before AFNIC sells IDNs, and that IDNs are case= sensitive as our real target (Intersem) requires it, sorry but French spea= kers [from everywhere] aslo are stubborn :-))

Merry Xmas to all.

Marie-France Berny (JD)




--000e0cdfc5be270b40047b50ad2f-- From jefsey@jefsey.com Wed Dec 30 19:35:15 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 B377F3A67C1 for ; Wed, 30 Dec 2009 19:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.304 X-Spam-Level: X-Spam-Status: No, score=0.304 tagged_above=-999 required=5 tests=[AWL=-1.617, BAYES_50=0.001, DEAR_SOMETHING=1.605, SARE_MILLIONSOF=0.315] 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 g-tnsjqXFF4R for ; Wed, 30 Dec 2009 19:35:14 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id CE8203A67C0 for ; Wed, 30 Dec 2009 19:35:14 -0800 (PST) Received: from 89-158-60-168.rev.dartybox.com ([89.158.60.168]:4182 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NQBoA-0004dT-0e; Wed, 30 Dec 2009 19:34:42 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 31 Dec 2009 04:25:45 +0100 To: iucg@ietf.org From: jefsey In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091231033514.CE8203A67C0@core3.amsl.com> Cc: nicolas1.krebs3@netcourrier.com, workon@idna2010.org, "idna-arabicscript@lists.irnic.ir" Subject: [iucg] from unique to multi DNS 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, 31 Dec 2009 03:35:15 -0000 At 23:18 30/12/2009, nicolas1.krebs3@netcourrier.com wrote: > > As Rod Beckstrom put-it, the Internet is going to change for the first time > > in 40 years. Switching from English ASCII passive content prototyping to > > full multi-lingual active content services operations. This is not a small > > thing. We are better to help people prepare for it. > >Dear Sir, >I am afraid I do not understand this. At 23:20 30/12/2009, nicolas1.krebs3@netcourrier.com wrote: >I guess that Marie-France Berny was talking about >"which part of 'unique' are you having trouble understanding?" >quoted in >http://www.ietf.org/mail-archive/web/ietf/current/msg28487.html (six >years ago) and in >http://www.ietf.org/mail-archive/web/ietf/current/msg37426.html >(four years ago). Dear Internet Users, Uniqueness is first a target necessity for a prototype, to find the best solution. Then it becomes robustness. Then it may become a limitation to be addressed. RFC 1958 has all of it: " Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." RFC 1958 also states: "4.2 A single naming structure should be used.". The Internet uses a single naming structure. For Information RFC 2826 adds that this single naming structure should use a single root file. The US Government decided it should be managed by ICANN. On an other hand the naming structure of the human language is heterarchical. Until now it has been accepted that IDNA was a linguistic extension of the Internet naming structure that would support human languages at user application level. IDNA2003 was consistent with that view through the Nameprep constraints. However, objections discussed a long ago stand. "Mapping" considers them. And IDNA2008 defines a syntax which eventually might allow to address them (but cases like French majuscules). Why is the AD raising questions? This is because IDNA is _not_ an extension of the Internet naming structure. It is a support of the human language naming structure at user applications level that takes advantage from the DNS resolution service. This leaves us with two unresolved problems : - (1) to embed properly the use of the DNS service within the application diversity - (2) to organise the hierarchical Internet single naming structure management in order to support the human heterarchic naming structure. Up to now, the envisioned solution to (2) was to curb the human language heterarchy as a first level of the single physical root. Hence the UNICODE/ICANN/GAC/UK madness about IDNA 3166 and RFC 4647. That madness was addressed for the RFC4646 and killed by an ISO vote. IDNA2008 definitely buries that possibility. This is because with IDNA URLs are not directly resolved by the DNS, they are pre-resolved by the user application architecture that Lisa asks to be clarified (this means to address problem (1)). The first question is: how will we make sure that two applications on the same machine resolve the same name in the same IP address. It is not only a "transition" issue that ICANN Guidelines could address, it is an immediate architectural issue which defeats the very IDNA principle. Then, once this is addressed, we need to document how we will make this application architecture to depend on a single root namespace, while that user side architecture can access and/or manage roots the way they want. When this WG began, we asked the Chair if his intent was to address the users' needs or to fulfill the Charter. James Seng answered it was not to address the users needs. The Chair confirmed. We said we would complete the task after the Charter would be full filed and IDNA2008 approved by the IESG. When some of us objected what could impeach such a completion they were banned. This lead to the IUCG. Now, the Chair has declared the Charter has been full filed. The AD has forwarded the Document set to the IESG (except the Mapping document which permits IDNA2008). So we are left with the two main issues : - (1) a user side architecture that permits stability [the IUCG proposes one that it names "interplus"] - (2) a community management of the IDN namespace that insure this permitted stability. This was foreseen by ICANN (ICP-3 document). We (IUCG leaders) have been the only ones to carry the requested testing. From this community experimentation we know that the only concept that matches the DNS required hierarchy and the language heterarchy is a Virtual Root. We also know that it cannot be managed in the way the NTIA physical root is managed and supported by ICANN. The Virtual Root can include millions of TLDs. Because, no one else carried the ICANN ICP-3 requested testing, and because we (our dot-root test-bed) did not have the budget capacity to carry a true intertesting of the necessary intergovernance of the unique internet namespace, we do not have a solution. At the same time, we know that ICANN's war declaration to IDNgTLDs (Fast Track TLD only being introduced in the root file) puts an enormous pressure on us. This is because the Internet Plus (to use the existing internet along the Interplus concepts) permits to access our .FRA, .Multilinc and .PERFIDA domain names, the 500 ICANN candidate (IDN)gTLD, and much more at everyone decision and for free. The problem they have to address - without any charter and any IDNA guidance - is an Internet Adminance (technical administration governance) where everyone is his own "MYCANN". Best wishes for a exciting 2010! jfc From jefsey@jefsey.com Thu Dec 31 08:07:55 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 58D723A6A15 for ; Thu, 31 Dec 2009 08:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_50=0.001, SARE_MILLIONSOF=0.315] 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 Dkon0bLAmnkB for ; Thu, 31 Dec 2009 08:07:54 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 681963A69D5 for ; Thu, 31 Dec 2009 08:07:54 -0800 (PST) Received: from 89-158-60-168.rev.dartybox.com ([89.158.60.168]:1764 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1NQNYS-0003lD-LX; Thu, 31 Dec 2009 08:07:22 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 31 Dec 2009 16:57:38 +0100 To: iucg@ietf.org From: JFC Morfin In-Reply-To: <200912310335.nBV3YxoZ014700@ns1.irnic.ir> References: <200912310335.nBV3YxoZ014700@ns1.irnic.ir> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <20091231160754.681963A69D5@core3.amsl.com> Subject: [iucg] from unique to multi DNS 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, 31 Dec 2009 16:07:55 -0000 At 09:17 31/12/2009, xxxx wrote: >>At the same time, we know that ICANN's war declaration to IDNgTLDs >>(Fast Track TLD only being introduced in the root file) puts an >>enormous pressure on us. This is because the Internet Plus (to use >>the existing internet along the Interplus concepts) permits to >>access our .FRA, .Multilinc and .PERFIDA domain names, the 500 >>ICANN candidate (IDN)gTLD, and much more at everyone decision and for free. >> >>The problem they have to address - without any charter and any IDNA >>guidance - is an Internet Adminance (technical administration >>governance) where everyone is his own "MYCANN". > >Got you! But what makes this different with TLDA's open roots. They >also can support all the 500 ICANN candidate gTLDs. This private response raises a important point. The difference is that TLDA, TLDA, etc. maintain physical root files. We are talking today of the transition from physical to virtual root file. This means from a decentralized unique naming structure obeying the icann centric paradigm to a distributed unique naming structure obeying the cosmological principle. TLDA includes the NTIA root file, so it can be labeled as "open". However, ICANN has the double concern that: - they make their living out of taxing Class IN, NTIA root file, domain names. TLDA is their commercial competition. ".biz" was used by ICANN to challenge the TLDA lack of conflict. - a very large root file, with 95%+ of erroneous calls and scores of millions dependent domain names might go beyond the RSS possible machines' capacity. This makes sense because their technical (IETF), political (GAC), economic (ISOC), civil society (IGF), industrial (Unicode Consortium), CORE etc. (Registry, registrars), CENTR (ccTLDs), etc. "stakeholders" share the culture of dumb-stupid UIs that: - do not support classes (however ICANN alluded to them in ICP-3). Our recently deceased friend Francis Muguet had succeded in initiating an ITU study on them. - are to be the applications that support IDNA (possibly in different ways, thanks to TR46). IDNA2008 breaks all that. Because it demands different applications (namely IE, Firefox, Chrome, Opera) to behave the same (like IDNA2003) but in using different codes and no more the same Nameprep. This allows - for example - Unicode to discuss with browser developpers how they can compete as being Unicode conformant. While, Unicode does not even support French majucules. This is why I suggest for years that IDNA be a Unicode application. Anyway, IDNA2008 + Unicode, put a perpetually punybrowser/hacker algorithm cacophonic transition at the core of the Internet. While it was to reduce it. This breaks the architectural unicity and MUST be corrected. To do that, IDNA2008 must be used outside UIs. Not _in_ applications, but _as_ an application. The question is where. From experience and logic we can say "down the DNS nameserver side". This can only be: - at the 16.5 millions of existing nameservers (this is in opposition to the IDNA concept) - at the user side in embedding a nameserver in their IDNA application. Then the point is "who are the users?" 1. The Chair keeps thinking in the pre-IDNA2008 way and says: ICANN. This make sense. However ICANN knows about legal contracting, not about network technical architectural innovation. They also contracted with at most 0,0000001% of the involved zone managers, even including the ccTLDs they drag into the ccNSO through "Fast Track". Obviously some of the zone managers under ICANN contract have very large static domain name tables. But will that continue to be the same criteria in a post-IDNA namespace usage and economy. 2. JEDI ("Jefsey disciples" :-)) show that their usage of the Fellowship Optimisation through Revised Continuities and Extensions (FORCE) works well! It only means to use a punyplused version of BIND on IDNA users machines and remove IDNA support from bowsers. This has changed the root of unicity. It is no more content unicity from a unique network name server system, it is network unicity from content unicity through a unique IDNAlliance. Also remember that LISP and IDv6 may remove part of the addressing rigidity. Those who adhere to the "which part of unicity dont you understand" joke show they have not understood what unicity is. We all are part of the naming virtual unicity. Now how do we build and protect it is the question. It is no more imposed by stakeholders. It has to be worked out by all of Internet Fellows. At the end of the day we may have billion ULDs (our user based TLD equivalent) supporting much more services than static IP address resolution. This has to work. Until Seoul there was no real harm in giving people some time to think. ICANN made three mistakes: 1. they asked the Chair to speed-up, so the AD could only raise her questions quickly endangering the whole process. 2. they do (cf. "Fast Track" and Rod's world tour) as if an operational IDNA solution did exist. Fast Track will permit to discover it does not (yet). 3. they divided and opposed the concerned parties (IDNg/ccTLDs) while we all have to ally to protect our common interests and reshape our economy. Happy new year. jfc