From jefsey@jefsey.com Wed Jul 1 05:43:11 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 BAE8B28C5FD for ; Wed, 1 Jul 2009 05:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 H9qul7n1YkLQ for ; Wed, 1 Jul 2009 05:43:10 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id B88383A6F2F for ; Wed, 1 Jul 2009 05:24:15 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:1999 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MLypt-0003tT-CF; Wed, 01 Jul 2009 05:22:49 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Jul 2009 14:19:06 +0200 To: Vint Cerf From: JFC Morfin In-Reply-To: References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> 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: <20090701122415.B88383A6F2F@core3.amsl.com> Cc: Andrew Sullivan , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 01 Jul 2009 12:43:11 -0000 At 04:18 01/07/2009, Vint Cerf wrote: >jefsey, it cannot be an A-label since that is defined to include >"xn--" as a prefix. Dear Vint, This is the conflict we have and the resulting confusion. - usage considers what is enter in usage applications (from the entire Unicode set [actually it needs much more (ex.Natal from M$] _including_ ASCII) - I consider what the DNS is asked to resolve after an algorithm (including null and punycode ones) has been applied. - you consider complex U-/A-... labels which do not overlap. "Ecole.fra" is not supported by this label list. "Ecole.fra", 1) it is a U-label 2) but you do not want to support it as xn--cole-abc.fra. You keep it as an non punycoded yet A-label without "xn--" prefix. 3) this confuses Andrew and John (who should not be concerned) because they try to understand how the DNS and Unicode casefolding could support the orthogonal User's casefolding (i.e. orthotypography). I see no other solution that to carry the mapping: - at the user application layer (outside of the Internet pile) and the Internet should remain transparent to "xn--" labels. - through a different presentation, and casefolding mapping etc. using "xs--" labels. Neither DNS nor Unicode casefolding are concerned. Only usage's side application (this is why the architecture is named IDNA): usage casefolding is to be decided and managed by the user through his application (if he wants to have it), depending on his own context, language, culture, job, kind of application, etc. and if the other end supports additional usage side features. This permits an application to application relation, where entropic actions (as required by the DNS resolution) can be restored through a negantropic process supported by metadata exchanges. As Elisabeth explained it. This being said, if you find a case (so far there is none) where a entropic mapping (casefolding or other) is universally accepted by users - or restored through a negentropic process such as what we call "duplex entities" -, supported by exvery encryption system, transparent to other technologies as well (netneutrality), etc. it could very well be investigated at protocol level (i.e within the Internet pile). Otherwise mapping can only be processed outside of the Internet pile. This is exactly the target and Charter of IDNA as I read and respect it. jfc >On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote: > >>At 17:12 30/06/2009, Andrew Sullivan wrote: >>>and, in particular, if we want to be sensitive to such upper and >>>lower case when the data comes back to us from the DNS resolver >>>level. >> >>Please, let not confuse : >> >>1) the DNS layer, where you run the game the way you want according >>to your published rules, and the Application Domain Names. >>2) French majuscules and upper cases. >> >>The U-label, A-label, etc. wording IMHO helps that confusion. Is >>Ecole.fra an U-label or an A-label? All I know is that it is an >>application domain name (like in "IDNA"). Also, that if the proposed >>text does not actually document the "ecole.fra, école.fra, >>Ecole.fra" case, this case will have to be documented during the >>IETF/LC. >> >>May be it is the best thing to do? so the whole IETF community may >>decide what does concern the whole community? >>jfc >> >>_______________________________________________ >>Idna-arabicscript mailing list >>Arabic Script IDN Working Group (ASIWG) >>Idna-arabicscript@lists.irnic.ir >>http://lists.irnic.ir/mailman/listinfo/idna-arabicscript From vint@google.com Wed Jul 1 06:10:27 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 D64F128C52B for ; Wed, 1 Jul 2009 06:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 kXqBZEq5XZLP for ; Wed, 1 Jul 2009 06:10:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 4907F3A6F23 for ; Wed, 1 Jul 2009 06:10:26 -0700 (PDT) Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id n61CcO3d030506 for ; Wed, 1 Jul 2009 13:38:25 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1246451905; bh=7OfhWcYeTNZdHFaj7s/NUO4LLe4=; h=DomainKey-Signature: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=Yv5oDC5aTvjVpA8BQUlc97Ki wBQVmKkXQBYCwLNSt/By0H2Xs6A0lG2HWqsqtpI6gxWZjbbMk+3ssilV3hKVug== 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=HiqNsBJvxwvJ5JjjByptROti8DGxX4qZhCaz0V1AhpJ+ArX62L5fYbpYdSB1exQg4 IZt5jiSRw4YWw6lfA081Q== Received: from rv-out-0708.google.com (rvfc5.prod.google.com [10.140.180.5]) by zps36.corp.google.com with ESMTP id n61CcLMe021546 for ; Wed, 1 Jul 2009 05:38:22 -0700 Received: by rv-out-0708.google.com with SMTP id c5so331508rvf.38 for ; Wed, 01 Jul 2009 05:38:21 -0700 (PDT) Received: by 10.140.199.15 with SMTP id w15mr3495176rvf.231.1246451901740; Wed, 01 Jul 2009 05:38:21 -0700 (PDT) Received: from 207-105-81-184.ded.pacbell.net ([207.105.81.184]) by mx.google.com with ESMTPS id g14sm5231568rvb.34.2009.07.01.05.38.18 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Jul 2009 05:38:19 -0700 (PDT) Message-Id: <8FB03160-1D7F-4E73-8F6C-16093771E1AB@google.com> From: Vint Cerf To: JFC Morfin In-Reply-To: <200907011222.n61CMrPx001109@smtp.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Jul 2009 08:38:16 -0400 References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> <200907011222.n61CMrPx001109@smtp.google.com> X-Mailer: Apple Mail (2.930.3) X-System-Of-Record: true Cc: Andrew Sullivan , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 01 Jul 2009 13:10:27 -0000 Jefsey, maybe my email rendering code is broken but the string I am =20 seeing in your message looks like a purely ascii string making it a =20 conventional ascii domain name not requiring any special treatment. vint On Jul 1, 2009, at 8:19 AM, JFC Morfin wrote: > At 04:18 01/07/2009, Vint Cerf wrote: >> jefsey, it cannot be an A-label since that is defined to include >> "xn--" as a prefix. > > Dear Vint, > This is the conflict we have and the resulting confusion. > > - usage considers what is enter in usage applications (from the =20 > entire Unicode set [actually it needs much more (ex.Natal from M$] =20 > _including_ ASCII) > - I consider what the DNS is asked to resolve after an algorithm =20 > (including null and punycode ones) has been applied. > - you consider complex U-/A-... labels which do not overlap. =20 > "Ecole.fra" is not supported by this label list. > > "Ecole.fra", > 1) it is a U-label > 2) but you do not want to support it as xn--cole-abc.fra. You keep =20 > it as an non punycoded yet A-label without "xn--" prefix. > 3) this confuses Andrew and John (who should not be concerned) =20 > because they try to understand how the DNS and Unicode casefolding =20 > could support the orthogonal User's casefolding (i.e. =20 > orthotypography). > > I see no other solution that to carry the mapping: > - at the user application layer (outside of the Internet pile) and =20 > the Internet should remain transparent to "xn--" labels. > - through a different presentation, and casefolding mapping etc. =20 > using "xs--" labels. > > Neither DNS nor Unicode casefolding are concerned. Only usage's side =20= > application (this is why the architecture is named IDNA): usage =20 > casefolding is to be decided and managed by the user through his =20 > application (if he wants to have it), depending on his own context, =20= > language, culture, job, kind of application, etc. and if the other =20 > end supports additional usage side features. This permits an =20 > application to application relation, where entropic actions (as =20 > required by the DNS resolution) can be restored through a =20 > negantropic process supported by metadata exchanges. As Elisabeth =20 > explained it. > > This being said, if you find a case (so far there is none) where a =20 > entropic mapping (casefolding or other) is universally accepted by =20 > users - or restored through a negentropic process such as what we =20 > call "duplex entities" -, supported by exvery encryption system, =20 > transparent to other technologies as well (netneutrality), etc. it =20 > could very well be investigated at protocol level (i.e within the =20 > Internet pile). Otherwise mapping can only be processed outside of =20 > the Internet pile. This is exactly the target and Charter of IDNA as =20= > I read and respect it. > > jfc > > >> On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote: >> >>> At 17:12 30/06/2009, Andrew Sullivan wrote: >>>> and, in particular, if we want to be sensitive to such upper and >>>> lower case when the data comes back to us from the DNS resolver >>>> level. >>> >>> Please, let not confuse : >>> >>> 1) the DNS layer, where you run the game the way you want according >>> to your published rules, and the Application Domain Names. >>> 2) French majuscules and upper cases. >>> >>> The U-label, A-label, etc. wording IMHO helps that confusion. Is >>> Ecole.fra an U-label or an A-label? All I know is that it is an >>> application domain name (like in "IDNA"). Also, that if the proposed >>> text does not actually document the "ecole.fra, =E9cole.fra, >>> Ecole.fra" case, this case will have to be documented during the >>> IETF/LC. >>> >>> May be it is the best thing to do? so the whole IETF community may >>> decide what does concern the whole community? >>> jfc >>> >>> _______________________________________________ >>> Idna-arabicscript mailing list >>> Arabic Script IDN Working Group (ASIWG) >>> Idna-arabicscript@lists.irnic.ir >>> http://lists.irnic.ir/mailman/listinfo/idna-arabicscript > From jefsey@jefsey.com Wed Jul 1 06:17:43 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 07DA028C527 for ; Wed, 1 Jul 2009 06:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 31aubbr0tmso for ; Wed, 1 Jul 2009 06:17:41 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 53D343A6EED for ; Wed, 1 Jul 2009 06:13:46 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:2242 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MLzcb-00079K-E2; Wed, 01 Jul 2009 06:13:10 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Jul 2009 15:13:07 +0200 To: Vint Cerf From: jefsey In-Reply-To: <8FB03160-1D7F-4E73-8F6C-16093771E1AB@google.com> References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> <200907011222.n61CMrPx001109@smtp.google.com> <8FB03160-1D7F-4E73-8F6C-16093771E1AB@google.com> 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: <20090701131346.53D343A6EED@core3.amsl.com> Cc: Andrew Sullivan , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 01 Jul 2009 13:17:43 -0000 At 14:38 01/07/2009, Vint Cerf wrote: >Jefsey, maybe my email rendering code is broken but the string I am >seeing in your message looks like a purely ascii string making it a >conventional ascii domain name not requiring any special treatment. Vint, The string you see on your screen is ASCII - the string I enter is not. This is because Unicode is being used and Unicode does not properly supports the French language orthotypography. In "Ecole.fra" the semantics demands that "E" is not an "E" ASCII but a French "E" majuscule. I am sure Unicode has no problem in supporting them, or TLD Tables can be used. "Ecole.fra" is a user domain name which may have nothing to do (except phishing) with "école.fra", "ecole.fra" and "École.fra". This means there are wo problems: - they are to be able to resolve different IP addresses. - they also are to be able to resolve the same IP address. However, the decision is only with the registrant. So, the simplest is to consider each usage domain name separately. If some are to resolve the same IP, the registrant will only register several domain names. jfc >On Jul 1, 2009, at 8:19 AM, JFC Morfin wrote: > >>At 04:18 01/07/2009, Vint Cerf wrote: >>>jefsey, it cannot be an A-label since that is defined to include >>>"xn--" as a prefix. >> >>Dear Vint, >>This is the conflict we have and the resulting confusion. >> >>- usage considers what is enter in usage applications (from the >>entire Unicode set [actually it needs much more (ex.Natal from M$] >>_including_ ASCII) >>- I consider what the DNS is asked to resolve after an algorithm >>(including null and punycode ones) has been applied. >>- you consider complex U-/A-... labels which do not overlap. >>"Ecole.fra" is not supported by this label list. >> >>"Ecole.fra", >>1) it is a U-label >>2) but you do not want to support it as xn--cole-abc.fra. You keep >>it as an non punycoded yet A-label without "xn--" prefix. >>3) this confuses Andrew and John (who should not be concerned) >>because they try to understand how the DNS and Unicode casefolding >>could support the orthogonal User's casefolding (i.e. >>orthotypography). >> >>I see no other solution that to carry the mapping: >>- at the user application layer (outside of the Internet pile) and >>the Internet should remain transparent to "xn--" labels. >>- through a different presentation, and casefolding mapping etc. >>using "xs--" labels. >> >>Neither DNS nor Unicode casefolding are concerned. Only usage's side >>application (this is why the architecture is named IDNA): usage >>casefolding is to be decided and managed by the user through his >>application (if he wants to have it), depending on his own context, >>language, culture, job, kind of application, etc. and if the other >>end supports additional usage side features. This permits an >>application to application relation, where entropic actions (as >>required by the DNS resolution) can be restored through a >>negantropic process supported by metadata exchanges. As Elisabeth >>explained it. >> >>This being said, if you find a case (so far there is none) where a >>entropic mapping (casefolding or other) is universally accepted by >>users - or restored through a negentropic process such as what we >>call "duplex entities" -, supported by exvery encryption system, >>transparent to other technologies as well (netneutrality), etc. it >>could very well be investigated at protocol level (i.e within the >>Internet pile). Otherwise mapping can only be processed outside of >>the Internet pile. This is exactly the target and Charter of IDNA as >>I read and respect it. >> >>jfc >> >> >>>On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote: >>> >>>>At 17:12 30/06/2009, Andrew Sullivan wrote: >>>>>and, in particular, if we want to be sensitive to such upper and >>>>>lower case when the data comes back to us from the DNS resolver >>>>>level. >>>> >>>>Please, let not confuse : >>>> >>>>1) the DNS layer, where you run the game the way you want according >>>>to your published rules, and the Application Domain Names. >>>>2) French majuscules and upper cases. >>>> >>>>The U-label, A-label, etc. wording IMHO helps that confusion. Is >>>>Ecole.fra an U-label or an A-label? All I know is that it is an >>>>application domain name (like in "IDNA"). Also, that if the proposed >>>>text does not actually document the "ecole.fra, école.fra, >>>>Ecole.fra" case, this case will have to be documented during the >>>>IETF/LC. >>>> >>>>May be it is the best thing to do? so the whole IETF community may >>>>decide what does concern the whole community? >>>>jfc >>>> >>>>_______________________________________________ >>>>Idna-arabicscript mailing list >>>>Arabic Script IDN Working Group (ASIWG) >>>>Idna-arabicscript@lists.irnic.ir >>>>http://lists.irnic.ir/mailman/listinfo/idna-arabicscript From jmabdp@gmail.com Wed Jul 1 07:12: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 5F9BC28C537 for ; Wed, 1 Jul 2009 07:12:55 -0700 (PDT) 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 KhICQpdrdb8j for ; Wed, 1 Jul 2009 07:12:53 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 3464D28C534 for ; Wed, 1 Jul 2009 07:12:53 -0700 (PDT) Received: by ewy6 with SMTP id 6so1156516ewy.37 for ; Wed, 01 Jul 2009 07:11:51 -0700 (PDT) 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=Y8UY4yB1XFBsFeY1EyCQnGwl1FaXRPQytImvRlu/D3Y=; b=PnBXPj7/rE6y853tztiQ9XK5TU35CZ3ZQ2dFIC0d3oXsajqXVzGgiZeLYkqXq8loI5 iIQC6Ryi1BLcvCMb+wyoH8E0FiQPx4B3Hc6Gs4j/zdaOgOOZvOMa2WOhEfDi44Ohofc6 5j6M7viBkyYMXSLBwZDSClghuV82st2AqWn6o= 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=cRvQOjZX41+clxZKZ2SXLty7WVvfPKpjMiI3bO/SOqSrh1X3p5ELUA6y0Af/gxwzkI 8H48Q98ebtmfL6z+RXEp+x6AQcreDnVOba+eDh/2FjsZScnMgFjUTNWl51gXHVa1Si5G 1y807bZ4yPDEjEZHnOQzoQX8jIok14YrCUNq8= MIME-Version: 1.0 Received: by 10.216.29.80 with SMTP id h58mr2764994wea.159.1246457508041; Wed, 01 Jul 2009 07:11:48 -0700 (PDT) In-Reply-To: <6aad7a210907010707s363152e6ha2e67a84f941142a@mail.gmail.com> References: <20090526011501.468193A6E44@core3.amsl.com> <0A2BDB123E910F2D087B6AF1@PST.JCK.COM> <4A49E907.4020808@it.aoyama.ac.jp> <6589127a0906301836r7a85037p5246a469dc256784@mail.gmail.com> <4A4AC3B6.2060800@abenaki.wabanaki.net> <6589127a0907010258y77acc9cev20d417a25603deea@mail.gmail.com> <3E9BF786-3800-43CE-9B5A-CC85C9F625E9@google.com> <6aad7a210907010544w1bcd9c71y2f9fed23157e98df@mail.gmail.com> <4E9B39D4-A191-4B56-803C-538E93A5D52E@google.com> <6aad7a210907010707s363152e6ha2e67a84f941142a@mail.gmail.com> Date: Wed, 1 Jul 2009 16:11:47 +0200 Message-ID: <6aad7a210907010711r64748fcfk80d96f397587e246@mail.gmail.com> From: jean-michel bernier de portzamparc To: idna-update@alvestrand.no, iucg@ietf.org Content-Type: multipart/alternative; boundary=0016e6de010ffe9607046da58095 Subject: Re: [iucg] I-D Action:draft-ietf-idnabis-mappings-00.txt 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, 01 Jul 2009 14:12:55 -0000 --0016e6de010ffe9607046da58095 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I send this mail again because it seemed there were too many cc"s. --------- 2009/7/1 jean-michel bernier de portzamparc > Dear Mr. Cerf, > I am afraid you have a total misreading of our position!!! > > Our "direction" works in test for years on and outside the Internet - > anyone can develop it in Perl in a couple of hours. It is based upon a to= tal > neutrality of the Internet and of the DNS. What we oppose in what you > consider is precisely that you disrpect the Charter and redesign the > Internet and IDNA. You want to introduce at protocol level (i.e. within t= he > Internet pile) new constraints that break the Internet technical neutrali= ty > in some cases. > > We do not really mind because these cases are very limited (at least for > the time being, but we realise that your appraoch may lead to various > attempt to control the Internet) However, in putting mapping at the > Internet (controlled) level for things that will be important for some > users, you create deployment issues and you make them lose interoperabili= ty > with the rest of usage. > > We document the Internet the way it actually is, including IDNA, active > content, presentation, DNS, etc.. This is because we need to be sure it c= an > support the Intersem (semantic, semiotic, multiclultural, etc.) stratum w= e > are interested in. This includes the use of the presentation and session > control layer. > > Jean-Michel A. Bernier de Portzamparc > > 2009/7/1 Vint Cerf > > Jean-michel, >> I consider this discussion to be outside the scope of the working group. >> In my opinion, the IDNA architecture has already been decided, based on = the >> constraints of the DNS itself. The direction you and others associated w= ith >> Jefsey want to pursue leads toward a re-design of DNS itself. I am not >> arguing against a serious consideration of such a thing, only that I don= 't >> consider it appropriate for the IDNABIS discussion. >> >> >> vint >> >> >> On Jul 1, 2009, at 8:44 AM, jean-michel bernier de portzamparc wrote: >> >> Dear Mr. Cerf, >> may be could you set-up this mailing list yourself as part of the WG? Th= e >> reason why is that this is not a theorical but an architectural discussi= on. >> As Elisabeth documents it, it will decide of the IDNA architecture. The >> worst situation would be that a discussion list you called for as a Chai= r, >> would conflict with this WG. >> >> Best >> Jean-Michel A. Bernier de Portzamparc >> >> Folks, >>> this discussion is not going to get us closer to agreement on the >>> remaining task: selection of the set of characters that should undergo = some >>> kind of mapping prior to lookup in the DNS. >>> >>> Could I suggest that parties interested in this theoretical discussion >>> move it to a private distribution list while the WG focuses on finalizi= ng >>> the mapping choices? >>> >>> thanks >>> >>> vint >>> >>> >>> On Jul 1, 2009, at 5:58 AM, Elisabeth Blanconil wrote: >>> >>> I understand this. But I am refering to entropy as "a loss of >>> information", as per Shannon and John. Now, I am not a mathematician he= re: I >>> am a semantician. This because we precisely reach here (and this is the >>> entire problem) the limits of mathematics. If we could quantify the ent= ropy >>> we could restore the initial information in restoring the corresponding >>> negentropy. >>> >>> The problem we face is that mapping introduce a non quantifiable entrop= y. >>> We definitly enter mathematical chaos field through the entropic succes= sion >>> which chains possible semantic misunderstandings. >>> >>> Varela (knowledge), Thom (mathematics), Cullioli (linguistics), Morin >>> (complex thinking), Von Bertalanffy (systems) etc. identify linguistics= , >>> semantics and pragmatics as the most complex knowlege field. Here we pl= ay >>> with hortotypography with an impact on semantic within different contex= ts. >>> For those not familiar with chaos and catastrophy theories or complex >>> thinking this is like the Lorentz's butterfly in Tokyo. You change a >>> majuscule into a minuscule (French orthotypography) or an upper case in= to a >>> lower case (English orthotypography) and you do not the global impact (= it >>> can be nill, most probably it will change the world, cf. Chaitin and co= .). >>> This is exactly the same as any other phishing: to make someone trust w= hat >>> he should not. >>> >>> Elisabeth Blanconil >>> >>> 2009/7/1 Eric Brunner-Williams >>> >>>> Any phrasing is possible. Some mean less than others. One of my >>>> co-workers was tempted to use "entropy" in a policy document recently.= I >>>> prefer not to use the word unless the "entropy" asserted to exist can = be >>>> stated as a mathematical formula. If you could make that attempt, it w= ould >>>> be helpful. Users deserve statements that purport to "explain" which a= re >>>> factually correct. >>>> >>>> Eric >>>> >>>> Elisabeth Blanconil wrote: >>>> >>>>> 2009/6/30 "Martin J. D=FCrst" >>>> duerst@it.aoyama.ac.jp>> >>>>> >>>>> >>>>> A case mapping is also a 'loss of information', but one that >>>>> people clearly want. >>>>> >>>>> >>>>> Could we not phrase this differently ? Case mapping may be considered >>>>> only if it does not represent a loss of information. Otherwise should= we not >>>>> name it "case and entropy mapping" to explain users where entropy occ= urs. >>>>> >>>>> Elisabeth Blanconil >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------= --- >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> _______________________________________________ >>> Idna-update mailing list >>> Idna-update@alvestrand.no >>> http://www.alvestrand.no/mailman/listinfo/idna-update >>> >>> >> >> > --0016e6de010ffe9607046da58095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I send this mail again because it seemed there were too many cc"s.
= ---------

2009/7/1 jean-michel bernier de= portzamparc <jmab= dp@gmail.com>
Dear Mr. Cerf,I am afraid you have a total misreading of our position!!!

Our &quo= t;direction" works in test for years on and outside the Internet - any= one can develop it in Perl in a couple of hours. It is based upon a total n= eutrality of the Internet and of the DNS. What we oppose in what you consid= er is precisely that you disrpect the Charter and=A0 redesign the Internet = and IDNA. You want to introduce at protocol level (i.e. within the Internet= pile) new constraints that break the Internet technical neutrality in some= cases.

We do not really mind because these cases are very limited (at least fo= r the time being, but we realise that your appraoch may lead to various att= empt to control the Internet)=A0 However, in putting mapping at the Interne= t (controlled) level for things that will be important for some users, you = create deployment issues and you make them lose interoperability with the r= est of usage.

We document the Internet the way it actually is, including IDNA, active= content, presentation, DNS, etc.. This is because we need to be sure it ca= n support the Intersem (semantic, semiotic, multiclultural, etc.) stratum w= e are interested in. This includes the use of the presentation and session = control layer.


Jean-Michel A. Bernier de Portzamparc

2009/7/1 Vint Cerf <vint@google.com>

Jean-michel,

I consider this discussion to be outsi= de the scope of the working group. In my opinion, the IDNA architecture has= already been decided, based on the constraints of the DNS itself. The dire= ction you and others associated with Jefsey want to pursue leads toward a r= e-design of DNS itself. I am not arguing against a serious consideration of= such a thing, only that I don't consider it appropriate for the IDNABI= S discussion.


vint


On Jul 1, 2009, at = 8:44 AM, jean-michel bernier de portzamparc wrote:

Dear Mr. Cerf,
may be could you set-up this mailing list yourself as par= t of the WG? The reason why is that this is not a theorical but an architec= tural discussion. As Elisabeth documents it, it will decide of the IDNA arc= hitecture. The worst situation would be that a discussion list you called f= or as a Chair, would conflict with this WG.

Best
Jean-Michel A. Bernier de Portzamparc

F= olks,=A0

this discussion is not going to get us closer to agreement o= n the remaining task: selection of the set of characters that should underg= o some kind of mapping prior to lookup in the DNS.

Could I suggest that parties interested in this theoretical discussion= move it to a private distribution list while the WG focuses on finalizing = the mapping choices?

thanks

vint

On Jul 1, 2009, at 5:58 AM, Elisabeth Blanconil w= rote:

I understand this. But I am referi= ng to entropy as "a loss of information", as per Shannon and John= . Now, I am not a mathematician here: I am a semantician. This because we p= recisely reach here (and this is the entire problem) the limits of mathemat= ics. If we could quantify the entropy we could restore the initial informat= ion in restoring the corresponding negentropy.

The problem we face is that mapping introduce a non quantifiable entr= opy. We definitly enter mathematical chaos field through the entropic succe= ssion which chains possible semantic misunderstandings.

Varela (kno= wledge), Thom (mathematics), Cullioli (linguistics), Morin (complex thinkin= g), Von Bertalanffy (systems) etc. identify linguistics, semantics and prag= matics as the most complex knowlege field. Here we play with hortotypograph= y with an impact on semantic within different contexts. For those not famil= iar with chaos and catastrophy theories or complex thinking this is like th= e Lorentz's butterfly in Tokyo. You change a majuscule into a minuscule= (French orthotypography) or an upper case into a lower case (English ortho= typography) and you do not the global impact (it can be nill, most probably= it will change the world, cf. Chaitin and co.). This is exactly the same a= s any other phishing: to make someone trust what he should not.

Elisabeth Blanconil

2009/7/1 Eric B= runner-Williams <ebw@abenaki.wabanaki.net>
Any phrasing is possible. Some mean less than others. One of my co-worker= s was tempted to use "entropy" in a policy document recently. I p= refer not to use the word unless the "entropy" asserted to exist = can be stated as a mathematical formula. If you could make that attempt, it= would be helpful. Users deserve statements that purport to "explain&q= uot; which are factually correct.

Eric

Elisabeth Blanconil wrote:
2009/6/30 "Martin J. D=FCrst"= <duerst@it.= aoyama.ac.jp <mailto:duerst@it.aoyama.ac.jp>>


=A0 =A0A case mapping is also a 'loss of in= formation', but one that
=A0 =A0people clearly want.


= Could we not phrase this differently ? Case mapping may be considered only = if it does not represent a loss of information. Otherwise should we not nam= e it "case and entropy mapping" to explain users where entropy oc= curs.

Elisabeth Blanconil




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

_______________________________________________
Idna-update mai= ling list
Idna-updat= e@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/= idna-update
=A0



___________= ____________________________________
Idna-update mailing list
Idna-update@alvestr= and.no
http://www.alvestrand.no/mailman/listinfo/idna-update


__________________________= _____________________
Idna-update mailing list
Idna-update@alvestrand.no
http://www.alv= estrand.no/mailman/listinfo/idna-update



=

--0016e6de010ffe9607046da58095-- From jmabdp@gmail.com Wed Jul 1 07:08: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 5CE1A28C522 for ; Wed, 1 Jul 2009 07:08:33 -0700 (PDT) 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 2rKZwY0ks1zV for ; Wed, 1 Jul 2009 07:08:31 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 2689828C562 for ; Wed, 1 Jul 2009 07:08:30 -0700 (PDT) Received: by ewy6 with SMTP id 6so1152519ewy.37 for ; Wed, 01 Jul 2009 07:07:51 -0700 (PDT) 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=V8qrdT2byFYMkt8sFDarFcBcAlGIGBb+swwXCTkl0fk=; b=ufoa/3kl+2d9p324X2+YCK3ddN9fibfrC4So8d2qqX+S3h/ojMMl5qJPmLsvKlUyzN EJuDMi4hTfbR/2AVdk+ztXDIlV74kcO6cNZelXZIiaerGKQzFZ+Nx/QJuljUfujYhTuT ZD7KJ52Ij8pk+ss+ZG8I8et+TYm4IbsRI3FdE= 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=dK2uVJHpSoM6sJRKDNkoLkmXjIGATQWdvWAojre8cdbUHwwFTd3OorfX2l0nrnzWnY 5ygEe5Xl5mY7QwkICpM1WYOUM51s8Q0uUjOaq7VFtjVluUzz20GbMigKPXqZcwFzRfTB 3L3mLjVsmXLFW7zKEyfGhW9erMu3WNjWzLwQM= MIME-Version: 1.0 Received: by 10.216.24.206 with SMTP id x56mr2853890wex.39.1246457271436; Wed, 01 Jul 2009 07:07:51 -0700 (PDT) In-Reply-To: <4E9B39D4-A191-4B56-803C-538E93A5D52E@google.com> References: <20090526011501.468193A6E44@core3.amsl.com> <30b660a20906282128u7bfffe9fma35c01f41cf7fe9f@mail.gmail.com> <0A2BDB123E910F2D087B6AF1@PST.JCK.COM> <4A49E907.4020808@it.aoyama.ac.jp> <6589127a0906301836r7a85037p5246a469dc256784@mail.gmail.com> <4A4AC3B6.2060800@abenaki.wabanaki.net> <6589127a0907010258y77acc9cev20d417a25603deea@mail.gmail.com> <3E9BF786-3800-43CE-9B5A-CC85C9F625E9@google.com> <6aad7a210907010544w1bcd9c71y2f9fed23157e98df@mail.gmail.com> <4E9B39D4-A191-4B56-803C-538E93A5D52E@google.com> Date: Wed, 1 Jul 2009 16:07:51 +0200 Message-ID: <6aad7a210907010707s363152e6ha2e67a84f941142a@mail.gmail.com> From: jean-michel bernier de portzamparc To: Vint Cerf Content-Type: multipart/alternative; boundary=0016e6db7c6ae44894046da57260 X-Mailman-Approved-At: Wed, 01 Jul 2009 07:35:47 -0700 Cc: Shawn Steele , Paul Hoffman , Eric Brunner-Williams , idna-update@alvestrand.no, internet users contributing group , =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= , Pete Resnick , John C Klensin , =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Subject: Re: [iucg] I-D Action:draft-ietf-idnabis-mappings-00.txt 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, 01 Jul 2009 14:08:33 -0000 --0016e6db7c6ae44894046da57260 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Mr. Cerf, I am afraid you have a total misreading of our position!!! Our "direction" works in test for years on and outside the Internet - anyon= e can develop it in Perl in a couple of hours. It is based upon a total neutrality of the Internet and of the DNS. What we oppose in what you consider is precisely that you disrpect the Charter and redesign the Internet and IDNA. You want to introduce at protocol level (i.e. within the Internet pile) new constraints that break the Internet technical neutrality in some cases. We do not really mind because these cases are very limited (at least for th= e time being, but we realise that your appraoch may lead to various attempt t= o control the Internet) However, in putting mapping at the Internet (controlled) level for things that will be important for some users, you create deployment issues and you make them lose interoperability with the rest of usage. We document the Internet the way it actually is, including IDNA, active content, presentation, DNS, etc.. This is because we need to be sure it can support the Intersem (semantic, semiotic, multiclultural, etc.) stratum we are interested in. This includes the use of the presentation and session control layer. Jean-Michel A. Bernier de Portzamparc 2009/7/1 Vint Cerf > Jean-michel, > I consider this discussion to be outside the scope of the working group. = In > my opinion, the IDNA architecture has already been decided, based on the > constraints of the DNS itself. The direction you and others associated wi= th > Jefsey want to pursue leads toward a re-design of DNS itself. I am not > arguing against a serious consideration of such a thing, only that I don'= t > consider it appropriate for the IDNABIS discussion. > > > vint > > > On Jul 1, 2009, at 8:44 AM, jean-michel bernier de portzamparc wrote: > > Dear Mr. Cerf, > may be could you set-up this mailing list yourself as part of the WG? The > reason why is that this is not a theorical but an architectural discussio= n. > As Elisabeth documents it, it will decide of the IDNA architecture. The > worst situation would be that a discussion list you called for as a Chair= , > would conflict with this WG. > > Best > Jean-Michel A. Bernier de Portzamparc > > Folks, >> this discussion is not going to get us closer to agreement on the >> remaining task: selection of the set of characters that should undergo s= ome >> kind of mapping prior to lookup in the DNS. >> >> Could I suggest that parties interested in this theoretical discussion >> move it to a private distribution list while the WG focuses on finalizin= g >> the mapping choices? >> >> thanks >> >> vint >> >> >> On Jul 1, 2009, at 5:58 AM, Elisabeth Blanconil wrote: >> >> I understand this. But I am refering to entropy as "a loss of >> information", as per Shannon and John. Now, I am not a mathematician her= e: I >> am a semantician. This because we precisely reach here (and this is the >> entire problem) the limits of mathematics. If we could quantify the entr= opy >> we could restore the initial information in restoring the corresponding >> negentropy. >> >> The problem we face is that mapping introduce a non quantifiable entropy= . >> We definitly enter mathematical chaos field through the entropic success= ion >> which chains possible semantic misunderstandings. >> >> Varela (knowledge), Thom (mathematics), Cullioli (linguistics), Morin >> (complex thinking), Von Bertalanffy (systems) etc. identify linguistics, >> semantics and pragmatics as the most complex knowlege field. Here we pla= y >> with hortotypography with an impact on semantic within different context= s. >> For those not familiar with chaos and catastrophy theories or complex >> thinking this is like the Lorentz's butterfly in Tokyo. You change a >> majuscule into a minuscule (French orthotypography) or an upper case int= o a >> lower case (English orthotypography) and you do not the global impact (i= t >> can be nill, most probably it will change the world, cf. Chaitin and co.= ). >> This is exactly the same as any other phishing: to make someone trust wh= at >> he should not. >> >> Elisabeth Blanconil >> >> 2009/7/1 Eric Brunner-Williams >> >>> Any phrasing is possible. Some mean less than others. One of my >>> co-workers was tempted to use "entropy" in a policy document recently. = I >>> prefer not to use the word unless the "entropy" asserted to exist can b= e >>> stated as a mathematical formula. If you could make that attempt, it wo= uld >>> be helpful. Users deserve statements that purport to "explain" which ar= e >>> factually correct. >>> >>> Eric >>> >>> Elisabeth Blanconil wrote: >>> >>>> 2009/6/30 "Martin J. D=FCrst" >>> duerst@it.aoyama.ac.jp>> >>>> >>>> >>>> A case mapping is also a 'loss of information', but one that >>>> people clearly want. >>>> >>>> >>>> Could we not phrase this differently ? Case mapping may be considered >>>> only if it does not represent a loss of information. Otherwise should = we not >>>> name it "case and entropy mapping" to explain users where entropy occu= rs. >>>> >>>> Elisabeth Blanconil >>>> >>>> >>>> >>>> >>>> >>>> ----------------------------------------------------------------------= -- >>>> >>>> _______________________________________________ >>>> 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 >> >> >> >> _______________________________________________ >> Idna-update mailing list >> Idna-update@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/idna-update >> >> > > --0016e6db7c6ae44894046da57260 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Mr. Cerf,
I am afraid you have a total misreading of our position!!= !

Our "direction" works in test for years on and outside t= he Internet - anyone can develop it in Perl in a couple of hours. It is bas= ed upon a total neutrality of the Internet and of the DNS. What we oppose i= n what you consider is precisely that you disrpect the Charter and=A0 redes= ign the Internet and IDNA. You want to introduce at protocol level (i.e. wi= thin the Internet pile) new constraints that break the Internet technical n= eutrality in some cases.

We do not really mind because these cases are very limited (at least fo= r the time being, but we realise that your appraoch may lead to various att= empt to control the Internet)=A0 However, in putting mapping at the Interne= t (controlled) level for things that will be important for some users, you = create deployment issues and you make them lose interoperability with the r= est of usage.

We document the Internet the way it actually is, including IDNA, active= content, presentation, DNS, etc.. This is because we need to be sure it ca= n support the Intersem (semantic, semiotic, multiclultural, etc.) stratum w= e are interested in. This includes the use of the presentation and session = control layer.

Jean-Michel A. Bernier de Portzamparc

2009/7/1 Vint Cerf <vint@google.com>
Jean-michel,

I consider this discussion = to be outside the scope of the working group. In my opinion, the IDNA archi= tecture has already been decided, based on the constraints of the DNS itsel= f. The direction you and others associated with Jefsey want to pursue leads= toward a re-design of DNS itself. I am not arguing against a serious consi= deration of such a thing, only that I don't consider it appropriate for= the IDNABIS discussion.


vint


On Jul= 1, 2009, at 8:44 AM, jean-michel bernier de portzamparc wrote:

Dear Mr. Cerf,
may be could you set-up this mailing list yourself as par= t of the WG? The reason why is that this is not a theorical but an architec= tural discussion. As Elisabeth documents it, it will decide of the IDNA arc= hitecture. The worst situation would be that a discussion list you called f= or as a Chair, would conflict with this WG.

Best
Jean-Michel A. Bernier de Portzamparc

F= olks,=A0

this discussion is not going to get us closer to agreement o= n the remaining task: selection of the set of characters that should underg= o some kind of mapping prior to lookup in the DNS.

Could I suggest that parties interested in this theoretical discussion= move it to a private distribution list while the WG focuses on finalizing = the mapping choices?

thanks

vint

On Jul 1, 2009, at 5:58 AM, Elisabeth Blanconil w= rote:

I understand this. But I am referi= ng to entropy as "a loss of information", as per Shannon and John= . Now, I am not a mathematician here: I am a semantician. This because we p= recisely reach here (and this is the entire problem) the limits of mathemat= ics. If we could quantify the entropy we could restore the initial informat= ion in restoring the corresponding negentropy.

The problem we face is that mapping introduce a non quantifiable entr= opy. We definitly enter mathematical chaos field through the entropic succe= ssion which chains possible semantic misunderstandings.

Varela (kno= wledge), Thom (mathematics), Cullioli (linguistics), Morin (complex thinkin= g), Von Bertalanffy (systems) etc. identify linguistics, semantics and prag= matics as the most complex knowlege field. Here we play with hortotypograph= y with an impact on semantic within different contexts. For those not famil= iar with chaos and catastrophy theories or complex thinking this is like th= e Lorentz's butterfly in Tokyo. You change a majuscule into a minuscule= (French orthotypography) or an upper case into a lower case (English ortho= typography) and you do not the global impact (it can be nill, most probably= it will change the world, cf. Chaitin and co.). This is exactly the same a= s any other phishing: to make someone trust what he should not.

Elisabeth Blanconil

2009/7/1 Eric B= runner-Williams <ebw@abenaki.wabanaki.net>
Any phrasing is possible. Some mean less than others. One of my co-worker= s was tempted to use "entropy" in a policy document recently. I p= refer not to use the word unless the "entropy" asserted to exist = can be stated as a mathematical formula. If you could make that attempt, it= would be helpful. Users deserve statements that purport to "explain&q= uot; which are factually correct.

Eric

Elisabeth Blanconil wrote:
2009/6/30 "Martin J. D=FCrst"= <duerst@it.= aoyama.ac.jp <mailto:duerst@it.aoyama.ac.jp>>


=A0 =A0A case mapping is also a 'loss of in= formation', but one that
=A0 =A0people clearly want.


= Could we not phrase this differently ? Case mapping may be considered only = if it does not represent a loss of information. Otherwise should we not nam= e it "case and entropy mapping" to explain users where entropy oc= curs.

Elisabeth Blanconil




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

_______________________________________________
Idna-update mai= ling list
Idna-updat= e@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/= idna-update
=A0



___________= ____________________________________
Idna-update mailing list
Idna-update@alvestr= and.no
http://www.alvestrand.no/mailman/listinfo/idna-update


__________________________= _____________________
Idna-update mailing list
Idna-update@alvestrand.no
http://www.alv= estrand.no/mailman/listinfo/idna-update



=
--0016e6db7c6ae44894046da57260-- From jefsey@jefsey.com Wed Jul 1 08:44: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 4F39B3A6B8C for ; Wed, 1 Jul 2009 08:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 ItrLdZwn-UQl for ; Wed, 1 Jul 2009 08:44:18 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 669D028C179 for ; Wed, 1 Jul 2009 08:44:13 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:2635 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MM0z2-0000MB-Od; Wed, 01 Jul 2009 07:40:25 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Jul 2009 16:39:48 +0200 To: Vint Cerf From: JFC Morfin In-Reply-To: <26C36789-306A-410D-B265-F26E0ED89A08@google.com> References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> <200907011222.n61CMrPx001109@smtp.google.com> <8FB03160-1D7F-4E73-8F6C-16093771E1AB@google.com> <200907011313.n61DDDVN002981@smtp.google.com> <26C36789-306A-410D-B265-F26E0ED89A08@google.com> 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: <20090701154413.669D028C179@core3.amsl.com> Cc: Andrew Sullivan , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 01 Jul 2009 15:44:19 -0000 At 15:15 01/07/2009, Vint Cerf wrote: >jefsey, then your issue is UNICODE and not IDNABIS. Work with them! >vint Vint, Why would I work with Unicode, about what ?? What is true about French is probably true about hundreds of other languages?? They are grown respected experts. They do for the best - up to them to tell what they do. If we wanted them to behave differently, we had to let them know before. Unicode is like the DNS, IDNA and the Internet. They are existing, deployed, stable solutions. Our opposition is to time wasting ill identified, slow to change, conflicting propositions. All what I need is that IDNABIS is published as it is today and that its texts are polished by the IETF/LC to make sure they respect the charter, the DNS, the IDNA principles and the Internet end to end process. Without any technological barrier to open trade. ----- Now, I suggest that IUCG and france@large members stop participating for at least a couple of hours. The target is not to fight other's positions, but to find the best way to facilitate the user's life. Again, we have a three step process which will take some time: 1) let me finish the IUCG Draft(s) I should have completed a mont ago. 2) let us structure the project.fra process 3) let get developped/integrated and tested a few working tools so everyone may better understand that we talk about nothing which is not here for years. Thanks to everyone. Non-IUCG/france@large comments welcome. jfc >On Jul 1, 2009, at 9:13 AM, jefsey wrote: > >>At 14:38 01/07/2009, Vint Cerf wrote: >>>Jefsey, maybe my email rendering code is broken but the string I am >>>seeing in your message looks like a purely ascii string making it a >>>conventional ascii domain name not requiring any special treatment. >> >>Vint, >>The string you see on your screen is ASCII - the string I enter is >>not. This is because Unicode is being used and Unicode does not >>properly supports the French language orthotypography. >> >>In "Ecole.fra" the semantics demands that "E" is not an "E" ASCII >>but a French "E" majuscule. I am sure Unicode has no problem in >>supporting them, or TLD Tables can be used. "Ecole.fra" is a user >>domain name which may have nothing to do (except phishing) with >>"école.fra", "ecole.fra" and "École.fra". >> >>This means there are wo problems: >> >>- they are to be able to resolve different IP addresses. >>- they also are to be able to resolve the same IP address. >> >>However, the decision is only with the registrant. So, the simplest >>is to consider each usage domain name separately. If some are to >>resolve the same IP, the registrant will only register several >>domain names. >> >>jfc >> >> >>>On Jul 1, 2009, at 8:19 AM, JFC Morfin wrote: >>> >>>>At 04:18 01/07/2009, Vint Cerf wrote: >>>>>jefsey, it cannot be an A-label since that is defined to include >>>>>"xn--" as a prefix. >>>> >>>>Dear Vint, >>>>This is the conflict we have and the resulting confusion. >>>> >>>>- usage considers what is enter in usage applications (from the >>>>entire Unicode set [actually it needs much more (ex.Natal from M$] >>>>_including_ ASCII) >>>>- I consider what the DNS is asked to resolve after an algorithm >>>>(including null and punycode ones) has been applied. >>>>- you consider complex U-/A-... labels which do not overlap. >>>>"Ecole.fra" is not supported by this label list. >>>> >>>>"Ecole.fra", >>>>1) it is a U-label >>>>2) but you do not want to support it as xn--cole-abc.fra. You keep >>>>it as an non punycoded yet A-label without "xn--" prefix. >>>>3) this confuses Andrew and John (who should not be concerned) >>>>because they try to understand how the DNS and Unicode casefolding >>>>could support the orthogonal User's casefolding (i.e. >>>>orthotypography). >>>> >>>>I see no other solution that to carry the mapping: >>>>- at the user application layer (outside of the Internet pile) and >>>>the Internet should remain transparent to "xn--" labels. >>>>- through a different presentation, and casefolding mapping etc. >>>>using "xs--" labels. >>>> >>>>Neither DNS nor Unicode casefolding are concerned. Only usage's side >>>>application (this is why the architecture is named IDNA): usage >>>>casefolding is to be decided and managed by the user through his >>>>application (if he wants to have it), depending on his own context, >>>>language, culture, job, kind of application, etc. and if the other >>>>end supports additional usage side features. This permits an >>>>application to application relation, where entropic actions (as >>>>required by the DNS resolution) can be restored through a >>>>negantropic process supported by metadata exchanges. As Elisabeth >>>>explained it. >>>> >>>>This being said, if you find a case (so far there is none) where a >>>>entropic mapping (casefolding or other) is universally accepted by >>>>users - or restored through a negentropic process such as what we >>>>call "duplex entities" -, supported by exvery encryption system, >>>>transparent to other technologies as well (netneutrality), etc. it >>>>could very well be investigated at protocol level (i.e within the >>>>Internet pile). Otherwise mapping can only be processed outside of >>>>the Internet pile. This is exactly the target and Charter of IDNA as >>>>I read and respect it. >>>> >>>>jfc >>>> >>>> >>>>>On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote: >>>>> >>>>>>At 17:12 30/06/2009, Andrew Sullivan wrote: >>>>>>>and, in particular, if we want to be sensitive to such upper and >>>>>>>lower case when the data comes back to us from the DNS resolver >>>>>>>level. >>>>>> >>>>>>Please, let not confuse : >>>>>> >>>>>>1) the DNS layer, where you run the game the way you want >>>>>>according >>>>>>to your published rules, and the Application Domain Names. >>>>>>2) French majuscules and upper cases. >>>>>> >>>>>>The U-label, A-label, etc. wording IMHO helps that confusion. Is >>>>>>Ecole.fra an U-label or an A-label? All I know is that it is an >>>>>>application domain name (like in "IDNA"). Also, that if the >>>>>>proposed >>>>>>text does not actually document the "ecole.fra, école.fra, >>>>>>Ecole.fra" case, this case will have to be documented during the >>>>>>IETF/LC. >>>>>> >>>>>>May be it is the best thing to do? so the whole IETF community may >>>>>>decide what does concern the whole community? >>>>>>jfc >>>>>> >>>>>>_______________________________________________ >>>>>>Idna-arabicscript mailing list >>>>>>Arabic Script IDN Working Group (ASIWG) >>>>>>Idna-arabicscript@lists.irnic.ir >>>>>>http://lists.irnic.ir/mailman/listinfo/idna-arabicscript From vint@google.com Wed Jul 1 08:52: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 D13213A68F4 for ; Wed, 1 Jul 2009 08:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 Kio-GFwhCS7F for ; Wed, 1 Jul 2009 08:52:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 2492A3A67AF for ; Wed, 1 Jul 2009 08:52:18 -0700 (PDT) Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id n61DFmdC008275 for ; Wed, 1 Jul 2009 06:15:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1246454148; bh=bDlcN05FZUzYXIN40byU8eGr2VQ=; h=DomainKey-Signature:From:To:In-Reply-To:Subject:References: Message-Id:Content-Type:Content-Transfer-Encoding:Mime-Version: Date:Cc:X-Mailer:X-System-Of-Record; b=tRSRSNfk1IdUeCxZib75frj5FyQ BOvK/a7f/m0YdjpXCXmyLHc7WIWSWN/2rgiFreMe6totq8e11NBNcOH2MzA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=from:to:in-reply-to:subject:references:message-id: content-type:content-transfer-encoding:mime-version:date:cc:x-mailer:x-system-of-record; b=uEvurHgxaO+83y9VR1f+I5fVhOuXS6Jg4DWpA67rET4RxN17o7/TxLCKTo58jEOf4 0Z8FL7j4AAfuO6c+Je/qg== Received: from rv-out-0506.google.com (rvbk40.prod.google.com [10.140.87.40]) by spaceape10.eur.corp.google.com with ESMTP id n61DFhDi032583 for ; Wed, 1 Jul 2009 06:15:44 -0700 Received: by rv-out-0506.google.com with SMTP id k40so295621rvb.27 for ; Wed, 01 Jul 2009 06:15:43 -0700 (PDT) Received: by 10.141.37.8 with SMTP id p8mr495738rvj.239.1246454142733; Wed, 01 Jul 2009 06:15:42 -0700 (PDT) Received: from 207-105-81-184.ded.pacbell.net ([207.105.81.184]) by mx.google.com with ESMTPS id k37sm5387805rvb.58.2009.07.01.06.15.39 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Jul 2009 06:15:40 -0700 (PDT) From: Vint Cerf To: jefsey In-Reply-To: <200907011313.n61DDDVN002981@smtp.google.com> References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> <200907011222.n61CMrPx001109@smtp.google.com> <8FB03160-1D7F-4E73-8F6C-16093771E1AB@google.com> <200907011313.n61DDDVN002981@smtp.google.com> Message-Id: <26C36789-306A-410D-B265-F26E0ED89A08@google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Jul 2009 09:15:37 -0400 X-Mailer: Apple Mail (2.930.3) X-System-Of-Record: true Cc: Andrew Sullivan , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 01 Jul 2009 15:52:19 -0000 jefsey, then your issue is UNICODE and not IDNABIS. Work with them! vint On Jul 1, 2009, at 9:13 AM, jefsey wrote: > At 14:38 01/07/2009, Vint Cerf wrote: >> Jefsey, maybe my email rendering code is broken but the string I am >> seeing in your message looks like a purely ascii string making it a >> conventional ascii domain name not requiring any special treatment. > > Vint, > The string you see on your screen is ASCII - the string I enter is =20 > not. This is because Unicode is being used and Unicode does not =20 > properly supports the French language orthotypography. > > In "Ecole.fra" the semantics demands that "E" is not an "E" ASCII =20 > but a French "E" majuscule. I am sure Unicode has no problem in =20 > supporting them, or TLD Tables can be used. "Ecole.fra" is a user =20 > domain name which may have nothing to do (except phishing) with =20 > "=E9cole.fra", "ecole.fra" and "=C9cole.fra". > > This means there are wo problems: > > - they are to be able to resolve different IP addresses. > - they also are to be able to resolve the same IP address. > > However, the decision is only with the registrant. So, the simplest =20= > is to consider each usage domain name separately. If some are to =20 > resolve the same IP, the registrant will only register several =20 > domain names. > > jfc > > >> On Jul 1, 2009, at 8:19 AM, JFC Morfin wrote: >> >>> At 04:18 01/07/2009, Vint Cerf wrote: >>>> jefsey, it cannot be an A-label since that is defined to include >>>> "xn--" as a prefix. >>> >>> Dear Vint, >>> This is the conflict we have and the resulting confusion. >>> >>> - usage considers what is enter in usage applications (from the >>> entire Unicode set [actually it needs much more (ex.Natal from M$] >>> _including_ ASCII) >>> - I consider what the DNS is asked to resolve after an algorithm >>> (including null and punycode ones) has been applied. >>> - you consider complex U-/A-... labels which do not overlap. >>> "Ecole.fra" is not supported by this label list. >>> >>> "Ecole.fra", >>> 1) it is a U-label >>> 2) but you do not want to support it as xn--cole-abc.fra. You keep >>> it as an non punycoded yet A-label without "xn--" prefix. >>> 3) this confuses Andrew and John (who should not be concerned) >>> because they try to understand how the DNS and Unicode casefolding >>> could support the orthogonal User's casefolding (i.e. >>> orthotypography). >>> >>> I see no other solution that to carry the mapping: >>> - at the user application layer (outside of the Internet pile) and >>> the Internet should remain transparent to "xn--" labels. >>> - through a different presentation, and casefolding mapping etc. >>> using "xs--" labels. >>> >>> Neither DNS nor Unicode casefolding are concerned. Only usage's side >>> application (this is why the architecture is named IDNA): usage >>> casefolding is to be decided and managed by the user through his >>> application (if he wants to have it), depending on his own context, >>> language, culture, job, kind of application, etc. and if the other >>> end supports additional usage side features. This permits an >>> application to application relation, where entropic actions (as >>> required by the DNS resolution) can be restored through a >>> negantropic process supported by metadata exchanges. As Elisabeth >>> explained it. >>> >>> This being said, if you find a case (so far there is none) where a >>> entropic mapping (casefolding or other) is universally accepted by >>> users - or restored through a negentropic process such as what we >>> call "duplex entities" -, supported by exvery encryption system, >>> transparent to other technologies as well (netneutrality), etc. it >>> could very well be investigated at protocol level (i.e within the >>> Internet pile). Otherwise mapping can only be processed outside of >>> the Internet pile. This is exactly the target and Charter of IDNA as >>> I read and respect it. >>> >>> jfc >>> >>> >>>> On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote: >>>> >>>>> At 17:12 30/06/2009, Andrew Sullivan wrote: >>>>>> and, in particular, if we want to be sensitive to such upper and >>>>>> lower case when the data comes back to us from the DNS resolver >>>>>> level. >>>>> >>>>> Please, let not confuse : >>>>> >>>>> 1) the DNS layer, where you run the game the way you want =20 >>>>> according >>>>> to your published rules, and the Application Domain Names. >>>>> 2) French majuscules and upper cases. >>>>> >>>>> The U-label, A-label, etc. wording IMHO helps that confusion. Is >>>>> Ecole.fra an U-label or an A-label? All I know is that it is an >>>>> application domain name (like in "IDNA"). Also, that if the =20 >>>>> proposed >>>>> text does not actually document the "ecole.fra, =E9cole.fra, >>>>> Ecole.fra" case, this case will have to be documented during the >>>>> IETF/LC. >>>>> >>>>> May be it is the best thing to do? so the whole IETF community may >>>>> decide what does concern the whole community? >>>>> jfc >>>>> >>>>> _______________________________________________ >>>>> Idna-arabicscript mailing list >>>>> Arabic Script IDN Working Group (ASIWG) >>>>> Idna-arabicscript@lists.irnic.ir >>>>> http://lists.irnic.ir/mailman/listinfo/idna-arabicscript > From ajs@shinkuro.com Wed Jul 1 07:56: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 A7A2528C527 for ; Wed, 1 Jul 2009 07:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, J_CHICKENPOX_53=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 d20YmKq4RIdh for ; Wed, 1 Jul 2009 07:56:48 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D4F7A28C520 for ; Wed, 1 Jul 2009 07:56:48 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 42F2C2FE9666; Wed, 1 Jul 2009 14:54:58 +0000 (UTC) Date: Wed, 1 Jul 2009 10:54:52 -0400 From: Andrew Sullivan To: JFC Morfin Message-ID: <20090701145449.GA4777@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Wed, 01 Jul 2009 10:07:12 -0700 Cc: iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] Punycode Mixed-case annotation 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, 01 Jul 2009 14:56:49 -0000 I don't think I'm a member of the lists you cc:d, so I expect this will get moderated. But. . . On Wed, Jul 01, 2009 at 02:42:01AM +0200, JFC Morfin wrote: > At 17:12 30/06/2009, Andrew Sullivan wrote: >> and, in particular, if we want to be sensitive to such upper and lower >> case when the data comes back to us from the DNS resolver level. > > Please, let not confuse : > > 1) the DNS layer, where you run the game the way you want according to > your published rules, and the Application Domain Names. > 2) French majuscules and upper cases. I am not confusing them. The fact is that they _are confused_ -- there's no way to distinguish "Ecole.fra" the (all ASCII) LDH labels and "Ecole.fra" the pair of putative labels that includes an (unaccented) upper-case "é". There simply _is not_ a way, technically, to disambiguate this even if we would like to do so: both are (in Unicode) LATIN CAPITAL LETTER E. If you want that fixed, go talk to the Unicode consortium and get them to change it. It would plainly reqire that two glyphs, which both look like "E", get different code points so that LATIN CAPITAL LETTER E would be different from UPPER-CASE LETTER E WITH INVISIBLE ACUTE (or whatever it got named) would actually be different characters. Whether such an addition to the Unicode code-space would be a good idea from the point of view of actual users is something entirely beyond my professional competence. I will say that I would be personally surprised to have two characters that always appear to be identical, but that do not match one another. Until there are different characters for upper-case e and upper-case é without the accent, there is no way to get école.fra and Ecole.fra to match one another, because Ecole.fra already matches ecole.fra. That's an old, long-standing limitation of the DNS, and since no IDNA proposal plans to interfere in the resolution path for plain ASCII characters (which Ecole.fra is, whether you like it or not), it's a limitation we're stuck with. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jefsey@jefsey.com Wed Jul 1 15:42:35 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 784213A6767 for ; Wed, 1 Jul 2009 15:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_53=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 POc5HvFmL+H0 for ; Wed, 1 Jul 2009 15:42:33 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id A72533A6973 for ; Wed, 1 Jul 2009 15:42:30 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:4266 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MM8Vt-0007Yg-KP; Wed, 01 Jul 2009 15:42:50 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 00:42:42 +0200 To: Andrew Sullivan From: JFC Morfin In-Reply-To: <20090701145449.GA4777@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> 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: <20090701224230.A72533A6973@core3.amsl.com> Cc: iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] Punycode Mixed-case annotation 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, 01 Jul 2009 22:42:35 -0000 > > Please, let not confuse : > > > > 1) the DNS layer, where you run the game the way you want according to > > your published rules, and the Application Domain Names. > > 2) French majuscules and upper cases. Dear Andrew, I suggest you give me a few days to finish my Interplus Draft which is delayed by my family obligations. >At 16:54 01/07/2009, Andrew Sullivan wrote: >I am not confusing them. The fact is that they _are confused_ -- We know and want the DNS does not confuse them: it takes them as identical. It MUST stay that way. This means that mapping at DNS (protocol) service layer MUST not be permitted. Mapping charfacters at the same service layer as the DNS is to build a new DNS. This is not permitted by the Charter (the IESG and IAB must be involved). Whatever the motivations. The DNS MUST _entirely_ stay outside of IDNA. >there's no way to distinguish "Ecole.fra" the (all ASCII) LDH labels >and "Ecole.fra" the pair of putative labels that includes an >(unaccented) upper-case "é". There simply _is not_ a way, >technically, Perefectly true. This is why I 100% supports the Chartef which says that disambiguation does _not_ belong to the network area. Mapping MUST be outside of the protocol. >to disambiguate this even if we would like to do so: both >are (in Unicode) LATIN CAPITAL LETTER E. If you want that fixed, go >talk to the Unicode consortium and get them to change it. It would >plainly reqire that two glyphs, which both look like "E", get >different code points so that LATIN CAPITAL LETTER E would be >different from UPPER-CASE LETTER E WITH INVISIBLE ACUTE (or whatever >it got named) would actually be different characters. This would be pragmatically foolish (irt. pragmatics as a discipline), orthotypographycally uncorrect, and semantically confusing. >Whether such an addition to the Unicode code-space would be a good >idea from the point of view of actual users is something entirely >beyond my professional competence. I will say that I would be >personally surprised to have two characters that always appear to be >identical, but that do not match one another. This is exactly what the current character mapping debate would lead to (interfering with "E", "e", "é", "è", "ë", "ê", Unicode, semantics, pragmatics, DNS, IDNA, etc.). IETF is only to document where mapping may occur, under which conditions, with which consequences. Or it may better not speak about it. Please also remember that my French example are only an easy exemple to type in ASCII of the consequence of the considered Internet / Usage strata violations. >Until there are different characters for upper-case e and upper-case ýA9 >without the accent, there is no way to get école.fra and Ecole.fra to >match one another, Who is asking for that? >because Ecole.fra already matches ecole.fra. Who says that? Please do not confuse user domain names and DNS domain names. It take one minute to contradict you in using Host.txt. >That's an old, long-standing limitation of the DNS, Who is here talking of DNS? Only mapping at protocol layer supporters are. And mapping at protocol layer is forbiden by the charter. Mapping at protocol layer propagates the DNS "e to E to e" DNS _feature_ as an IDNA _rigidity_ (at user level). >and since no IDNA >proposal plans to interfere in the resolution path for plain ASCII >characters (which Ecole.fra is, whether you like it or not), it's a >limitation we're stuck with. "IDNA" is a BCP suggesting a proven forrmalization of the way one can use the Internet presentation layer. Because the IETF is to " influence the way people design, use, and manage the Internet in such a way as to make the Internet work better" (RFC 3935). However, it should "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." Mapping at protocol level is network centric IETF centralised control, mapping at user application is "edge-user empowerment". "These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create". (Same RFC) Some may push towards different concepts. I disagree. Moreover than: - it is a major strata violation (network vs. user) - the Internet alternative is in operation for decades (in various embryonic manners - I accept this - but very deep in the Internet architecture and culture) and nothing can prevent it to be applied. However, the risk is that it may scale in a non coordinated ways (example: the indecision of ICANN about IDNcc/gTLD policy in the IN class). jfc From ajs@shinkuro.com Wed Jul 1 15:47: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 37BD93A6ABC for ; Wed, 1 Jul 2009 15:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.542, 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 57xtiZ+bkPND for ; Wed, 1 Jul 2009 15:47:28 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6F92A3A6884 for ; Wed, 1 Jul 2009 15:47:28 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 975CB2FE9666; Wed, 1 Jul 2009 22:47:49 +0000 (UTC) Date: Wed, 1 Jul 2009 18:47:47 -0400 From: Andrew Sullivan To: JFC Morfin Message-ID: <20090701224747.GA6292@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] Punycode Mixed-case annotation 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, 01 Jul 2009 22:47:29 -0000 On Thu, Jul 02, 2009 at 12:42:42AM +0200, JFC Morfin wrote: > We know and want the DNS does not confuse them: it takes them as identical. They are in fact identical code points. User intention, which is inscrutable, is not relevant here. > It MUST stay that way. This means that mapping at DNS (protocol) service > layer MUST not be permitted. Mapping charfacters at the same service > layer as the DNS is to build a new DNS. This is not permitted by the > Charter (the IESG and IAB must be involved). Whatever the motivations. Nobody was suggesting they get mapped in the DNS. The question is whether they get mapped before the DNS, which is IDNA, and I am merely pointing out that you can't do that because one of the rules was "no change to DNS". Since the plan is to put IDNA in between an application and the DNS, you can't have behaviour in IDNA that is contrary to the traditional rules of DNS; one of those rules is that E and e match, and that neither of them matches anything else. > Who says that? Please do not confuse user domain names and DNS domain > names. It take one minute to contradict you in using Host.txt. Clearly, if you enter stray data into the system, you can get a different result. That's nowise a premise in favour of your view. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jefsey@jefsey.com Thu Jul 2 03:00:32 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 0D7163A6A7F for ; Thu, 2 Jul 2009 03:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 pWS8Ruc3ODMT for ; Thu, 2 Jul 2009 03:00:31 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 205093A6894 for ; Thu, 2 Jul 2009 03:00:31 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:2463 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MMJ61-0002IT-6p; Thu, 02 Jul 2009 03:00:49 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 12:00:46 +0200 To: Andrew Sullivan From: JFC Morfin In-Reply-To: <20090701224747.GA6292@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@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: <20090702100031.205093A6894@core3.amsl.com> Cc: iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] Punycode Mixed-case annotation 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, 02 Jul 2009 10:00:32 -0000 At 00:47 02/07/2009, Andrew Sullivan wrote: > > Who says that? Please do not confuse user domain names and DNS domain > > names. It take one minute to contradict you in using Host.txt. > >Clearly, if you enter stray data into the system, you can get a >different result. That's nowise a premise in favour of your view. The point is what what do you mean by "stray" and by "system". I feel you do not make a difference between what the user enter in the application and what the DNS receives as a querry. Pete has very well documented this point in his Draft. We are considering two systems. - one is the Internet and its ASCII DNS. The charter says they should stay unchanged. IMHO this is an architectural MUST. - the other is the Internationalized Internet which is made of the Internet plus IDNA. The purpose is to permit to use Chinese, French, Arabic, English domain names (IDNs) in the Internationalized Internet, however they are stray data in the DNS. To map anything at: - protocol level, i.e. at the same layer as the DNS, is to build a new DNS. - IDNA level, i.e. above the DNS Internet application layer, is transparent to the DNS and does not build a new DNS. This is the whole IDNA idea. There are therefore two layer violations under discussion: 1. to map at protocol layer. We roughly agree, however my architectural motives seem to be stricter than your DNS requirements. 2. to only consider the ASCII Unicode sub-part as a special part: this is the linguistic English "bias" of English internationalization. We consider that _every_ Unicode sub-part (down to code point level) is potentially a special part, while Vint only want to cristalize a few of them in the technology itself. This means that our conceptual premises are equivalent, so please let drop disputes on that matter. We only differ in terms of mapping flexibility (who decides, for how long) and extension (which code points and contexts); also we commonly explore mapping location (prior, after or within the punycode algorithm) and should consider architectural coherence and stability (how to document the whole thing in order to influence a better stability). I understand there are two main positions: - to protect the internet from linguistic originated technical overload through very limited changes, even if this does not fulfill the users expectations. The people supporting this position consider linguistic and Unicode details. They also want to use constraints as protection of technical status quo. - to protect the internet from any technical change, because users expectations are much more extended than linguistic needs and are common to every digital technology: they must therefore be treated between the user and the Internet - what is named IDNA in here, and we more generally name Interplus. The people supporting this position are only interested in presentation layer issues, whatever the presentation details. They want no constraints on the Internet considering that the overload will more likely result from the constraint mechanism and and of its impact on the global network equilbrium. IMHO, whatever the good reasons the first coalition may propose, they will most probably be disregarded by users as unnecessary constraints happening to support commercial and political status-quo. My concern, if there is no general IETF and ICANN consensus, at least for Class IN, a wild IDN usage will deploy. jfc From ajs@shinkuro.com Thu Jul 2 04:05: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 198953A6D81 for ; Thu, 2 Jul 2009 04:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.530, 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 4EDVjWsd++0m for ; Thu, 2 Jul 2009 04:05:03 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 32D9F3A6D7B for ; Thu, 2 Jul 2009 04:05:03 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B42CE2FE9666; Thu, 2 Jul 2009 11:05:24 +0000 (UTC) Date: Thu, 2 Jul 2009 07:05:23 -0400 From: Andrew Sullivan To: JFC Morfin Message-ID: <20090702110522.GC6393@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] Punycode Mixed-case annotation 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, 02 Jul 2009 11:05:04 -0000 On Thu, Jul 02, 2009 at 12:00:46PM +0200, JFC Morfin wrote: > The point is what what do you mean by "stray" and by "system". Yes. > I feel you do not make a difference between what the user enter in the > application and what the DNS receives as a querry. No. But there's a subtle and important relationship. IDNA-oblivious applications pass along whatever is typed in to the DNS. This means that entries like é fail completely, but both E and e succeed. Therefore, a constraint on any IDNA protocol for dealing with internationalized names MUST deal with the cases that always were successfully passed along the same way. The upshot of this is that the ASCII e and E have to be treated as the same character. Therefore, until the E that corresponds to e and the E that corresponds to é are different code points (which might never happen), there's no way to get Ecole to correspond to école unless école and ecole correspond to one another. Which was the original question, you may recall. > To map anything at: > - protocol level, i.e. at the same layer as the DNS, is to build a new DNS. Yes. > - IDNA level, i.e. above the DNS Internet application layer, is > transparent to the DNS and does not build a new DNS. This is the whole > IDNA idea. Yes, but see above. > 2. to only consider the ASCII Unicode sub-part as a special part: this is > the linguistic English "bias" of English internationalization. We > consider that _every_ Unicode sub-part (down to code point level) is > potentially a special part, while Vint only want to cristalize a few of > them in the technology itself. I get the objection, but I don't think we can violate the rule that how ASCII was ever processed will have to be how it will be processed in future. If we truly want to break that, I think it's time to get to work on DNS2. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From eblanconil@gmail.com Thu Jul 2 04:15: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 F14E728C22C for ; Thu, 2 Jul 2009 04:15:51 -0700 (PDT) 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 wExjsIn2KvTX for ; Thu, 2 Jul 2009 04:15:50 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id D729F28C22E for ; Thu, 2 Jul 2009 04:15:49 -0700 (PDT) Received: by fxm18 with SMTP id 18so1290452fxm.43 for ; Thu, 02 Jul 2009 04:16:06 -0700 (PDT) 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=d1WoDJUdF0l8S88fOKblKzBd46IbcEWWGbKiO55gUPA=; b=wqMxqM+uvHDP0Gc4f7sQMdpqAOcxK+UJzexTXqBc/uTmLbO0EodkkIsAOo9GLVbjDe L1BPAAEAq5gghCn48RY8F32rO62jnC5GuUXKz7ihNBmbmTL7dPtoSxAMd1XQZCV5L8ky 0A+ivx1Oh6a0cuf0xQKCyFpleYU2yuHPxq9X0= 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=g0R0OBNnoPSfyz9JB/SdaZH/d651biso2sfkpUGZzRryZORtG5RdPcgedm2U6lWzzS bhwllWuUVhwN78XWy028b3UbQw56Lqfx4OYJo0d+nME6I799NEsR3PsU+XlYiu0NLWmE /HvyDeqNl2IgaWwxL2aTA9N8ShpcizGrCwdhk= MIME-Version: 1.0 Received: by 10.86.57.2 with SMTP id f2mr52184fga.34.1246533366514; Thu, 02 Jul 2009 04:16:06 -0700 (PDT) In-Reply-To: <20090702100031.205093A6894@core3.amsl.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <20090702100031.205093A6894@core3.amsl.com> Date: Thu, 2 Jul 2009 13:16:06 +0200 Message-ID: <6589127a0907020416n108876b7y8d8db0d0c41b788a@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: multipart/alternative; boundary=000e0cd244de8304d5046db72ad9 Cc: Andrew Sullivan , Arabic Scripts IDNA Subject: Re: [iucg] Punycode Mixed-case annotation 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, 02 Jul 2009 11:15:52 -0000 --000e0cd244de8304d5046db72ad9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey, je d=E9jeune et je lis ton mail. Quelques petits points. I will comment the= m in English for Andrew and the ASIWG. 2009/7/2 JFC Morfin > At 00:47 02/07/2009, Andrew Sullivan wrote: > >> > Who says that? Please do not confuse user domain names and DNS domain >> > names. It take one minute to contradict you in using Host.txt. >> >> Clearly, if you enter stray data into the system, you can get a >> different result. That's nowise a premise in favour of your view. >> > > The point is what do you mean by "stray" and by "system". > > I feel you do not make a difference between what the user enters in the > application and what the DNS receives as a querry. Pete has very well > documented this point in his Draft. We are considering two systems. > - one is the Internet and its ASCII DNS. The charter says they should sta= y > unchanged. IMHO this is an architectural MUST. > - the other is the Internationalized Internet which is made of the Intern= et > plus IDNA. The purpose is to permit to use Chinese, French, Arabic, Engli= sh > domain names (IDNs) in the Internationalized Internet, however they are > stray data in the DNS. IMHO if you want IDNA people to understand things clearly, they need to understand here that we consider four: Core System =3D the unchanged Internet four layers pile. With the DNS in th= e service layer. IDNA System =3D currently still undefined internationalization ability addition to the core internet system for the user to be able (to some extent) to enter Chinese, French, Arabic, etc. names. Interplus System =3D the coherent extension of the Internet layers pile to fully support the usage system requirements, including full multilingual an= d semiotic names (as documented by Pete). Usage system =3D the system being used by the edge-user. To map anything at: > - protocol level, i.e. at the same layer as the DNS, is to build a new DN= S. > - IDNA level, i.e. above the DNS Internet application layer, is transpare= nt > to the DNS and does not build a new DNS. This is the whole IDNA idea. > > There are therefore two layer violations under discussion: > 1. to map at protocol layer. We roughly agree, however my architectural > motives seem to be stricter than your DNS requirements. You mean you agree together that you disagree about mapping at protocol layer. > > 2. to only consider the ASCII Unicode sub-part as a special part: this is > the linguistic English "bias" of English internationalization. We conside= r > that _every_ Unicode sub-part (down to code point level) is potentially a > special part, while Vint only want to cristalize a few of them in the > technology itself. We consider it for two main reasons: - because idiolect orthotypography has to be semantically consistent with the other forms of human naming (polynymy) - because (RFC 1958) similar problems should receive similar solutions and as I noted it yesterday, multilingual presentation support is just a paradigm for many other similar needs. The resolution of these needs should not depend on tricks to accommodate IDNA to Unicode specifics. > This means that our conceptual premises are equivalent, so please let dro= p > disputes on that matter. We only differ in terms of mapping flexibility (= who > decides, for how long) and extension (which code points and contexts); al= so > we commonly explore mapping location (prior, after or within the punycode > algorithm) and should consider architectural coherence and stability (how= to > document the whole thing in order to influence a better stability). This grid is very important. No mapping discussion can be complete if these topics are not discussed. - authority (structural, namespace, host, user) - duration (permanent, parametrised, option) - scope (per scripts, language, application, culture, usage, style, etc.) - contexts (semantic, pragmatic, semiotic, orthotypographies) - before, within, after punycode - architectural coherence with other usages of the resources being documented, neutrality for cross technology support. - technical, operational, economic, strategic and usage stability. I understand there are two main positions: > > - to protect the internet from linguistic originated technical overload > through very limited changes, even if this does not fulfill the users > expectations. The people supporting this position consider linguistic and > Unicode details. They also want to use constraints limitations > as protections of technical status quo. Mostly they consider the Internet as a single system of which they know the limitations, while we consider it as a flexible much more resilient concatenated distributed system. They focus on traffic and transport. We focus on semantic and facilitation. We need to keep that in mind. On both sides. Elsiabeth Blanconil --000e0cd244de8304d5046db72ad9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey,
je d=E9jeune et je lis ton mail. Quelques petits points. I will = comment them in English for Andrew and the ASIWG.

2009/7/2 JFC Morfin <jefsey@jefsey.com>
At 00:47 02/07/2009, Andrew Sullivan wrote:
> Who says that? Please do not confuse user domain names and DNS domain<= br> > names. It take one minute to contradict you in using Host.txt.

Clearly, if you enter stray data into the system, you can get a
different result. =A0That's nowise a premise in favour of your view.

The point is what do you mean by "stray" and by "system"= ;.

I feel you do not make a difference between what the user enters in the app= lication and what the DNS receives as a querry. Pete has very well document= ed this point in his Draft. We are considering two systems.
- one is the Internet and its ASCII DNS. The charter says they should stay = unchanged. IMHO this is an architectural MUST.
- the other is the Internationalized Internet which is made of the Internet= plus IDNA. The purpose is to permit to use Chinese, French, Arabic, Englis= h domain names (IDNs) in the Internationalized Internet, however they are s= tray data in the DNS.

IMHO if you want IDNA people to understand things clearly, they ne= ed to understand here that we consider four:

Core System =3D the unc= hanged Internet four layers pile. With the DNS in the service layer.
IDN= A System =3D currently still undefined internationalization ability additio= n to the core internet system for the user to be able (to some extent) to e= nter Chinese, French, Arabic, etc. names.
Interplus System =3D the coherent extension of the Internet layers pile to = fully support the usage system requirements, including full multilingual an= d semiotic names (as documented by Pete).
Usage system =3D the system be= ing used by the edge-user.

To map anything at:
- protocol level, i.e. at the same layer as the DNS, is to build a new DNS.=
- IDNA level, i.e. above the DNS Internet application layer, is transparent= to the DNS and does not build a new DNS. This is the whole IDNA idea.

There are therefore two layer violations under discussion:
1. to map at protocol layer. We roughly agree, however my architectural mot= ives seem to be stricter than your DNS requirements.

Y= ou mean you agree together that you disagree about mapping at protocol laye= r.

2. to only consider the ASCII Unicode sub-part as a special part: this is t= he linguistic English "bias" of English internationalization. We = consider that _every_ Unicode sub-part (down to code point level) is potent= ially a special part, while Vint only want to cristalize a few of them in t= he technology itself.

We consider it for two main reasons:
- because idiolect orthoty= pography has to be semantically consistent with the other forms of human na= ming (polynymy)
- because (RFC 1958) similar problems should receive sim= ilar solutions and as I noted it yesterday, multilingual presentation suppo= rt is just a paradigm for many other similar needs. The resolution of these= needs should not depend on tricks to accommodate IDNA to Unicode specifics= .


This means that our conceptual premises are equivalent, so please let drop = disputes on that matter. We only differ in terms of mapping flexibility (wh= o decides, for how long) and extension (which code points and contexts); al= so we commonly explore mapping location (prior, after or within the punycod= e algorithm) and should consider architectural coherence and stability (how= to document the whole thing in order to influence a better stability).

This grid is very important. No mapping discussion can be complete= if these topics are not discussed.

- authority (structural, namespa= ce, host, user)
- duration (permanent, parametrised, option)
- scope= (per scripts, language, application, culture, usage, style, etc.)
- contexts (semantic, pragmatic, semiotic, orthotypographies)
- before, = within, after punycode
- architectural coherence with other usages of th= e resources being documented, neutrality for cross technology support.
- technical, operational, economic, strategic and usage stability.

<= /div>
I understand there are two main positions:

- to protect the internet from linguistic originated technical overload thr= ough very limited changes, even if this does not fulfill the users expectat= ions. The people supporting this position consider linguistic and Unicode d= etails. They also want to use constraints

limitations
=A0
as protections of technical status quo.

Mostly they consider the Internet as a single system of which they know= the limitations, while we consider it as a flexible much more resilient co= ncatenated distributed system. They focus on traffic and transport. We focu= s on semantic and facilitation.

We need to keep that in mind. On both sides.

Elsiabeth Blanconil=

--000e0cd244de8304d5046db72ad9-- From eblanconil@gmail.com Thu Jul 2 04:28:13 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 4E6333A683A for ; Thu, 2 Jul 2009 04:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 OH61DFw+fcWA for ; Thu, 2 Jul 2009 04:28:12 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 1561A3A6816 for ; Thu, 2 Jul 2009 04:28:11 -0700 (PDT) Received: by fxm18 with SMTP id 18so1414497fxm.37 for ; Thu, 02 Jul 2009 04:28:24 -0700 (PDT) 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=8xToZtSeUn9D39YwBgHhgSsydUvlpcHIu1zEpWwpwCI=; b=PoUwQFMedtv8DxIHmm19wbxzbEy3+vuN17CRRmzxB2LoSLAHSf6DsZlMGRGXtq4UzO rCrDmPhF47QwyId/bp0Tv1Zd5ovTXMGAyM8Kft2copFtZougWQBQN4KC3ztAnN71vlLx OWmyjlX+FzOMv2dp2MsayZ1Kw9WvRs4u2Y2XI= 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=tkE6RuawuDsEvDf8Isg7Ajj05CJaXQLM65tPQUfIIGl+5gu0EgcGMic46ScStAwxAV r13KRwbnimeXxKZNyZMBaRqflqTtmOT1Na8ymT12D3Xo7+iAK3eN8R33Z+N/CbnGstkv RoNgobNhDOHlbYbIpxC4n1zHXyJrzsJ05D7qI= MIME-Version: 1.0 Received: by 10.86.90.8 with SMTP id n8mr43497fgb.59.1246534103728; Thu, 02 Jul 2009 04:28:23 -0700 (PDT) In-Reply-To: <20090702110522.GC6393@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <20090702110522.GC6393@shinkuro.com> Date: Thu, 2 Jul 2009 13:28:23 +0200 Message-ID: <6589127a0907020428s44e5449fye6e8452b2da2ba95@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: multipart/alternative; boundary=000e0cd2506e7406bd046db756da Cc: Arabic Scripts IDNA Subject: Re: [iucg] Punycode Mixed-case annotation 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, 02 Jul 2009 11:28:13 -0000 --000e0cd2506e7406bd046db756da Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great !!! You and Jefsey agree !. I have finished my lunch time and I must go. I will leave JFC explain the project.fra answer to the very good point you make. Elisabeth Blanconil. 2009/7/2 Andrew Sullivan > > I feel you do not make a difference between what the user enter in the > > application and what the DNS receives as a querry. > > No. But there's a subtle and important relationship. > > IDNA-oblivious applications pass along whatever is typed in to the > DNS. This means that entries like =E9 fail completely, but both E and e > succeed. > > Therefore, a constraint on any IDNA protocol for dealing with > internationalized names MUST deal with the cases that always were > successfully passed along the same way. The upshot of this is that > the ASCII e and E have to be treated as the same character. > Therefore, until the E that corresponds to e and the E that > corresponds to =E9 are different code points (which might never happen), > there's no way to get Ecole to correspond to =E9cole unless =E9cole and > ecole correspond to one another. Which was the original question, you > may recall. > > --000e0cd2506e7406bd046db756da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great !!!
You and Jefsey agree !. I have finished my lunch time and I mu= st go. I will leave JFC explain the project.fra answer to the very good poi= nt you make.

Elisabeth Blanconil.


2009/7/2 Andrew Sullivan <ajs@shinkuro.com>
> I feel you do not make a difference between what the user enter in the=
> application and what the DNS receives as a querry.

No. =A0But there's a subtle and important relationship.

IDNA-oblivious applications pass along whatever is typed in to the
DNS. =A0This means that entries like =E9 fail completely, but both E and e<= br> succeed.

Therefore, a constraint on any IDNA protocol for dealing with
internationalized names MUST deal with the cases that always were
successfully passed along the same way. =A0The upshot of this is that
the ASCII e and E have to be treated as the same character.

Therefore, until the E that corresponds to e and the E that
corresponds to =E9 are different code points (which might never happen), there's no way to get Ecole to correspond to =E9cole unless =E9cole and=
ecole correspond to one another. =A0Which was the original question, you may recall.


--000e0cd2506e7406bd046db756da-- From vint@google.com Thu Jul 2 04:32: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 484673A6944 for ; Thu, 2 Jul 2009 04:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 4E7CdQydcWVK for ; Thu, 2 Jul 2009 04:32:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 3E8FC3A67AF for ; Thu, 2 Jul 2009 04:32:27 -0700 (PDT) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id n62BWm90026247 for ; Thu, 2 Jul 2009 12:32:48 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1246534368; bh=U7T2CaZ0DMOzRG0uX/+WjC1zxT8=; h=DomainKey-Signature: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=aa6p3VaH8IG/sAKgEcusetwn z/GUaBQbPGwbZNW89OUT4lfAIPiAYTIWlY5P8efIb7dQ9hK9hopC9jpd50+8ow== 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=wRLF7CMJEkI8fpRqmPNjFYXiaH8gJZxLYyGz1fCRo/d9uB235FnwG367XIggCn0j8 xg/J0C2Q545W+QbzFCnuw== Received: from wf-out-1314.google.com (wff28.prod.google.com [10.142.6.28]) by spaceape11.eur.corp.google.com with ESMTP id n62BW7kC005537 for ; Thu, 2 Jul 2009 04:32:45 -0700 Received: by wf-out-1314.google.com with SMTP id 28so586295wff.17 for ; Thu, 02 Jul 2009 04:32:44 -0700 (PDT) Received: by 10.142.84.5 with SMTP id h5mr1424579wfb.291.1246534362735; Thu, 02 Jul 2009 04:32:42 -0700 (PDT) Received: from 207-105-81-221.ded.pacbell.net ([207.105.81.221]) by mx.google.com with ESMTPS id 20sm7134501wfi.20.2009.07.02.04.32.39 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Jul 2009 04:32:40 -0700 (PDT) Message-Id: <7EA5A735-BCFC-410E-8AA7-43950C313036@google.com> From: Vint Cerf To: JFC Morfin In-Reply-To: <200907021000.n62A0qEO032564@ns1.irnic.ir> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Jul 2009 07:32:37 -0400 References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <200907021000.n62A0qEO032564@ns1.irnic.ir> X-Mailer: Apple Mail (2.930.3) X-System-Of-Record: true Cc: Andrew Sullivan , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 02 Jul 2009 11:32:30 -0000 jefsey, thanks for taking the trouble to prepare this note. It does lay out the issues clearly. I think I can report agreement with you in several areas. First, while the IDNA working group members may not yet have reach consensus, there is at least among them, some who would treat the mapping on look up as a "should" (for compatibility reasons) but not a MUST and distinguish between the basic IDN protocol that preserves the A-label/U-label definitions and 1:1 conversion feature as part of protocol, and the pre-processing of strings that may be destined for lookup in the DNS. Some of the potential preprocessing is not specified in any of the documents except to say that by the time a look up occurs, it must be in A-label form (including the "xn--") or must be a "traditional" ASCII form ("LDH"). One form of preprocessing, about which we continue to debate, is to map some of the characters of the eventual "lookup" string so as to reduce variance from expectations that arise from the IDNA2003 behaviors. The DNS itself continues to have the purely ASCII behavior it has always had to avoid requiring changes on the domain name server side. Second, I think there is considerable room for innovation and standardization at a conceptual "presentation" layer - such a layer was not defined in the Internet while some effort to define on was in the OSI system. As applications have become increasingly internationalized, it is arguable that codifying presentation concepts may prove useful. Some might go so far as to suggest re-inventing the system of binding strings to internet addresses (what the DNS does). While that path was not chosen in the present DNS-IDNA2003-IDNA2008 sequence, it might be considered in the future and in my opinion, it is in these areas (presentation and re-definition) that much of your work, jefsey, has relevance. I am interpreting your message here as arguing not to change the existing basic DNS, to confer stability at the server level, and here we agree. vint On Jul 2, 2009, at 6:00 AM, JFC Morfin wrote: > At 00:47 02/07/2009, Andrew Sullivan wrote: >> > Who says that? Please do not confuse user domain names and DNS >> domain >> > names. It take one minute to contradict you in using Host.txt. >> >> Clearly, if you enter stray data into the system, you can get a >> different result. That's nowise a premise in favour of your view. > > The point is what what do you mean by "stray" and by "system". > > I feel you do not make a difference between what the user enter in > the application and what the DNS receives as a querry. Pete has very > well documented this point in his Draft. We are considering two > systems. > - one is the Internet and its ASCII DNS. The charter says they > should stay unchanged. IMHO this is an architectural MUST. > - the other is the Internationalized Internet which is made of the > Internet plus IDNA. The purpose is to permit to use Chinese, French, > Arabic, English domain names (IDNs) in the Internationalized > Internet, however they are stray data in the DNS. > > To map anything at: > - protocol level, i.e. at the same layer as the DNS, is to build a > new DNS. > - IDNA level, i.e. above the DNS Internet application layer, is > transparent to the DNS and does not build a new DNS. This is the > whole IDNA idea. > > There are therefore two layer violations under discussion: > 1. to map at protocol layer. We roughly agree, however my > architectural motives seem to be stricter than your DNS requirements. > 2. to only consider the ASCII Unicode sub-part as a special part: > this is the linguistic English "bias" of English > internationalization. We consider that _every_ Unicode sub-part > (down to code point level) is potentially a special part, while Vint > only want to cristalize a few of them in the technology itself. > > This means that our conceptual premises are equivalent, so please > let drop disputes on that matter. We only differ in terms of mapping > flexibility (who decides, for how long) and extension (which code > points and contexts); also we commonly explore mapping location > (prior, after or within the punycode algorithm) and should consider > architectural coherence and stability (how to document the whole > thing in order to influence a better stability). > > I understand there are two main positions: > > - to protect the internet from linguistic originated technical > overload through very limited changes, even if this does not fulfill > the users expectations. The people supporting this position consider > linguistic and Unicode details. They also want to use constraints as > protection of technical status quo. > > - to protect the internet from any technical change, because users > expectations are much more extended than linguistic needs and are > common to every digital technology: they must therefore be treated > between the user and the Internet - what is named IDNA in here, and > we more generally name Interplus. The people supporting this > position are only interested in presentation layer issues, whatever > the presentation details. They want no constraints on the Internet > considering that the overload will more likely result from the > constraint mechanism and and of its impact on the global network > equilbrium. > > IMHO, whatever the good reasons the first coalition may propose, > they will most probably be disregarded by users as unnecessary > constraints happening to support commercial and political status- > quo. My concern, if there is no general IETF and ICANN consensus, at > least for Class IN, a wild IDN usage will deploy. > > jfc > > > > _______________________________________________ > Idna-arabicscript mailing list > Arabic Script IDN Working Group (ASIWG) > Idna-arabicscript@lists.irnic.ir > http://lists.irnic.ir/mailman/listinfo/idna-arabicscript From jefsey@jefsey.com Thu Jul 2 09:41: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 307B63A6938 for ; Thu, 2 Jul 2009 09:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.271, 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 KL2KdkG7TFGK for ; Thu, 2 Jul 2009 09:41:30 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 5DE7C3A68A5 for ; Thu, 2 Jul 2009 09:41:30 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:4346 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MMPLq-0000Jc-14; Thu, 02 Jul 2009 09:41:34 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 18:41:32 +0200 To: Andrew Sullivan From: jefsey In-Reply-To: <20090702110522.GC6393@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <20090702110522.GC6393@shinkuro.com> 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: <20090702164130.5DE7C3A68A5@core3.amsl.com> Cc: iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] Punycode Mixed-case annotation 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, 02 Jul 2009 16:41:31 -0000 At 13:05 02/07/2009, Andrew Sullivan wrote: > > I feel you do not make a difference between what the user enter in the > > application and what the DNS receives as a querry. > >No. But there's a subtle and important relationship. > >IDNA-oblivious applications pass along whatever is typed in to the >DNS. This means that entries like é fail completely, but both E and e >succeed. > >Therefore, a constraint on any IDNA protocol for dealing with >internationalized names MUST deal with the cases that always were >successfully passed along the same way. The upshot of this is that >the ASCII e and E have to be treated as the same character. >Therefore, until the E that corresponds to e and the E that >corresponds to é are different code points (which might never happen), >there's no way to get Ecole to correspond to école unless école and >ecole correspond to one another. Which was the original question, you >may recall. Correct. However, please remember that we are talking of linguistic TLDs (this is why I first initiated Multilinc and want to run the project.fra test-bed). This mean that I can manage the TLD registry the way I want. 1. I can put a TTY 0 (which corresponds to Web 2.0 anyway), so the ecole/Ecole data are not cached. 2. unless you change the DNS for security reasons (scrambling the lower/upper cases) "ecole" and "Ecole" will be passed as such to the DNS, even they both are treated as "ecole". So I will filter out "Ecole" which is meaningless to me (I need to receive xn--cole-abc.fra). I have the right to do that because I do not change the DNS at all, only put an OPES on the DNS. I tried to push the WG/OPES to work on the DNS protocol before SMTP. This might have helped. > > 2. to only consider the ASCII Unicode sub-part as a special part: this is > > the linguistic English "bias" of English internationalization. We > > consider that _every_ Unicode sub-part (down to code point level) is > > potentially a special part, while Vint only want to cristalize a few of > > them in the technology itself. > >I get the objection, but I don't think we can violate the rule that >how ASCII was ever processed will have to be how it will be >processed in future. I agree with this. And we need it (hence my objection to your considered change which breaks that rule with case scrambling - which is a good idea in terms of security - but I suggested you an alternative which is to use IPv6 requests). 1) an OPES filter is not a DNS change because it is a new TLD. 2) French is not ASCII but FSCII. There is no change in DNS, no change in ASCII. > If we truly want to break that, I think it's time to get to work on DNS2. Is it not already here, in the same way as Web 2.0. A generalization of existing practices and possibilities. jfc From ajs@shinkuro.com Thu Jul 2 10:04: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 3140728C14D for ; Thu, 2 Jul 2009 10:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, SARE_MONEYTERMS=0.681] 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 7C+EivGraifo for ; Thu, 2 Jul 2009 10:04:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3B16C3A69BA for ; Thu, 2 Jul 2009 10:03:54 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D57552FE9666; Thu, 2 Jul 2009 17:04:15 +0000 (UTC) Date: Thu, 2 Jul 2009 13:04:14 -0400 From: Andrew Sullivan To: jefsey Message-ID: <20090702170413.GF6393@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <20090702110522.GC6393@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] Punycode Mixed-case annotation 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, 02 Jul 2009 17:04:19 -0000 On Thu, Jul 02, 2009 at 06:41:32PM +0200, jefsey wrote: > 1. I can put a TTY 0 (which corresponds to Web 2.0 anyway), so the > ecole/Ecole data are not cached. I guess you mean "TTL". TTLs of 0 are well-known not to work everywhere, so this will likely break in at least some cases. Let's suppose you want to accept that breakage. You increase the load on the Net, too, but let's suppose you're willing to do that. > 2. unless you change the DNS for security reasons (scrambling the > lower/upper cases) "ecole" and "Ecole" will be passed as such to the > DNS, even they both are treated as "ecole". So I will filter out "Ecole" > which is meaningless to me (I need to receive xn--cole-abc.fra). I have > the right to do that because I do not change the DNS at all, only put an > OPES on the DNS. No. They _are not_ both treated as "ecole": that's exactly the problem. They both _match_ "ecole", but DNS _preserves_ case even as it is insensitive for matching. If they were in fact both _treated_ as "ecole", then I agree the entire problem would go away. By "filtering out 'Ecole'" you are in fact violating the DNS protocol. > I agree with this. And we need it (hence my objection to your considered > change which breaks that rule with case scrambling - which is a good idea > in terms of security - but I suggested you an alternative which is to use > IPv6 requests). I don't think I understand the proposal for IPv6 requests, but if you have a comment that is relevant to this it needs to be pursued in the DNSEXT WG, where we're considering the work. I encourage you to raise objections to this "0x20" approach in that forum, because we will be considering whether to adopt it and objections will form an important part of the input. > 1) an OPES filter is not a DNS change because it is a new TLD. This conflates the protocol, the database, and the data in it. > 2) French is not ASCII but FSCII. There is no change in DNS, no change in > ASCII. It doesn't matter whether "French" is in ASCII. The DNS knows nothing about the language a label is in (whatever it means for a label to be in a language). >> If we truly want to break that, I think it's time to get to work on DNS2. > > Is it not already here, in the same way as Web 2.0. A generalization of > existing practices and possibilities. I meant "a different protocol". The marketing slogan "Web 2.0" is just a name for a bunch of practices that have made people more or less wealthy. The point of a "DNS2" would be to solve the manifold issues with the existing DNS. For what it's worth, I imagine such an effort would take longer than either IPv6 or DNSSEC to get deployed. Since those two efforts have taken upwards of 15 years (and counting), I cannot believe that we'd get DNS2 (DNSng? whatever) deployed in anything like a timeline acceptable to the current user community. That's the reason I haven't started working on it: it's so late now that it will never happen. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jefsey@jefsey.com Thu Jul 2 17:28:32 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 BCA113A6876 for ; Thu, 2 Jul 2009 17:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, 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 Nxn9R4bJ5MN6 for ; Thu, 2 Jul 2009 17:28:31 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id BA8AE3A683D for ; Thu, 2 Jul 2009 17:28:31 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:2715 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MMWe2-00074I-TK; Thu, 02 Jul 2009 17:28:51 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 01:42:36 +0200 To: Vint Cerf From: JFC Morfin In-Reply-To: <7EA5A735-BCFC-410E-8AA7-43950C313036@google.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <200907021000.n62A0qEO032564@ns1.irnic.ir> <7EA5A735-BCFC-410E-8AA7-43950C313036@google.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: <20090703002831.BA8AE3A683D@core3.amsl.com> Cc: Andrew Sullivan , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 03 Jul 2009 00:28:33 -0000 At 13:32 02/07/2009, Vint Cerf wrote: >jefsey, > >thanks for taking the trouble to prepare this note. It does lay out >the issues clearly. I think I can report agreement with you in several >areas. Dear Vint, Thank you for this mail. These various exchanges took quite some time away from my planned agenda for the Interplus Draft and the Project.FRA documents, but they truly help in evaluating how to better introduce them. >First, while the IDNA working group members may not yet have reach >consensus, there is at least among them, some who would treat the >mapping on look up as a "should" (for compatibility reasons) but not a >MUST and distinguish between the basic IDN protocol that preserves the >A-label/U-label definitions and 1:1 conversion feature as part of >protocol, and the pre-processing of strings that may be destined for >lookup in the DNS. Some of the potential preprocessing is not >specified in any of the documents except to say that by the time a >look up occurs, it must be in A-label form (including the "xn--") or >must be a "traditional" ASCII form ("LDH"). One form of preprocessing, >about which we continue to debate, is to map some of the characters of >the eventual "lookup" string so as to reduce variance from >expectations that arise from the IDNA2003 behaviors. This is the actual point John and Pete made very well. SHOULD and COULD can be used in clever ways in order to influence network design, usage and management in the way most of this WG feels the best. MUST should not be used. >The DNS itself continues to have the purely ASCII behavior it has >always had to avoid requiring changes on the domain name server side. Absolutely. This is mandatory. We should not use scrambling for security purposes (moreover, IPv6 random IIDs offer a better possibility and pushes for IPv6 implementation). However, we must be careful to not harm the network in confusing what a function is supposed to do and what it can actually do without being changed but in being better used through the evolution of its upper layer context and possibilities (which usually means innovation and extended possibilities). The less we change the lower layers and the best we can use them preserve network consistency. >Second, I think there is considerable room for innovation and >standardization at a conceptual "presentation" layer - such a layer >was not defined in the Internet while some effort to define on was in >the OSI system. As applications have become increasingly >internationalized, it is arguable that codifying presentation concepts >may prove useful. Some might go so far as to suggest re-inventing the >system of binding strings to internet addresses (what the DNS does). From the dot-root community test-bed that I ran a few years ago (along the ICANN ICP-3 recommendation), I feel that there is still plenty of things to do with the DNS tools in the way that they currently are. However, there is also a lot to debate about the best way to utilize them. >While that path was not chosen in the present DNS-IDNA2003-IDNA2008 >sequence, it might be considered in the future and in my opinion, it >is in these areas (presentation and re-definition) that much of your >work, jefsey, has relevance. My concern is that this work shows that many things are already here. The Internet has really great potential. These things are not used, but they are consistently here. However, this also means that anyone freely can take advantage from them . Therefore, the real issue is to try to influence some concerted usage vision. After the hardware and software, we need to influence the brainware - in openly exploring as to how some usage architecture may turn out to be more efficient than others. This is not network technology or topology any longer but rather ideology as Rod Beckstrom would say. We face the concerns expressed by IAB in RFC 3869 . We need a review of RFC 3935 because the criteria for success are no longer only technical, or even financial, but are rather more related to a broad diversity of common, private, public, cultural, individual, and personal empowerments that we are not used to seeing at that level. >I am interpreting your message here as arguing not to change the >existing basic DNS, to confer stability at the server level, and here >we agree. ABSOLUTELY. Maybe I am wrong (and this is what project.fra should help to check), but my four leading concerns are that: - net neutrality is not engaged by "xn--" mapping at the protocol level - or it is labeled as an experiment and an alternative experiment is organized. - DNS behavior is not changed, for example by case scrambling. This does not prevent additions outside of the nameservers (through OPES, for example) in turn assisting in a smooth evolution towards what I call the Multilingual Distributed Referential System (including "DNS2", local IANA, etc.). - the ICANN dreamspace documentation complexity. I have no idea (lack of time, poor presentation of changes) as to what ICANN may be telling the world over IDNA, Fast Track - except that there seem to be conflicts ahead that result from misunderstanding and sovereignty trespasses. - nothing has been prepared in order to migrate from a single root to a virtual matrix self-deployment, i.e. billions of individual rootnameservers running billions of class/presentation roots. Its architecture and adminance (technical and administrative governance) are far less a problem (if the DNS protocols remain unchanged) than its governance and economy might be. I know these are not usual concerns for an IETF WG. - Yet small decisions by this WG will most probably decide of them due to the DNS importance in the world life. - This is why I first tried to explore the IETF precautionary duty (http://tools.ietf.org/html/draft-iucg-precaution-00.html) jfc From jefsey@jefsey.com Thu Jul 2 18:52: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 21B893A6C78 for ; Thu, 2 Jul 2009 18:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=1.088, 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 3RLFjzupOqZd for ; Thu, 2 Jul 2009 18:52:45 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id F3F133A683F for ; Thu, 2 Jul 2009 18:52:44 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:3230 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MMXwJ-0004eO-TQ; Thu, 02 Jul 2009 18:51:48 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 03:51:35 +0200 To: Mark Davis ,Vint Cerf , Andrew Sullivan ,iucg@ietf.org, Arabic Scripts IDNA , IDNA update work From: JFC Morfin In-Reply-To: <30b660a20907021647p1e1131exf6c0a166cc0ca5e9@mail.gmail.com > References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> <200907011222.n61CMrPx001109@smtp.google.com> <8FB03160-1D7F-4E73-8F6C-16093771E1AB@google.com> <200907011313.n61DDF4F029038@ns1.irnic.ir> <30b660a20907021647p1e1131exf6c0a166cc0ca5e9@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_147789406==.ALT" 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: <20090703015244.F3F133A683F@core3.amsl.com> Cc: michel@suignard.com, Kenneth Whistler Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 03 Jul 2009 01:52:46 -0000 --=====================_147789406==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Dear all, Will I answer Mark? No. My prority is now with the Interplus Draft as a working document. So I would lack the time. But mainly this is because I could not. What Mark talks about is not nonsense.However, (1) everyone knows it (2) it is by nature a different topic. I am a multilinguist (simultaneous technical support of a language diversity), not a linguist (discussing individual language cases). Mark's interest is in globalization, i.e. the system he invented to support foreign languages in English technologies. As such it is a great success. It has the technical cons and pros of being an English language machine-centric system. My interest is in presentation and extended services network layers. This what we need in order to empower: - without constraints every language (including English, French, Arabic, Chinese etc.) - as part of semiotic (including scripts) mediatic end to end functions (access, addressing, delivery, routing, etc.) , - in every technology (including the Internet), - in using every coding (including Unicode), - for every application (including IDNA), - in every environment from brain cells to outerspace identified by their namespaces. This is a people centric system, to accomodate the relations of the people diversity in what they are and what they do. Is it a reason why to disregard Unicode? No! As fas as the Internet is concerned, Unicode is a structured set of code-points. If IDNA users are happy with it, the Internet should be happy with it. If they are not, they should be not. Does that mean that Unicode should be disregarded ? No! The same as Unicode is not a reason for disregarding the DNS (this is the justification of IDNA). Each addresses the needs of a different layer. Layers need to cooperate. In order for all them to progress in symbiosis. NB. what Marks discusses is not obsolete, it is just (as he documents it himself very well) a layer below what I discuss. Best. jfc At 01:47 03/07/2009, Mark Davis wrote: >What Jefsey suggests is all nonsense. > >Here is what is happening. Basically, one can make a distinction >between capital letters that are required linguistically (the L at >the start of the sentence below and the M at the start of the proper >name Marcel in the example below) and those that just happen to have >a capital form (because the sentence is set in all caps). The former >in French are called majuscules, and the latter capitales. From Wikipedia: > >La phrase : « LONGTEMPS MARCEL S’EST COUCHÉ DE BONNE HEURE » >est écrite en capitales, mais seule la première et la dixième >lettres sont majuscules. On s’en rend mieux compte si on écrit >cette phrase en petites capitales : « Longtemps Marcel s’est >couché de bonne heure ». > >However, that distinction is not captured in Unicode, nor in ASCII, >nor in any other character encodings that I know of, nor should it >be. There are many distinctions in the usage of characters that are >not, and should not be, represented in the encoding. One could just >as well argue that the distinction between the pronunciation of "o" >in "rove", "move", and "love" needs to be in the encoding, or that >the difference between the "." in "1.2", "etc.", or "." at the end >of a sentence needs to be in the encoding. That would end up with >scads of identical characters that people would not distinguish when >keying, could not distinguish in display, are not in any existing >data, could not be depended on in processing, but would be just a >marvelous opportunity for spoofing! >Nor, of course, should anyone think of trying to capture this >distinction in IDNA. > >Mark --=====================_147789406==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear all,
Will I answer Mark? No.

My prority is now with the Interplus Draft as a working document. So I would lack the time. But mainly this is because I could not.
What Mark talks about is not nonsense.However, (1) everyone knows it (2) it is by nature a different topic.
I am a multilinguist (simultaneous technical support of a language diversity), not a linguist (discussing individual language cases).

Mark's interest is in globalization, i.e. the system he invented to support foreign languages in English technologies. As such it is a great success. It has the technical cons and pros of being an English language machine-centric system.

My interest is in presentation and extended services network layers. This what we need in order to empower:
- without constraints every language (including English, French, Arabic, Chinese etc.)
- as part of semiotic (including scripts) mediatic end to end functions (access, addressing, delivery, routing, etc.) ,
- in every technology (including the Internet),
- in using every coding (including Unicode),
- for every application (including IDNA),
- in every environment from brain cells to outerspace identified by their namespaces.
This is a people centric system, to accomodate the relations of the people diversity in what they are and what they do. Is it a reason why to disregard Unicode? No!  As fas as the Internet is concerned, Unicode is a structured set of code-points. If IDNA users are happy with it, the Internet should be happy with it. If they are not, they should be not.

Does that mean that Unicode should be disregarded ? No!

The same as Unicode is not a reason for disregarding the DNS (this is the justification of IDNA). Each addresses the needs of a different layer. Layers need to cooperate. In order for all them to progress in symbiosis.

NB. what Marks discusses is not obsolete, it is just (as he documents it himself very well) a layer below what I discuss.
Best.
jfc
 
 

At 01:47 03/07/2009, Mark Davis wrote:
What Jefsey suggests is all nonsense.

Here is what is happening. Basically, one can make a distinction between capital letters that are required linguistically (the L at the start of the sentence below and the M at the start of the proper name Marcel in the example below) and those that just happen to have a capital form (because the sentence is set in all caps). The former in French are called majuscules, and the latter capitales. >From Wikipedia:

La phrase : « LONGTEMPS MARCEL S’EST COUCHÉ DE BONNE HEURE » est écrite en capitales, mais seule la première et la dixième lettres sont majuscules. On s’en rend mieux compte si on écrit cette phrase en petites capitales : « Longtemps Marcel s’est couché de bonne heure ».

However, that distinction is not captured in Unicode, nor in ASCII, nor in any other character encodings that I know of, nor should it be. There are many distinctions in the usage of characters that are not, and should not be, represented in the encoding. One could just as well argue that the distinction between the pronunciation of "o" in "rove", "move", and "love" needs to be in the encoding, or that the difference between the "." in "1.2", "etc.", or "." at the end of a sentence needs to be in the encoding. That would end up with scads of identical characters that people would not distinguish when keying, could not distinguish in display, are not in any existing data, could not be depended on in processing, but would be just a marvelous opportunity for spoofing!
Nor, of course, should anyone think of trying to capture this distinction in IDNA.

Mark
--=====================_147789406==.ALT-- From mark.edward.davis@gmail.com Thu Jul 2 16:47:34 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 72D7528C147 for ; Thu, 2 Jul 2009 16:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 MuD25Cse6lpD for ; Thu, 2 Jul 2009 16:47:32 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id D76953A6876 for ; Thu, 2 Jul 2009 16:47:31 -0700 (PDT) Received: by yxe12 with SMTP id 12so3222776yxe.29 for ; Thu, 02 Jul 2009 16:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=6YvRFffZgMDMiM9blhUtb5b0VqejwF1JiRhLcw+UMxc=; b=Y1umDzE/oFI+o7QpgicOmQzVzTka4EqH2GlJKFQ1QKBq19dwGOZGrQbwqtSygd9tdF 0MWJDrOLMT0dUo5/e6HR+WLtzaj4SW6svwSREuOGK6Vu0URqpsvXJ9DgFMFkNWoIyODM xg0rk7ZRc/bugpM5PS37VcfFH/+cDBzoV9Uo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=bGcTgqBnmzWmLIZ9mcLYk61nxGlOjHXyfc6pJrWPY2tZ4BJiyyTUlA0Tv87RfEkHeC YpbaEYT7BZ2G4jeQMIcdX+ysZgCVsTCopAUgBpK3tqBiPhava2Pu6eQ3JvdETr3ohOxJ OrpMbZxWZl9piJWUZ1NDYpe3+jkT+NExJxeA8= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.100.34.3 with SMTP id h3mr978560anh.137.1246578462314; Thu, 02 Jul 2009 16:47:42 -0700 (PDT) In-Reply-To: <200907011313.n61DDF4F029038@ns1.irnic.ir> References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> <200907011222.n61CMrPx001109@smtp.google.com> <8FB03160-1D7F-4E73-8F6C-16093771E1AB@google.com> <200907011313.n61DDF4F029038@ns1.irnic.ir> Date: Thu, 2 Jul 2009 16:47:42 -0700 X-Google-Sender-Auth: b716313a35c8b78a Message-ID: <30b660a20907021647p1e1131exf6c0a166cc0ca5e9@mail.gmail.com> From: Mark Davis To: Vint Cerf , Andrew Sullivan , iucg@ietf.org, Arabic Scripts IDNA , IDNA update work Content-Type: multipart/alternative; boundary=0016e64712586e53c0046dc1aa49 X-Mailman-Approved-At: Thu, 02 Jul 2009 18:53:46 -0700 Cc: michel@suignard.com, Kenneth Whistler Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 02 Jul 2009 23:47:34 -0000 --0016e64712586e53c0046dc1aa49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What Jefsey suggests is all nonsense. Here is what is happening. Basically, one can make a distinction between capital letters that are required linguistically (the *L* at the start of the sentence below and the *M* at the start of the proper name *Marcel* in the example below) and those that just happen to have a capital form (because the sentence is set in all caps). The former in French are called = * majuscules*, and the latter *capitales*. From Wikipedia: La phrase : =C2=AB LONGTEMPS MARCEL S=E2=80=99EST COUCH=C3=89 DE BONNE HEUR= E =C2=BB est =C3=A9crite en capitales, mais seule la premi=C3=A8re et la dixi=C3=A8me lettres sont maju= scules. On s=E2=80=99en rend mieux compte si on =C3=A9crit cette phrase en petites cap= itales : =C2=AB Longtemps Marcel s=E2=80=99est couch=C3=A9 de bonne heure =C2=BB. However, that distinction is not captured in Unicode, nor in ASCII, nor in any other character encodings that I know of, *nor should it be*. There are many distinctions in the *usage* of characters that are not, and should not be, represented in the encoding. One could just as well argue that the distinction between the pronunciation of "o" in "rove", "move", and "love" needs to be in the encoding, or that the difference between the "." in "1.2", "etc.", or "." at the end of a sentence needs to be in the encoding. That would end up with scads of identical characters that people would not distinguish when keying, could not distinguish in display, are not in any existing data, could not be depended on in processing, but would be just a marvelous opportunity for spoofing! Nor, of course, should anyone think of trying to capture this distinction i= n IDNA. Mark On Wed, Jul 1, 2009 at 06:13, jefsey wrote: > At 14:38 01/07/2009, Vint Cerf wrote: > >> Jefsey, maybe my email rendering code is broken but the string I am >> seeing in your message looks like a purely ascii string making it a >> conventional ascii domain name not requiring any special treatment. >> > > Vint, > The string you see on your screen is ASCII - the string I enter is not. > This is because Unicode is being used and Unicode does not properly suppo= rts > the French language orthotypography. > > In "Ecole.fra" the semantics demands that "E" is not an "E" ASCII but a > French "E" majuscule. I am sure Unicode has no problem in supporting them= , > or TLD Tables can be used. "Ecole.fra" is a user domain name which may ha= ve > nothing to do (except phishing) with "=C3=A9cole.fra", "ecole.fra" and > "=C3=89cole.fra". > > This means there are wo problems: > > - they are to be able to resolve different IP addresses. > - they also are to be able to resolve the same IP address. > > However, the decision is only with the registrant. So, the simplest is to > consider each usage domain name separately. If some are to resolve the sa= me > IP, the registrant will only register several domain names. > > jfc > > > > On Jul 1, 2009, at 8:19 AM, JFC Morfin wrote: >> >> At 04:18 01/07/2009, Vint Cerf wrote: >>> >>>> jefsey, it cannot be an A-label since that is defined to include >>>> "xn--" as a prefix. >>>> >>> >>> Dear Vint, >>> This is the conflict we have and the resulting confusion. >>> >>> - usage considers what is enter in usage applications (from the >>> entire Unicode set [actually it needs much more (ex.Natal from M$] >>> _including_ ASCII) >>> - I consider what the DNS is asked to resolve after an algorithm >>> (including null and punycode ones) has been applied. >>> - you consider complex U-/A-... labels which do not overlap. >>> "Ecole.fra" is not supported by this label list. >>> >>> "Ecole.fra", >>> 1) it is a U-label >>> 2) but you do not want to support it as xn--cole-abc.fra. You keep >>> it as an non punycoded yet A-label without "xn--" prefix. >>> 3) this confuses Andrew and John (who should not be concerned) >>> because they try to understand how the DNS and Unicode casefolding >>> could support the orthogonal User's casefolding (i.e. >>> orthotypography). >>> >>> I see no other solution that to carry the mapping: >>> - at the user application layer (outside of the Internet pile) and >>> the Internet should remain transparent to "xn--" labels. >>> - through a different presentation, and casefolding mapping etc. >>> using "xs--" labels. >>> >>> Neither DNS nor Unicode casefolding are concerned. Only usage's side >>> application (this is why the architecture is named IDNA): usage >>> casefolding is to be decided and managed by the user through his >>> application (if he wants to have it), depending on his own context, >>> language, culture, job, kind of application, etc. and if the other >>> end supports additional usage side features. This permits an >>> application to application relation, where entropic actions (as >>> required by the DNS resolution) can be restored through a >>> negantropic process supported by metadata exchanges. As Elisabeth >>> explained it. >>> >>> This being said, if you find a case (so far there is none) where a >>> entropic mapping (casefolding or other) is universally accepted by >>> users - or restored through a negentropic process such as what we >>> call "duplex entities" -, supported by exvery encryption system, >>> transparent to other technologies as well (netneutrality), etc. it >>> could very well be investigated at protocol level (i.e within the >>> Internet pile). Otherwise mapping can only be processed outside of >>> the Internet pile. This is exactly the target and Charter of IDNA as >>> I read and respect it. >>> >>> jfc >>> >>> >>> On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote: >>>> >>>> At 17:12 30/06/2009, Andrew Sullivan wrote: >>>>> >>>>>> and, in particular, if we want to be sensitive to such upper and >>>>>> lower case when the data comes back to us from the DNS resolver >>>>>> level. >>>>>> >>>>> >>>>> Please, let not confuse : >>>>> >>>>> 1) the DNS layer, where you run the game the way you want according >>>>> to your published rules, and the Application Domain Names. >>>>> 2) French majuscules and upper cases. >>>>> >>>>> The U-label, A-label, etc. wording IMHO helps that confusion. Is >>>>> Ecole.fra an U-label or an A-label? All I know is that it is an >>>>> application domain name (like in "IDNA"). Also, that if the proposed >>>>> text does not actually document the "ecole.fra, =C3=A9cole.fra, >>>>> Ecole.fra" case, this case will have to be documented during the >>>>> IETF/LC. >>>>> >>>>> May be it is the best thing to do? so the whole IETF community may >>>>> decide what does concern the whole community? >>>>> jfc >>>>> >>>>> _______________________________________________ >>>>> Idna-arabicscript mailing list >>>>> Arabic Script IDN Working Group (ASIWG) >>>>> Idna-arabicscript@lists.irnic.ir >>>>> http://lists.irnic.ir/mailman/listinfo/idna-arabicscript >>>>> >>>> > _______________________________________________ > Idna-arabicscript mailing list > Arabic Script IDN Working Group (ASIWG) > Idna-arabicscript@lists.irnic.ir > http://lists.irnic.ir/mailman/listinfo/idna-arabicscript > --0016e64712586e53c0046dc1aa49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What Jefsey suggests is all nonsense.

Here is what is happening. Bas= ically, one can make a distinction between capital letters that are require= d linguistically (the L at the start of the sentence below and the <= i>M at the start of the proper name Marcel in the example below)= and those that just happen to have a capital form (because the sentence is= set in all caps). The former in French are called majuscules, and t= he latter capitales. From Wikipedia:

La phrase=C2=A0: =C2=AB=C2=A0LONGTEMPS MARCEL S=E2=80=99EST COUCH=C3=89 = DE BONNE HEURE=C2=A0=C2=BB est =C3=A9crite en capitales, mais seule la premi=C3=A8re et la dixi=C3=A8me le= ttres sont majuscules. On s=E2=80=99en rend mieux compte si on =C3=A9crit cette phrase= en petites capitales=C2=A0: =C2=AB=C2=A0Longtemps Marcel s=E2=80=99est couch=C3=A9 de bonne heure=C2=A0= =C2=BB.

However, that distinction is not captured in Unicode, nor in ASCII= , nor in any other character encodings that I know of, nor should it be. There are many distinctions in the usage of characters that are not, and should not be, represented in the encodin= g. One could just as well argue that the distinction between the pronunciat= ion of "o" in "rove", "move", and "love&= quot; needs to be in the encoding, or that the difference between the "= ;." in "1.2", "etc.", or "." at the end = of a sentence needs to be in the encoding. That would end up with scads of = identical characters that people would not distinguish when keying, could n= ot distinguish in display, are not in any existing data, could not be depen= ded on in processing, but would be just a marvelous opportunity for spoofin= g!

Nor, of course, should anyone think of trying to capture this distinction i= n IDNA.

Mark

On Wed, Jul 1, 2009 at 06:13, jefsey <jefsey@jefsey.com> wrote:
At 14:38 01/07/2009, Vint Cerf wrote:
Jefsey, maybe my email rendering code is broken but the string I am
seeing in your message looks like a purely ascii string making it a
conventional ascii domain name not requiring any special treatment.

Vint,
The string you see on your screen is ASCII - the string I enter is not. Thi= s is because Unicode is being used and Unicode does not properly supports t= he French language orthotypography.

In "Ecole.fra" the semantics demands that "E" is not an= "E" ASCII but a French "E" majuscule. I am sure Unicod= e has no problem in supporting them, or TLD Tables can be used. "Ecole= .fra" is a user domain name which may have nothing to do (except phish= ing) with "=C3=A9cole.fra", "ecole.fra" and "=C3= =89cole.fra".

This means there are wo problems:

- they are to be able to resolve different IP addresses.
- they also are to be able to resolve the same IP address.

However, the decision is only with the registrant. So, the simplest is to c= onsider each usage domain name separately. If some are to resolve the same = IP, the registrant will only register several domain names.

jfc



On Jul 1, 2009, at 8:19 AM, JFC Morfin wrote:

At 04:18 01/07/2009, Vint Cerf wrote:
jefsey, it cannot be an A-label since that is defined to include
"xn--" as a prefix.

Dear Vint,
This is the conflict we have and the resulting confusion.

- usage considers what is enter in usage applications (from the
entire Unicode set [actually it needs much more (ex.Natal from M$]
_including_ ASCII)
- I consider what the DNS is asked to resolve after an algorithm
(including null and punycode ones) has been applied.
- you consider complex U-/A-... labels which do not overlap.
"Ecole.fra" is not supported by this label list.

"Ecole.fra",
1) it is a U-label
2) but you do not want to support it as xn--cole-abc.fra. You keep
it as an non punycoded yet A-label without "xn--" prefix.
3) this confuses Andrew and John (who should not be concerned)
because they try to understand how the DNS and Unicode casefolding
could support the orthogonal User's casefolding (i.e.
orthotypography).

I see no other solution that to carry the mapping:
- at the user application layer (outside of the Internet pile) and
the Internet should remain transparent to "xn--" labels.
- through a different presentation, and casefolding mapping etc.
using "xs--" labels.

Neither DNS nor Unicode casefolding are concerned. Only usage's side application (this is why the architecture is named IDNA): usage
casefolding is to be decided and managed by the user through his
application (if he wants to have it), depending on his own context,
language, culture, job, kind of application, etc. and if the other
end supports additional usage side features. This permits an
application to application relation, where entropic actions (as
required by the DNS resolution) can be restored through a
negantropic process supported by metadata exchanges. As Elisabeth
explained it.

This being said, if you find a case (so far there is none) where a
entropic mapping (casefolding or other) is universally accepted by
users - or restored through a negentropic process such as what we
call "duplex entities" -, supported by exvery encryption system,<= br> transparent to other technologies as well (netneutrality), etc. it
could very well be investigated at protocol level (i.e within the
Internet pile). Otherwise mapping can only be processed outside of
the Internet pile. This is exactly the target and Charter of IDNA as
I read and respect it.

jfc


On Jun 30, 2009, at 8:42 PM, JFC Morfin wrote:

At 17:12 30/06/2009, Andrew Sullivan wrote:
and, in particular, if we want to be sensitive to such upper and
lower case when the data comes back to us from the DNS resolver
level.

Please, let not confuse :

1) the DNS layer, where you run the game the way you want according
to your published rules, and the Application Domain Names.
2) French majuscules and upper cases.

The U-label, A-label, etc. wording IMHO helps that confusion. Is
Ecole.fra an U-label or an A-label? All I know is that it is an
application domain name (like in "IDNA"). Also, that if the propo= sed
text does not actually document the "ecole.fra, =C3=A9cole.fra,
Ecole.fra" case, this case will have to be documented during the
IETF/LC.

May be it is the best thing to do? so the whole IETF community may
decide what does concern the whole community?
jfc

_______________________________________________
Idna-arabicscript mailing list
Arabic Script IDN Working Group (ASIWG)
Idna-= arabicscript@lists.irnic.ir
http://lists.irnic.ir/mailman/listinfo/idna-arabicscript

_______________________________________________
Idna-arabicscript mailing list
Arabic Script IDN Working Group (ASIWG)
Idna-= arabicscript@lists.irnic.ir
http://lists.irnic.ir/mailman/listinfo/idna-arabicscript

--0016e64712586e53c0046dc1aa49-- From jmabdp@gmail.com Thu Jul 2 19:58:13 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 40DF73A6C7C for ; Thu, 2 Jul 2009 19:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 m7-3nCKxawiN for ; Thu, 2 Jul 2009 19:58:09 -0700 (PDT) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id F0BC83A6C6B for ; Thu, 2 Jul 2009 19:58:08 -0700 (PDT) Received: by ewy11 with SMTP id 11so719783ewy.37 for ; Thu, 02 Jul 2009 19:58:18 -0700 (PDT) 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=KwYVic6uW62HCQgOUhN+fK0TvHBMZ+qHc+7X3pQ+Res=; b=ZPvy7E7pAcN2IrEL8pSVx+eNVTC0JQgCHWJF7kqsJn1+xT/oMN8gkSQtVYdWzdy8Bn +T2dKUFfyiTElGl4xLFGD+pwQ9hCuL54uAreMQFevs4da3oCfSFFcKXlq7JHxqThWedQ NNdM9SAwjkvbq4KizZsUi0psq2c8prYvKYheU= 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=tLZ1RLOK6ZZu+NuGY1V8zkIiv+mgV+LyYj1/ci7o85C+IDufKtRsHwFyXaSJ8cLH3c o6xQG3vfvTsWvAyKCTMWUvUcjppU8aU+xPCY5B3OYqlVDzkU/r+N5Afe4PsG4PH/qp+p fxEA6IKKAn9Z7P9frZjk3q9UTQAXwrrt78PYU= MIME-Version: 1.0 Received: by 10.216.29.73 with SMTP id h51mr224057wea.16.1246589897886; Thu, 02 Jul 2009 19:58:17 -0700 (PDT) In-Reply-To: <30b660a20907021647p1e1131exf6c0a166cc0ca5e9@mail.gmail.com> References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> <200907011222.n61CMrPx001109@smtp.google.com> <8FB03160-1D7F-4E73-8F6C-16093771E1AB@google.com> <200907011313.n61DDF4F029038@ns1.irnic.ir> <30b660a20907021647p1e1131exf6c0a166cc0ca5e9@mail.gmail.com> Date: Fri, 3 Jul 2009 04:58:17 +0200 Message-ID: <6aad7a210907021958n15e029e5x33ef3539cca1924f@mail.gmail.com> From: jean-michel bernier de portzamparc To: Mark Davis Content-Type: multipart/alternative; boundary=0016e6d63f6c0b4cea046dc4544c Cc: Andrew Sullivan , michel@suignard.com, IDNA update work , iucg@ietf.org, Kenneth Whistler , Vint Cerf , Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 03 Jul 2009 02:58:13 -0000 --0016e6d63f6c0b4cea046dc4544c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Dr. Davis, Do you mean that the project.fra is a nonsense, that academics participating to it are ignorant, that politicians supporting it are fooled by Jefsey, that supporting linguists dont know their mother tongue, and that its future users' IQ will be too low for them to understand on the internet the words of their very daily language? Is that not a little blunt? Portzamparc --0016e6d63f6c0b4cea046dc4544c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Dr. Davis,
Do you mean that the project.fra is a nonsense, that aca= demics participating to it are ignorant, that politicians supporting it are= fooled by Jefsey, that supporting linguists dont know their mother tongue,= and that its future users' IQ will be too low for them to understand o= n the internet the words of their very daily language?=A0

Is that not a little blunt?
Portzamparc

--0016e6d63f6c0b4cea046dc4544c-- From ajs@shinkuro.com Fri Jul 3 04:17:22 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 82C8C3A6E34 for ; Fri, 3 Jul 2009 04:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.515, 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 NpgMndCcUQHy for ; Fri, 3 Jul 2009 04:17:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B03CF3A6E36 for ; Fri, 3 Jul 2009 04:17:21 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1D8732FE9667; Fri, 3 Jul 2009 11:17:44 +0000 (UTC) Date: Fri, 3 Jul 2009 07:17:42 -0400 From: Andrew Sullivan To: JFC Morfin Message-ID: <20090703111741.GB8620@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <200907021000.n62A0qEO032564@ns1.irnic.ir> <7EA5A735-BCFC-410E-8AA7-43950C313036@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Vint Cerf , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 03 Jul 2009 11:17:22 -0000 On Fri, Jul 03, 2009 at 01:42:36AM +0200, JFC Morfin wrote: > - nothing has been prepared in order to migrate from a single root to a > virtual matrix self-deployment, i.e. billions of individual > rootnameservers running billions of class/presentation roots. Indeed, nothing has been done that way, and that's because it's a completely incoherent idea. The DNS namespace is a coherent namespace with a single root. If you have "billions of individial rootnameservers running billions of … roots", you're imagining something. The namespace is structured such that you have to start _somewhere_. If you have another layer "beyond the root" that tells you where to look things up, then all you have done is move the root around. Having actually billions of entries in the rootserver.hints file would be, frankly, stupid: not copying around such a list is what the DNS was invented for. I think you know that perfectly well. If you want a distributed hash table, self-publication arrangement, I encourage you to get to work. Several such proposals have already foundered on the serious problem that, in a global context (and I know that individuals aren't on purpose in a global context, but the network still provides access to that context anyway) it's very hard to get unique names without co-ordination. If you have a magic solution to that problem, excellent. But let's not confuse matters by talking about "billions of roots". A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jefsey@jefsey.com Fri Jul 3 05:07: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 545D128C28D for ; Fri, 3 Jul 2009 05:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.320, 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 7bMfBeI00ykW for ; Fri, 3 Jul 2009 05:07:08 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 7A7C83A67EB for ; Fri, 3 Jul 2009 05:07:08 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:1497 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MMhY9-0003Kv-7A; Fri, 03 Jul 2009 05:07:29 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 14:06:57 +0200 To: internet users contributing group , Mark Davis From: jefsey In-Reply-To: <6aad7a210907021958n15e029e5x33ef3539cca1924f@mail.gmail.co m> References: <20090630151238.GB3059@shinkuro.com> <200907010138.n611cX3Q021352@ns1.irnic.ir> <200907011222.n61CMrPx001109@smtp.google.com> <8FB03160-1D7F-4E73-8F6C-16093771E1AB@google.com> <200907011313.n61DDF4F029038@ns1.irnic.ir> <30b660a20907021647p1e1131exf6c0a166cc0ca5e9@mail.gmail.com> <6aad7a210907021958n15e029e5x33ef3539cca1924f@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: <20090703120708.7A7C83A67EB@core3.amsl.com> Cc: Andrew Sullivan , michel@suignard.com, IDNA update work , iucg@ietf.org, Kenneth Whistler , Vint Cerf , Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 03 Jul 2009 12:07:09 -0000 Jean-Michel, Please, let keep it cool. Mark is a linguist using English based/biased (not pejorative) digital computers as they are, and feeding them with "pre-data" (Unicode, CLDR) in order to permit them to work correctly in an English+languages+scripts context. He must be thanked a lot for that. Now, we are confronting him with a new technical challenge, because the "computers" we consider are very different. They are networked, virtual (in many ways), with semiotic interface, semantic and neuronal, and interactive with distant humans (heterarchic context). So, he is fully correct in challenging the sense of what we say. This is not because I say something that I am right against the entire world. He just overdoes it a little in starting with a conclusion ("this is nonsense") and too quick in his thinking (he associates the whole of what we say, only with French language related details). However, - challenging what we say on linguistic grounds is not an IETF issue. As the IETF we are not here to oppose the specs and direct the users. - discussing French language will always be opposed, as for the Arabic Tatweel: are you sure everyone agrees with you? We do not want to go by a single gopel but by the diverse and sometimes opposing people ways. - we certainly are interested in making sure that the technology we want to add will make the best out of his Unicode, and his inputs are very welcome. As well as his comments when we want to use Unicode and some "meta-data" we have to enrich it. - we also are very interested in his command of English and French and his love of the French language, because he may better perceive what is pragmatic (context dependent) and semantic (meaning related) in what we consider. Moreover when we consider the French, English, Chinese, etc. languages not only as a human languages but as particular parts of a semantic multilinguistic metatechnology. Mark is a long time practitioneer of a part which interests us a lot: human usage interface with "mecanologie". How people do react when confronted with new "mechanical" rules (such as Unicode tables, locale files, etc.). We have much to learn from him about man/machine relation in a language context I do hope he accepts to work with us, helping us to correct what we might think wrong. Best jfc At 04:58 03/07/2009, jean-michel bernier de portzamparc wrote: >Dear Dr. Davis, >Do you mean that the project.fra is a nonsense, that academics >participating to it are ignorant, that politicians supporting it are >fooled by Jefsey, that supporting linguists dont know their mother >tongue, and that its future users' IQ will be too low for them to >understand on the internet the words of their very daily language? > >Is that not a little blunt? >Portzamparc > >_______________________________________________ >iucg mailing list >iucg@ietf.org >https://www.ietf.org/mailman/listinfo/iucg From jefsey@jefsey.com Fri Jul 3 06:25: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 36F063A6A5A for ; Fri, 3 Jul 2009 06:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 Bv2h7UDESrMU for ; Fri, 3 Jul 2009 06:25:15 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 9144A3A6E2E for ; Fri, 3 Jul 2009 06:25:15 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:1783 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MMilP-00052A-KB; Fri, 03 Jul 2009 06:25:16 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 15:25:12 +0200 To: Andrew Sullivan From: JFC Morfin In-Reply-To: <20090703111741.GB8620@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <200907021000.n62A0qEO032564@ns1.irnic.ir> <7EA5A735-BCFC-410E-8AA7-43950C313036@google.com> <20090703111741.GB8620@shinkuro.com> 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: <20090703132515.9144A3A6E2E@core3.amsl.com> Cc: Vint Cerf , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 03 Jul 2009 13:25:17 -0000 At 13:17 03/07/2009, Andrew Sullivan wrote: >On Fri, Jul 03, 2009 at 01:42:36AM +0200, JFC Morfin wrote: > > - nothing has been prepared in order to migrate from a single root to a > > virtual matrix self-deployment, i.e. billions of individual > > rootnameservers running billions of class/presentation roots. Dear Andrew, I read and understand what you say. The difference between our perceptions is simple to understand. The IETF is to influence those who build, use, and manage the Internet so it works better; the Internet (capital "I") is made of all the computers that can interoperate throughout the world via (IP) packetswitch networks. This is the IETF/USC description of the issue. The best one can think in that context is what ISOC calls for : all this is to be "[internet] user centric". Then all what you say is then coherent: the facilitating technologie decides. I am not user centric. I am realist. If Brian Carpenter explained me that the least IETF heard about WSIS the best it was, it is because the entire world consensus (IETF not being here) disagreed with ISOC (USA included) and said it wanted a human society which would be "people centered, à caractère humain, centrada en la persona". The person decides and the facilitating technology serves. This is something I identifed in 1976 when starting considering the digital facilitation architecture the world needed. So, I am more familiar with the implications. This is also something which corresponds to the French legal definition of the necessary tools (including the internet) of the "on-line public communication and services". In a DNS user centric world you can centralise it. In a distributed people centric world you can only accept that I (and everyone can do the same) use the root file and the nameserver I loaded on my lap-top. In terms of architecture it only means that the DNS is not a replacement for the Host.txt job, but a replacement for its maintenance job. The problem we have to solve is that as soon as users learn about all the cons and pros of a local rootnameserver and then about the cons and pros of presentation and classes rootnameservers we will face a borad diversity of usage and a big risk of pollution. Today the namespace consistency is "mechanically" constrained by the "root server tale". We urgently need to build, document and make appealing a "virtual matrix tale" which sounds and is (people are more and more technology aware) technically acceptable and pertinent to the next century development. I feel there may be some, but I presently see none. This is a reason of project.fra: to discover what can keep a virtual terminology (such as the DNS supported semantic addressing) stable enough for the world to continue to trust it. Human languages do it pretty well for a long time, Trad Marks also. These are good omens. But I am afraid the "structured namespace starting somewhere" justification will not be of use. Starting somewhere is the attribute of an entity, not of billions of human entities. Now, if you want who is the first to propagate the call about this: http://www.icann.org/en/icp/icp-3.htm. "In an ever-evolving Internet, ultimately there may be better architectures for getting the job done where the need for a single, authoritative root will not be an issue. But that is not the case today. And the transition to such an architecture, should it emerge, would require community-based approaches. In the interim, responsible experimentation should be encouraged, but it should not be done in a manner that affects those who do not consent after being informed of the character of the experiment.". I carried such an experimentation ICANN asked the IETF to carry. All I can say, is that time has flown. Now, if you want to compute some figures. I think it is rather conservative - to consider one root per idolect/avalect (person, avatar), per relational space and per parametrised application (look at yesterday mail of Mark Davis. The "nonsense" is simply the support of what I perceive as the reality. - then you will to consider versions of each namespaces (ex. the "kid" filtered version of the ".com" namespace - nothing to do with "kid.com" or ".kid"). This may make trillions. To address this we have to think, not of namespace controlled delivery, but about open usage, not in terms of maintenance but in terms of access. Just think that "unicode.org" can legally resolve into thousands of IP addresses, in thousands of classes. No, I have no magic solution. But I try to find today working and quickly deployable ones, in considering, investigating, testing the reality. The only thing I know is that constraining the network (such as "mapping at protocol level") only complexify the network (making further solutions more complex) and will be immediately circumvented, accelerating the problem. jfc >Indeed, nothing has been done that way, and that's because it's a >completely incoherent idea. The DNS namespace is a coherent namespace >with a single root. If you have "billions of individial >rootnameservers running billions of … roots", you're imagining >something. The namespace is structured such that you have to start >_somewhere_. If you have another layer "beyond the root" that tells >you where to look things up, then all you have done is move the root >around. Having actually billions of entries in the rootserver.hints >file would be, frankly, stupid: not copying around such a list is what >the DNS was invented for. I think you know that perfectly well. > >If you want a distributed hash table, self-publication arrangement, I >encourage you to get to work. Several such proposals have already >foundered on the serious problem that, in a global context (and I know >that individuals aren't on purpose in a global context, but the >network still provides access to that context anyway) it's very hard >to get unique names without co-ordination. If you have a magic >solution to that problem, excellent. But let's not confuse matters by >talking about "billions of roots". > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. From ajs@shinkuro.com Fri Jul 3 10:16:58 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 D703C28C2F9 for ; Fri, 3 Jul 2009 10:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.514, 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 DkvL7seo7mFF for ; Fri, 3 Jul 2009 10:16:58 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3D53628C2FD for ; Fri, 3 Jul 2009 10:16:46 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 85E9C2FE9666; Fri, 3 Jul 2009 17:16:49 +0000 (UTC) Date: Fri, 3 Jul 2009 13:16:47 -0400 From: Andrew Sullivan To: JFC Morfin Message-ID: <20090703171647.GJ8620@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <200907021000.n62A0qEO032564@ns1.irnic.ir> <7EA5A735-BCFC-410E-8AA7-43950C313036@google.com> <20090703111741.GB8620@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Vint Cerf , iucg@ietf.org, Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 03 Jul 2009 17:16:58 -0000 On Fri, Jul 03, 2009 at 03:25:12PM +0200, JFC Morfin wrote: > In a DNS user centric world you can centralise it. In a distributed > people centric world you can only accept that I (and everyone can do the > same) use the root file and the nameserver I loaded on my lap-top. You are simply equivocating on the term "root" in that statement, which is what I was saying in the first place. "The root" just means where the namespace starts. If you happen to have a bunch of root nameservers that aren't in the IANA root, then you have a different root. That's all. > terms of architecture it only means that the DNS is not a replacement for > the Host.txt job, but a replacement for its maintenance job. I think it more accurate to say that the DNS was intended to supersede the old mechanism because maintaining the old mechanism was difficult, error-prone, and cumbersome. You appear to think that it has some advantage. I think I understand what that advantage is, and in my opinion you're being unrealistic. The fact is that mostly-closed, mostly-insular, tightly-knit communities give up some of the advantages of that cohesiveness in order to interact with people outside their community. That's what's happened in the case of the Internet: to use the technology, everyone has to adjust themselves some to it even as it has to be adjusted some to everyone. There is no such thing as a technology that does not change the users even as the users change the technology, and dreaming that our technology will exclusively be bent to our collective will is a way to be disappointed in future. (I think this is one of the central points of Latour's _Nous n'avons jamais été modernes_, among others of that set. It's certainly one of the central points Haraway makes, and I've yet to see a coherent argument against her position.) Anyway, I think we've strayed very far from the point of this discussion, so I won't indulge more in it. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jmabdp@gmail.com Fri Jul 3 11: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 3D68228C32B for ; Fri, 3 Jul 2009 11:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 qBNTY7Fl+4r9 for ; Fri, 3 Jul 2009 11:51:20 -0700 (PDT) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 03BC228C32A for ; Fri, 3 Jul 2009 11:51:19 -0700 (PDT) Received: by ewy11 with SMTP id 11so1292651ewy.37 for ; Fri, 03 Jul 2009 11:51:28 -0700 (PDT) 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=ZmQSf8Nmc60Y0YByb8yBJGTZaStlbURoswrZ/QfOEr8=; b=mdhClzlrvtzES2/DojMzmKd6FePc/0FODZwS9vhLnt19rvAZBpgj9Rw72nGznKL4ZQ VXqbGTV7vDRIiTvsIuw4AJXWOX8zhMIi4GjjUyXrZ6abrtGRE0nV5CmZewQK5NL3fVus xUNeXowmm56Rln570O0MfaWjNT4eDNDgS93vY= 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=URZmo4W1XMzr14cbJOgD/tlbmuAww09AKQXKNfzab3mieNc93W4/UaT7fnEHyk4n3V kSAXQW3vzHr2NBDLeJu6Uje9acKE1ZzWb30SkQY+zUH1ekAgk3MJ8ay6YnZYrubNzxXQ OfzpR6fKcfPNeZBcRugmQGyLdY7cnQRC0nhUc= MIME-Version: 1.0 Received: by 10.216.13.194 with SMTP id b44mr445341web.139.1246647088747; Fri, 03 Jul 2009 11:51:28 -0700 (PDT) In-Reply-To: <20090703171647.GJ8620@shinkuro.com> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <200907021000.n62A0qEO032564@ns1.irnic.ir> <7EA5A735-BCFC-410E-8AA7-43950C313036@google.com> <20090703111741.GB8620@shinkuro.com> <20090703171647.GJ8620@shinkuro.com> Date: Fri, 3 Jul 2009 20:51:28 +0200 Message-ID: <6aad7a210907031151p20a0879ay646fe27119e1a401@mail.gmail.com> From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=0016e64c1bbee29390046dd1a44b Cc: Vint Cerf , Arabic Scripts IDNA Subject: Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation 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, 03 Jul 2009 18:51:21 -0000 --0016e64c1bbee29390046dd1a44b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey, There is still a long way before we all understand each other. But some points are very positive. 2009/7/3 Andrew Sullivan > If you happen to have a bunch of root > nameservers that aren't in the IANA root, then you have a different > root. That's all. We have a buch of root, the same namespace, the same caches and the same users. > That's what's happened in the case of the > Internet: to use the technology, everyone has to adjust themselves > some to it even as it has to be adjusted some to everyone. We agree :-) but ICANN is not aware of that :-) > (I think this is one of the central points of Latour's > _Nous n'avons jamais =E9t=E9 modernes_, among others of that set. It's > certainly one of the central points Haraway makes, and I've yet to see > a coherent argument against her position.) I suggest we have a look at these two authors. > > > Anyway, I think we've strayed very far from the point of this > discussion, so I won't indulge more in it. Too bad, you were nearing the core of the point. Next time ? Anyway, this was a very interesting exchange. Thank you both. Portzamparc --0016e64c1bbee29390046dd1a44b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey,
There is still a long way before we all understand each other. B= ut some points are very positive.

2009/7/= 3 Andrew Sullivan <ajs@shinkuro.com>
If you happen to = have a bunch of root
nameservers that aren't in the IANA root, then you have a different
root. =A0That's all.

We have a buch of root, the s= ame namespace, the same caches and the same users.
That's what's happened in the case of the
Internet: to use the technology, everyone has to adjust themselves
some to it even as it has to be adjusted some to everyone.

We agree :-) but ICANN is not aware of that :-)
=A0
=A0(I think this is one of the central points of Latour's
_Nous n'avons jamais =E9t=E9 modernes_, among others of that set. =A0It= 's
certainly one of the central points Haraway makes, and I've yet to see<= br> a coherent argument against her position.)

I suggest w= e have a look at these two authors.


Anyway, I think we've strayed very far from the point of this
discussion, so I won't indulge more in it.

<= /div>Too bad, you were nearing the core of the point. Next time ?

An= yway, this was a very interesting exchange. Thank you both.
Portzamparc<= br> --0016e64c1bbee29390046dd1a44b-- From jefsey@jefsey.com Fri Jul 3 16:07:57 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 E47713A6EBA for ; Fri, 3 Jul 2009 16:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 Jji6loJUYith for ; Fri, 3 Jul 2009 16:07:57 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 244623A6CFE for ; Fri, 3 Jul 2009 16:07:57 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:2007 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MMrrf-0005P9-FJ; Fri, 03 Jul 2009 16:08:20 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Jul 2009 01:08:13 +0200 To: jean-michel bernier de portzamparc , internet users contributing group From: jefsey In-Reply-To: <6aad7a210907031151p20a0879ay646fe27119e1a401@mail.gmail.co m> References: <20090630151238.GB3059@shinkuro.com> <20090701145449.GA4777@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <200907021000.n62A0qEO032564@ns1.irnic.ir> <7EA5A735-BCFC-410E-8AA7-43950C313036@google.com> <20090703111741.GB8620@shinkuro.com> <20090703171647.GJ8620@shinkuro.com> <6aad7a210907031151p20a0879ay646fe27119e1a401@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: <20090703230757.244623A6CFE@core3.amsl.com> Cc: Vint Cerf , Arabic Scripts IDNA Subject: [iucg] Interplus documents review 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, 03 Jul 2009 23:07:58 -0000 At 20:51 03/07/2009, jean-michel bernier de portzamparc wrote: >We have a buch of root, the same namespace, the same caches and the >same users. And the same huge governance problem. Moreover if all of them want to sell their TLDs $ 150.000 a piece. Or to ransom others. Unfortunately ISOC/ICANN/IETF did not want to listen, for so long. And still do not (but at least we talk). So, I suggest that we focus back to the Interplus document. I am going to review it now based upon Margaret's and Michael's contributions, inputs on the wiki, etc. and then to consider the point raised at the IDNABIS that might be interesting to address in it. The main points right now is to decide (due to my delay) if : 1) a generalized communication embryonic global framework (I think about Andrew's and Mark's Internet/Unicode rooted points of view we need to confort and enlarge). It would be introduced in explaining that it would be by no means a model, just a temptative working framework. We could use the france@large "livre blanc" effort. 2) the glossary should be removed now and form a separate document. 3) I try to install the documents concerning "projet.fra" online from the document for the Francophonie before we meet with Marcel this week or after. I copy this mail to the idna-arabicscript mailing list because it transitions from the fruitful discussion we had there. I changed the thread subject, and as suggested by Vint, I invite those interested to continue this on the iucg@ietf.org mailing list - remembering that this list is not a dedicated and paid engineers mailing list, but only a motivated lead users open minded and free speach one. To join : https://www.ietf.org/mailman/listinfo/iucg jfc From eblanconil@gmail.com Fri Jul 3 16:46: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 65A893A6C5F for ; Fri, 3 Jul 2009 16:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9AidnqP7HZT for ; Fri, 3 Jul 2009 16:46:11 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 1A5BB3A6C33 for ; Fri, 3 Jul 2009 16:46:10 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so734841fgg.18 for ; Fri, 03 Jul 2009 16:46:32 -0700 (PDT) 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 :content-transfer-encoding; bh=eAmFYp4hO4X4Ly/JPf4dDLlUmqnR7zDGGGmWvIqGVlk=; b=bnr69yLsecIl9GB01MkQFHXFmbbYbttW0aRtJDfAvKTgMgU0575GEDeYqwOFvPGmSE x6Ao43I5VHr/nQme+OVvhDihhw/LsrO6ZU17ZnUWCzlB4YZP4EF/wFUuMv+rFC4qyTfp B4kto3/e36MkZ0h9fLoFqhjjKyJUTwgIga3eI= 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:content-transfer-encoding; b=vEwNgaShYaGxy1yGpjGRCY6A+Sdp78lYmZZVepHz4M3GsbdrfsDWN5dBoC1qu0YAUX DLrRwKoe+BZ95pVX1Z6XbpH+54XOSf2EkdsAoAL6uNpnesL34zy6s8T/GVfzRflZtAm/ +PQtfoUrIbLfrUBLg+fl64upi3GzCtfpdZk+8= MIME-Version: 1.0 Received: by 10.86.51.20 with SMTP id y20mr1160398fgy.72.1246664791994; Fri, 03 Jul 2009 16:46:31 -0700 (PDT) In-Reply-To: <20090703220002.D19AB3A6A38@core3.amsl.com> References: <20090703220002.D19AB3A6A38@core3.amsl.com> Date: Sat, 4 Jul 2009 01:46:31 +0200 Message-ID: <6589127a0907031646s349faed2w2bf9c8e46ff9f68b@mail.gmail.com> From: Elisabeth Blanconil To: internet users contributing group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idna-update@alvestrand.no Subject: Re: [iucg] I-D Action:draft-ietf-idnabis-mappings-01.txt 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, 03 Jul 2009 23:46:12 -0000 http://wikidna.org/index.php?title=3DIDNA_Mapping has been updated. It seems this new wording is quite interesting. Elisabeth Blanconil 2009/7/4 > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Internationalized Domain Names in Applic= ations (Revised) Working Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Mapping Characters in IDNA > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : P. Resnick, P. Hoffman > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-idnabis-mappings-01.t= xt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-07-03 > > In the original version of the Internationalized Domain Names in > Applications (IDNA) protocol, any Unicode code points taken from user > input were mapped into a set of Unicode code points that "make > sense", which were then encoded and passed to the domain name system > (DNS). =A0The current version of IDNA presumes that the input to the > protocol comes from a set of "permitted" code points, which it then > encodes and passes to the DNS, but does not specify what to do with > the result of user input. =A0This document describes the actions taken > by an implementation between user input and passing permitted code > points to the new IDNA protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idnabis-mappings-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > From mfberny@gmail.com Fri Jul 3 17:05: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 9BFCA28C283 for ; Fri, 3 Jul 2009 17:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 m0y9EoIE0DXX for ; Fri, 3 Jul 2009 17:05:13 -0700 (PDT) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 4D1983A67AA for ; Fri, 3 Jul 2009 17:05:13 -0700 (PDT) Received: by ewy7 with SMTP id 7so78388ewy.37 for ; Fri, 03 Jul 2009 17:03:33 -0700 (PDT) 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=+vBq0FMRNeh6bge6ePcpSjAEz3uwPWP7mo4Imj9JNU0=; b=Dool21SCtd80zDrtX+sHhmEgAHqmEfFEBlhZmkBkO1epHh9fqvlcP4ChNucE/iv8xF lgdOswZSw81FdjOpsw/9cPT+iv5WljjcL43SXFzRys+nGRHZM3ASyLHBZxrRjMtM+rvs 6GP3BK3TF8ZkYYpuezHV0XFfg5bXesTyPzWUw= 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=eFxukAfwM89KGD+M9Pqa7LSTl/xLbMC3rRHezx5fayzddOlqTG9gH3rY08BHIDysO9 iL9PicZCNm3rIFs95U4HqIxMSfE3+S/+yHxl6KO7FIOQAFeAy191l5BQ3lqn7yo6Jibl PTSyP5ed8UnohtaD5WtKjnknzorWDpXIUd3js= MIME-Version: 1.0 Received: by 10.210.69.13 with SMTP id r13mr1652511eba.66.1246665813852; Fri, 03 Jul 2009 17:03:33 -0700 (PDT) In-Reply-To: <20090703230757.244623A6CFE@core3.amsl.com> References: <20090630151238.GB3059@shinkuro.com> <20090701224747.GA6292@shinkuro.com> <200907021000.n62A0qEO032564@ns1.irnic.ir> <7EA5A735-BCFC-410E-8AA7-43950C313036@google.com> <20090703111741.GB8620@shinkuro.com> <20090703171647.GJ8620@shinkuro.com> <6aad7a210907031151p20a0879ay646fe27119e1a401@mail.gmail.com> <20090703230757.244623A6CFE@core3.amsl.com> Date: Sat, 4 Jul 2009 02:03:33 +0200 Message-ID: <58ee45520907031703n757fd1e4kd883a9eb74986c39@mail.gmail.com> From: Marie-France Berny To: internet users contributing group Content-Type: multipart/alternative; boundary=000e0cd1e302fd01ca046dd6001f Cc: Vint Cerf Subject: Re: [iucg] Interplus documents review 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, 04 Jul 2009 00:05:14 -0000 --000e0cd1e302fd01ca046dd6001f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jefsey, it seems it is the friday night fever and everybody is on the bridge to night! 2009/7/4 jefsey > The main points right now is to decide (due to my delay) if : > > 1) a generalized communication embryonic global framework (I think about > Andrew's and Mark's Internet/Unicode rooted points of view we need to > confort and enlarge). It would be introduced in explaining that it would be > by no means a model, just a temptative working framework. We could use the > france@large "livre blanc" effort. That could help to present it this way. - It would make a annoucement of the intended scope (the documents we published last year for ISO TC46 could be a good starter?) - the document on the model could be annouced as the last document. To be based on experience. > > 2) the glossary should be removed now and form a separate document. In the hypothesis above, it could come as part of Interplus and be moved as a document by its own right as new Drafts are issued. > > 3) I try to install the documents concerning "projet.fra" online from the > document for the Francophonie before we meet with Marcel this week or after. Don't rush. Dont get impressed by hurluberlus. Better to get a good job done first (we do not have to come back on it). Let just nominate Krebs for Hurl2009. Marie France Berny --000e0cd1e302fd01ca046dd6001f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey,
it seems it is the friday night fever and everybody is on the br= idge to night!

2009/7/4 jefsey <jefsey@jefsey.com>=
The main points right now is to decide (due to my delay) if :

1) a generalized communication embryonic global framework (I think about An= drew's and Mark's Internet/Unicode rooted points of view we need to= confort and enlarge). It would be introduced in explaining that it would b= e by no means a model, just a temptative working framework. We could use th= e france@large "livre blanc" effort.

That could help to present it this way.
- It would make a anno= ucement of the intended scope (the documents we published last year for ISO= TC46 could be a good starter?)
- the document on the model could be an= nouced as the last document. To be based on experience.

2) the glossary should be removed now and form a separate document.

In the hypothesis above, it could come as part of Interplus a= nd be moved as a document by its own right as new Drafts are issued.

3) I try to install the documents concerning "projet.fra" online = from the document for the Francophonie before we meet with Marcel this week= or after.

Don't rush. Dont get impressed by hurlu= berlus. Better to get a good job done first (we do not have to come back on= it). Let just nominate Krebs for Hurl2009.

Marie France Berny


--000e0cd1e302fd01ca046dd6001f-- From xlegoff@gmail.com Fri Jul 3 17:24:41 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABD73A68B7 for ; Fri, 3 Jul 2009 17:24:41 -0700 (PDT) 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 d+-Kq1B3qXUN for ; Fri, 3 Jul 2009 17:24:40 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id A496D3A687B for ; Fri, 3 Jul 2009 17:24:39 -0700 (PDT) Received: by fxm18 with SMTP id 18so2443221fxm.37 for ; Fri, 03 Jul 2009 17:24:02 -0700 (PDT) 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=xireHIyTXxnf6hnJoQvC9gSPCo33MTyILY24y/btmWw=; b=vMqneBcpoOfeSMi8rQ60fh/pjMhYI5KGr9klK8tg8pUvusxlI523bb/eLAHlguANEQ 6de+ucZccNfiU1Kquqen+X1/2TQNLM4l4lPETFm67kS290mKq/Ucv8cxLHWsGi6LWeN6 EFOs+I2Qz9T2iCNj78cLjp8Mq+y1UfXVBiuDA= 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=c0wZGuTHY9kgKQifGZ2X67IraurZToE0Kfl6ZH7i+2n4COq04GgcbdOUwngSq3JJkA iyAGz2qox4AWtW1iODZbraFD4gAS0ItQPyPXYYgpzZ2AXvUz7TFNZUdu6frm/O3j+cKe pfXt4aVO+Ror8LoBLa6p9j9S8zSGxGM6pHL14= MIME-Version: 1.0 Received: by 10.223.121.208 with SMTP id i16mr1230144far.32.1246667042279; Fri, 03 Jul 2009 17:24:02 -0700 (PDT) In-Reply-To: <58ee45520907031703n757fd1e4kd883a9eb74986c39@mail.gmail.com> References: <20090630151238.GB3059@shinkuro.com> <200907021000.n62A0qEO032564@ns1.irnic.ir> <7EA5A735-BCFC-410E-8AA7-43950C313036@google.com> <20090703111741.GB8620@shinkuro.com> <20090703171647.GJ8620@shinkuro.com> <6aad7a210907031151p20a0879ay646fe27119e1a401@mail.gmail.com> <20090703230757.244623A6CFE@core3.amsl.com> <58ee45520907031703n757fd1e4kd883a9eb74986c39@mail.gmail.com> Date: Sat, 4 Jul 2009 02:24:02 +0200 Message-ID: From: Xavier Legoff To: internet users contributing group Content-Type: multipart/alternative; boundary=001636c5b58f355104046dd64a19 Cc: listegenerale@franceatlarge.org Subject: Re: [iucg] Interplus documents review 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, 04 Jul 2009 00:24:41 -0000 --001636c5b58f355104046dd64a19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Why not to introduce the framework as introduction to a set of RFC 4846 Independent Submissions. This could be a good experiment to add Independent Submissions as the highest form of lead user contribution. This would probably fit well what the IAB said they expected from us. Kenavo. ------------------ Xavier Legoff PS. I do no know if my old friend Vint Cerf wants to receive this so I removed him from the cclist. 2009/7/4 Marie-France Berny > Jefsey, > it seems it is the friday night fever and everybody is on the bridge to > night! > > 2009/7/4 jefsey > >> The main points right now is to decide (due to my delay) if : >> >> 1) a generalized communication embryonic global framework (I think about >> Andrew's and Mark's Internet/Unicode rooted points of view we need to >> confort and enlarge). It would be introduced in explaining that it would be >> by no means a model, just a temptative working framework. We could use the >> france@large "livre blanc" effort. > > > That could help to present it this way. > - It would make a annoucement of the intended scope (the documents we > published last year for ISO TC46 could be a good starter?) > - the document on the model could be annouced as the last document. To be > based on experience. > >> >> 2) the glossary should be removed now and form a separate document. > > > In the hypothesis above, it could come as part of Interplus and be moved as > a document by its own right as new Drafts are issued. > >> >> 3) I try to install the documents concerning "projet.fra" online from the >> document for the Francophonie before we meet with Marcel this week or after. > > > Don't rush. Dont get impressed by hurluberlus. Better to get a good job > done first (we do not have to come back on it). Let just nominate Krebs for > Hurl2009. > > Marie France Berny > > > > _______________________________________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/listinfo/iucg > > --001636c5b58f355104046dd64a19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why not to introduce the framework as introduction to a set of RFC 4846 Ind= ependent Submissions. This could be a good experiment to add Independent Su= bmissions as the highest form of lead user contribution. This would probabl= y fit well what the IAB said they expected from us.

Kenavo.
------------------
Xavier Legoff

PS. I do no know = if my old friend Vint Cerf wants to receive this so I removed him from the = cclist.



2009/7/4 Marie-France Ber= ny <mfberny@gmail= .com>
Jefsey,
it see= ms it is the friday night fever and everybody is on the bridge to night!
2009/7/4 jefsey <jefsey@jefsey.com><= /span>

The main points right now is to decide (due to my delay) if :

1) a generalized communication embryonic global framework (I think about An= drew's and Mark's Internet/Unicode rooted points of view we need to= confort and enlarge). It would be introduced in explaining that it would b= e by no means a model, just a temptative working framework. We could use th= e france@large "livre blanc" effort.

That could help to present it this way.
- It would make = a annoucement of the intended scope (the documents we published last year f= or ISO TC46 could be a good starter?)
- the document on the model could= be annouced as the last document. To be based on experience.

2) the glossary should be removed now and form a separate document.

In the hypothesis above, it could come as part of Inter= plus and be moved as a document by its own right as new Drafts are issued. =

3) I try to install the documents concerning "projet.fra" online = from the document for the Francophonie before we meet with Marcel this week= or after.

Don't rush. Dont get impressed by= hurluberlus. Better to get a good job done first (we do not have to come b= ack on it). Let just nominate Krebs for Hurl2009.

Marie France Berny



_______________________________________________
iucg mailing list
iucg@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/iucg


--001636c5b58f355104046dd64a19-- From jefsey@jefsey.com Sat Jul 4 06:56:32 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 3A3A73A6BC3 for ; Sat, 4 Jul 2009 06:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_63=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 fnfHl4GD2Pkr for ; Sat, 4 Jul 2009 06:56:31 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 87DA73A67F5 for ; Sat, 4 Jul 2009 06:56:31 -0700 (PDT) Received: from 89-158-228-244.rev.dartybox.com ([89.158.228.244]:2751 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MN5jL-0002oT-FP; Sat, 04 Jul 2009 06:56:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Jul 2009 15:50:51 +0200 To: Vint Cerf ,Pete Resnick , Paul Hoffman From: JFC Morfin In-Reply-To: <4B981196-BF5C-4629-A5B1-C4EA5A6384BD@google.com> References: <4B981196-BF5C-4629-A5B1-C4EA5A6384BD@google.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: <20090704135631.87DA73A67F5@core3.amsl.com> Cc: iucg@ietf.org, idna-arabicscript@lists.irnic.ir Subject: Re: [iucg] mappings-01 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, 04 Jul 2009 13:56:32 -0000 At 14:40 04/07/2009, Vint Cerf wrote: >first, major thanks for this new version of the mapping document. > >second, do the two of you have a preference for how this mapping >should be referenced? >Many participants have suggested that the mapping SHOULD be applied >so as to convey the importance of the regularity the document >produces but allowing for circumstances that might justify not >mapping. I would underscore the weight given in IETF terms to >"SHOULD" as one is expected to adhere to the advice and only deviate >for very good reasons. Vint, what every one wants IMHO is network stability, and then flexibility in front of accepted or necessary innovation once it is enough documented. It is well known that I am a fierce opponent to any MUST in here, for that reason. I think the "SHOULDs", with all what this term implies in the IETF context, are adequate. The "very good reasons" I see are cross-technology net neutralility, national sovereignty, IAB approved architectural evolution, RFC 3869 justified opposition to commercial leadership in technical issues. What we need is to be able influence a lasting international culture that protects the IDNA concept in legal, contractual, operational, business, cultural fields. And also in the off-network application area. However, we do not want to carve the today vision of the IDNA into a status-quo that would eventually result in obsolete commercial niches opposing the common interest. I still need to print Pete and Paul's text and read it carefully with france@large, iucg and projet.fra people. Should we disagree with some details we would report them, in full trust. This being said, I fully support "SHOULDs". We need them inorder to reasonably build interoperability on top of IDNA. JFC From mfberny@gmail.com Wed Jul 8 15:16: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 0B7DA3A69DF for ; Wed, 8 Jul 2009 15:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 FPKPQbrs0vGP for ; Wed, 8 Jul 2009 15:16:27 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id AABC93A6836 for ; Wed, 8 Jul 2009 15:16:26 -0700 (PDT) Received: by ewy26 with SMTP id 26so2064489ewy.37 for ; Wed, 08 Jul 2009 15:16:47 -0700 (PDT) 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=sHyZdaUhupUFgEeHXcDuuiLkg6IUfU6VTpTKMq13cK8=; b=LjScAJWO5TpFrAxI79EcdpqZ7zHpZuud8ioh+nwlyRB9256maPBNh94TKfKL1aNNFX hqyjtQE+lokNNLlAQNeQzctV8fGVyDZE8P3527sPSI3LvaAZi6RqZ9bkEUmv4sANpk+f X8NFesL2EV4fhHOxsogmO0UlHoVGJt2zj8SiM= 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=bMWT5eZoU6iHxHNyYjXWbaZggjRtv9Vr1OnvX6g5E+LllL3Isj4N8tkpwkf9801GKa AV/fvY3rcIktdscB73pFxh8n05eb9WG4d8JS0F6fJZPYeba2Q+mUxk7Df63tcejE7p/D S2pYcSfSxTpfcpamOwRGHBuG6YrbFx/URRFFw= MIME-Version: 1.0 Received: by 10.210.30.10 with SMTP id d10mr22010ebd.58.1247091406661; Wed, 08 Jul 2009 15:16:46 -0700 (PDT) In-Reply-To: <30b660a20907081409tf6dd8e2oc5ace54a4c965e26@mail.gmail.com> References: <4A54FB80.6020407@mozilla.org> <30b660a20907081409tf6dd8e2oc5ace54a4c965e26@mail.gmail.com> Date: Thu, 9 Jul 2009 00:16:46 +0200 Message-ID: <58ee45520907081516y3cf0ad5boe195e295c323e13d@mail.gmail.com> From: Marie-France Berny To: Gervase Markham Content-Type: multipart/alternative; boundary=0015174bdc704beb3b046e3918cf Cc: mark@macchiato.com, "idna-update@alvestrand.no" , internet users contributing group Subject: Re: [iucg] Stop me if I've misunderstood... 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, 08 Jul 2009 22:16:30 -0000 --0015174bdc704beb3b046e3918cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gervase, Mark gives a very fair account of the Unicode sub-problem he faces. The sam= e as you gave a very fair account of the UI sub-problem you are concerned about. However, prior to addressing sub-problems we need to address the mai= n problem. The main problem is that: - (1) none of the existing tools sets (browsers, protocols, codes, procedures, applications, IDNA2003, etc. ) is prepared to answer the demand= s of the linguistic diversity. - (2) users (China, Russia, Francophonie, Arabic communities, etc.) have no= w the capacity and the will (after 10 years delay) to support their own aspects of this linguistic diversity by their own. They also distrust/oppos= e the ICANN IDNA strategy. So the issue is simple. We need find the exact level of flexibility in mapping to avoid the end of the Internet either because it becomes chaos (a= s you point it) or because users build their own Internet (like China, etc.). There is a possible consensus in this WG that this depends on the location where the _mappings_ apply (plural depending on the 30.000 linguistic orthotypographies eventually involved). This WG is not chartered to go any further than _permitting_ this flexibility and seems to have made some good work with the mapping document. It should be the reasoning basis for furthe= r orthotyporaphy support, language by language. Orthotypography being now mandatory because of the semantic value given to the DNS, awaiting the semantic addressing. The IUCG, under the france@large leadership, motivated by the inability of the current proposition to correctly support the French orthotypography and the need to support of the Semantic/Semiotic Internet (Intersem), has prepared an architectural extension (Interplus) that enacts (not create) th= e Internet presentation layer in a possibly reasonable manner (everyone can use it the way one want). This permits the user, the browser, the applications to work within a "presentation" without bothering about all th= e currently discussed details. The presentation they use is then related to the rest of the world through a "pseudo-network" layer which make them believe that they relate with a default Internet using the _whole_ Unicode set and any additional semiotic coding they may want to use. Depending on presentation (i.e. character set, language orthotypography, local environemnt, knowledge metastructure, etc.) there will be application and parametering at several layers, including protection against phishing, spamming, etc. However, all this "under the hood" mechanics should be transparent to the user and certified by an authority (ICANN, IANA, his Government, ISOC, his user association, you name it) he/she trusts and others will watch and criticize in order to protect interoperability and interintelligibility. The interest of this approach is that it will only require the design and development of something very comparable to a firewall and absolutely no change in the existing Internet, that ISP could even deploy on their side o= f their Internet connexion. This is something many ISPs round the world, are already used to - for example to support Chinese names. I hope this helps. Marie-France Berny 2009/7/8 Mark Davis =E2=8C=9B > That is, in fact, the current outcome, because of two issues: > > 1. There are 4 characters that are valid in both IDNA2003 and IDNA2008= , > but will direct to to different IP addresses. So if you send a friend = a URL, > he could end up going to a different site, if you have different brows= ers or > different browser versions. > 2. There is a proposal to add a mapping to IDNAbis that would be "UI > only", and optional. This is to handle user-expected variant differenc= es: > case, width,... That would also end up with problems with "bus-ability= " in > that whether a URL gets mapped is left up to the user-agent's choice, = and > what it thinks qualifies as "UI", and even whether the mapping is chan= ged > (the mapping is a SHOULD). And there is no current requirement that th= e > mapping be compatible with IDNA2003, so we get the same problem as #1. > > My opinion: > > This is a rather bad situation -- for interoperability and security, let > alone the user experience -- but that people in this group just don't > realize it yet because they haven't gotten enough feedback from people wh= o > are concerned with interoperability and security. In particular, I believ= e > that: > > 1. We should have differences from the current state (IDNA2003) that > cause a URL to go to a different site *only* if there is overwhelming > justification and little negative impact. > 1. There is convincing evidence that this divergence is necessary > for two characters: ZWJ, and ZWNJ. Fortunately these are extremely = low > frequency characters in current URLs within web pages, so the negat= ive > impact is quite limited. > 2. There is not overwhelming justification for the two others: > es-zett (sharp S) and final sigma. As a matter of fact, the German = NIC has > come out against the former. We do not have enough involvement from= the > Greek community to have any real case for the latter. And these are > extremely frequent characters in the respective language communitie= s. > 2. We should have a mandatory mapping applied to all lookup (whethe= r > "UI" or not "UI"), whereby for any cases where IDNA2003 also maps, the= y must > have the same result. Failing that, we should not provide any mapping = in > IDNA. > > Mark > > > > On Wed, Jul 8, 2009 at 13:03, Gervase Markham wrote: > >> I must confess that I've not had time recently to follow carefully the >> discussions about mappings. If that means that some people consign this >> message to the bit bucket, so be it. >> >> At the moment, standard domain names have what I'll call "bus-ability" - >> that is, if you see them in an advert on the side of a bus, you can >> write them down, type them into any web browser or other domain >> name-using client later, and you'll end up at the place intended by the >> creator of the advertisement. IDN domain names under the current version >> of IDN have, as far as I understand it, pretty much the same >> "bus-ability" property. In the IDN case, what the user types has to be >> first normalized, and then converted to punycode. The user in no way >> needs to know or care about this extra technical complexity. It just >> works. >> >> I would assert that this property is pretty key to keeping the web >> working in a sane and, importantly, secure manner. People convert domain >> names from print/voice/memory to computer and back all the time. >> >> If the standards were to change in such a way that it becomes quite >> legal and conforming that typing a set of characters into browser A >> takes you to website Q, but typing the same set into browser B takes you >> to website R, I would politely suggest that those who wrote the new >> standards had taken leave of their senses. This is a recipe for chaos. >> And phishing. >> >> This incredible outcome is not a serious possibility, is it? >> >> Gerv >> _______________________________________________ >> 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 > > --0015174bdc704beb3b046e3918cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gervase,
Mark gives a very fair account of the Unicode sub-problem he fa= ces. The same as you gave a very fair account of the UI sub-problem you are= concerned about. However, prior to addressing sub-problems we need to addr= ess the main problem. The main problem is that:

- (1) none of the existing tools sets (browsers, protocols, codes, proc= edures, applications, IDNA2003, etc. ) is prepared to answer the demands of= the linguistic diversity.
- (2) users (China, Russia, Francophonie, Ar= abic communities, etc.) have now the capacity and the will (after 10 years = delay) to support their own aspects of this linguistic diversity by their o= wn. They also distrust/oppose the ICANN IDNA strategy.

So the issue is simple. We need find the exact level of flexibility in = mapping to avoid the end of the Internet either because it becomes chaos (a= s you point it) or because users build their own Internet (like China, etc.= ). There is a possible consensus in this WG that this depends on the locati= on where the _mappings_ apply (plural depending on the 30.000 linguistic or= thotypographies eventually involved). This WG is not chartered to go any fu= rther than _permitting_ this flexibility and seems to have made some good w= ork with the mapping document. It should be the reasoning basis for further= orthotyporaphy support, language by language. Orthotypography being now ma= ndatory because of the semantic value given to the DNS, awaiting the semant= ic addressing.

The IUCG, under the france@large leadership, motivated by the inability= of the current proposition to correctly support the French orthotypography= and the need to support of the Semantic/Semiotic Internet (Intersem), has = prepared an architectural extension (Interplus) that enacts (not create) th= e Internet presentation layer in a possibly reasonable manner (everyone can= use it the way one want). This permits the user, the browser, the applicat= ions to work within a "presentation" without bothering about all = the currently discussed details. The presentation they use is then related = to the rest of the world through a "pseudo-network" layer which m= ake them believe that they relate with a default Internet using the _whole_= Unicode set and any additional semiotic coding they may want to use.

Depending on presentation (i.e. character set, language orthotypography= , local environemnt, knowledge metastructure, etc.) there will be applicati= on and parametering at several layers, including protection against phishin= g, spamming, etc. However, all this "under the hood" mechanics sh= ould be transparent to the user and certified by an authority (ICANN, IANA,= his Government, ISOC, his user association, you name it) he/she trusts and= others will watch and criticize in order to protect interoperability and i= nterintelligibility.

The interest of this approach is that it will only require the design a= nd development of something very comparable to a firewall and absolutely no= change in the existing Internet, that ISP could even deploy on their side = of their Internet connexion. This is something many ISPs round the world, a= re already used to - for example to support Chinese names.

I hope this helps.
Marie-France Berny




2009/7/8 Mark Davis =E2=8C=9B <mark@macchiato.com>
That is, in fact, the current outcome, because of two issues:
  1. Th= ere are 4 characters that are valid in both IDNA2003 and IDNA2008, but will= direct to to different IP addresses. So if you send a friend a URL, he cou= ld end up going to a different site, if you have different browsers or diff= erent browser versions.
  2. There is a proposal to add a mapping to IDNAbis that would be "UI = only", and optional. This is to handle user-expected variant differenc= es: case, width,... That would also end up with problems with "bus-abi= lity" in that whether a URL gets mapped is left up to the user-agent&#= 39;s choice, and what it thinks qualifies as "UI", and even wheth= er the mapping is changed (the mapping is a SHOULD). And there is no curren= t requirement that the mapping be compatible with IDNA2003, so we get the s= ame problem as #1.
My opinion:

This is a rather bad situation -- for interope= rability and security, let alone the user experience -- but that people in = this group just don't realize it yet because they haven't gotten en= ough feedback from people who are concerned with interoperability and secur= ity. In particular, I believe that:
  1. We should have differences from the current state (IDNA2003) that c= ause a URL to go to a different site *only* if there is overwhelming justif= ication and little negative impact.
    1. There is convincing evidenc= e that this divergence is necessary for two characters: ZWJ, and ZWNJ. Fortunately these are extremely low frequency characters in current URLs within web pag= es, so the negative impact is quite limited.
    2. There is not overw= helming justification for the two others: es-zett (sharp S) and final sigma. As a matter of fact, the German NIC has come out against the former. We do not have enough involvement from the Greek co= mmunity to have any real case for the latter. And these are extremely frequ= ent characters in the respective language communities.
  2. We should have a mandatory mapping applied to all lookup (whether "UI&= quot; or not "UI"), whereby for any cases where IDNA2003 also map= s, they must have the same result. Failing that, we should not provide any = mapping in IDNA.
Mark



On Wed, Jul 8, 2009 at 13:03, Gervase Ma= rkham <gerv@mozilla.org> wrote:
I must confess that I've not had time recently to follow carefully the<= br> discussions about mappings. If that means that some people consign this
message to the bit bucket, so be it.

At the moment, standard domain names have what I'll call "bus-abil= ity" -
that is, if you see them in an advert on the side of a bus, you can
write them down, type them into any web browser or other domain
name-using client later, and you'll end up at the place intended by the=
creator of the advertisement. IDN domain names under the current version of IDN have, as far as I understand it, pretty much the same
"bus-ability" property. In the IDN case, what the user types has = to be
first normalized, and then converted to punycode. The user in no way
needs to know or care about this extra technical complexity. It just works.=

I would assert that this property is pretty key to keeping the web
working in a sane and, importantly, secure manner. People convert domain names from print/voice/memory to computer and back all the time.

If the standards were to change in such a way that it becomes quite
legal and conforming that typing a set of characters into browser A
takes you to website Q, but typing the same set into browser B takes you to website R, I would politely suggest that those who wrote the new
standards had taken leave of their senses. This is a recipe for chaos.
And phishing.

This incredible outcome is not a serious possibility, is it?

Gerv
_______________________________________________
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


--0015174bdc704beb3b046e3918cf-- From jefsey@jefsey.com Wed Jul 8 16: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 246243A6AAB for ; Wed, 8 Jul 2009 16:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ontOPP+6CwKJ for ; Wed, 8 Jul 2009 16:46:45 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 5A0343A686C for ; Wed, 8 Jul 2009 16:46:45 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:3916 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MOgr0-0002yk-5h; Wed, 08 Jul 2009 16:47:11 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Jul 2009 01:46:34 +0200 To: internet users contributing group , Gervase Markham From: JFC Morfin In-Reply-To: <58ee45520907081516y3cf0ad5boe195e295c323e13d@mail.gmail.co m> References: <4A54FB80.6020407@mozilla.org> <30b660a20907081409tf6dd8e2oc5ace54a4c965e26@mail.gmail.com> <58ee45520907081516y3cf0ad5boe195e295c323e13d@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: <20090708234645.5A0343A686C@core3.amsl.com> Cc: mark@macchiato.com, internet users contributing group , Arabic Scripts IDNA Subject: Re: [iucg] Stop me if I've misunderstood... 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, 08 Jul 2009 23:46:46 -0000 Ouahou! Marie-France what a summary! Let me add a few comments : At 00:16 09/07/2009, Marie-France Berny wrote: >It should be the reasoning basis for further orthotyporaphy support, >language by language. Orthotypography being now mandatory because of >the semantic value given to the DNS, awaiting the semantic addressing. You can say that orthotypography is advisable, not mandatory. This is not a part of their Charter. >The IUCG, under the france@large leadership, motivated by the >inability of the current proposition to correctly support the French >orthotypography and the need to support of the Semantic/Semiotic >Internet (Intersem), has prepared an architectural extension >(Interplus) that enacts (not create) the Internet presentation layer >in a possibly reasonable manner (everyone can use it the way one want). You mean that everyone else can use the Internet presentation layer the way he wants and create havoc if this is not coordinated. >This permits the user, the browser, the applications to work within >a "presentation" without bothering about all the currently discussed >details. The presentation they use is then related to the rest of >the world through a "pseudo-network" layer which make them believe >that they relate with a default Internet using the _whole_ Unicode >set and any additional semiotic coding they may want to use. This is a part in Pete's document that seems to create a problem to Mark. May be the best way to make this understood is to suggest participants to think about the Microsoft Natal product and how it will relate with the DNS. In the same way as IDNA, but not through Unicode. jfc From gerv@mozilla.org Thu Jul 9 03:55: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 746E73A6832 for ; Thu, 9 Jul 2009 03:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-P1K2NYWxOY for ; Thu, 9 Jul 2009 03:55:53 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by core3.amsl.com (Postfix) with ESMTP id 97B723A6829 for ; Thu, 9 Jul 2009 03:55:53 -0700 (PDT) Received: from 78-105-22-247.zone3.bethere.co.uk ([78.105.22.247] helo=[192.168.2.90]) by balrog.mythic-beasts.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MOrIT-000054-UO; Thu, 09 Jul 2009 11:56:19 +0100 Message-ID: <4A55CCC7.60800@mozilla.org> Date: Thu, 09 Jul 2009 11:56:07 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1pre) Gecko/20090706 Shredder/3.0b3pre MIME-Version: 1.0 To: Marie-France Berny References: <4A54FB80.6020407@mozilla.org> <30b660a20907081409tf6dd8e2oc5ace54a4c965e26@mail.gmail.com> <58ee45520907081516y3cf0ad5boe195e295c323e13d@mail.gmail.com> In-Reply-To: <58ee45520907081516y3cf0ad5boe195e295c323e13d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BlackCat-Spam-Score: 3 X-Mailman-Approved-At: Thu, 09 Jul 2009 05:31:08 -0700 Cc: mark@macchiato.com, "idna-update@alvestrand.no" , internet users contributing group Subject: Re: [iucg] Stop me if I've misunderstood... 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, 09 Jul 2009 10:57:48 -0000 On 08/07/09 23:16, Marie-France Berny wrote: > Gervase, > Mark gives a very fair account of the Unicode sub-problem he faces. The > same as you gave a very fair account of the UI sub-problem you are > concerned about. However, prior to addressing sub-problems we need to > address the main problem. The main problem is that: > > - (1) none of the existing tools sets (browsers, protocols, codes, > procedures, applications, IDNA2003, etc. ) is prepared to answer the > demands of the linguistic diversity. I know little of ICANN politics or the relationship of your group to them, the IETF, or any other organization whose acronym begins with an I, but it seems self-evident to me that the above is not "the main problem", at least not for this group. We are not here to boil the sea. Life is imperfect. Unicode is imperfect. The DNS is not capable of representing all words in Latin-script languages, let alone words in all the other scripts. I can't have www.O'Markham.org. If there is an expectation from some language communities that every single word they can think of to type in can become a valid and different domain name, then they will be disappointed, just as the English and other Latin-using language communities have been for the past 30+ years. If that makes them go off and form a separate Internet, there's little we can do about it apart from tell them they have unrealistic expectations. Gerv From mfberny@gmail.com Thu Jul 9 06:09: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 E24B728C1C7 for ; Thu, 9 Jul 2009 06:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 x4O+QrqnQ5go for ; Thu, 9 Jul 2009 06:09:14 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 3622828C1CD for ; Thu, 9 Jul 2009 06:08:52 -0700 (PDT) Received: by ewy26 with SMTP id 26so176658ewy.37 for ; Thu, 09 Jul 2009 06:09:17 -0700 (PDT) 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=FmmWv1r4O4fpSHmtEujhx/dBXhAE0MhDrSberb0ok/4=; b=c8iC2qBjMQco39LsjXZGTkMOxcfUi40h2ko4AQW7DWxLc4gFXGVVF0jTIFSKlM1enb i8GCndopTWHvfrOnKmnypxS+ITZeXuauDHQ94vS2sS53t0+fY3hvAgYP6c/Z+fL53L+x pr+MUVxJ2ohct+OHKUfbkyc8PLwfyc2qBigtk= 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=yD3/ojqV1NlXjj5FMkVzZ/e/wqauIJu8Dmsk0YSqeK6yiEEeLvSVPXoJcyn62C5jjS OnquutXtqwuI1woSIn+baOIdP1Z3ImDW1SzDO69d2emcUXlKbpX8kkuvZSuS7dgvxBWO D+zc+T5TaLhTs0pW/90gOkXAGZ7fNiiX/43W8= MIME-Version: 1.0 Received: by 10.210.82.2 with SMTP id f2mr973582ebb.2.1247144957035; Thu, 09 Jul 2009 06:09:17 -0700 (PDT) In-Reply-To: <4A55CCC7.60800@mozilla.org> References: <4A54FB80.6020407@mozilla.org> <30b660a20907081409tf6dd8e2oc5ace54a4c965e26@mail.gmail.com> <58ee45520907081516y3cf0ad5boe195e295c323e13d@mail.gmail.com> <4A55CCC7.60800@mozilla.org> Date: Thu, 9 Jul 2009 15:09:17 +0200 Message-ID: <58ee45520907090609tfa68c8fy789ea28e9f271c07@mail.gmail.com> From: Marie-France Berny To: Gervase Markham Content-Type: multipart/alternative; boundary=0015174c40b025c9ea046e45901f Cc: mark@macchiato.com, "idna-update@alvestrand.no" , internet users contributing group Subject: Re: [iucg] Stop me if I've misunderstood... 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, 09 Jul 2009 13:09:16 -0000 --0015174c40b025c9ea046e45901f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gervase, your questions are a repetition. Your broadside of points is an excellent way for us to check our positions. Thank you. You definitly are an "IETF user" like us (IUCG stands for Internet users contributing group). We take "users" as Internet and RFC lead users. In initating the IUCG, the initial idea was to limit ourselves to inputs and comments. The IAB asked us more so they could discuss with us over formated inputs. This is in line with RFC 3935 which says that "The IETF has traditionally been a community for experimentation with things that are not fully understood, standardization of protocols for which some understanding has been reached, and publication of (and refinement of) protocols originally specified outside the IETF process." We take that our job also as to specify protocols in _parallel_ to the IETF process, in the hope it could speed up the internal as well as the external process. We do not feel at ease with the "acquisition" of the IETF by ISOC (this is the way we read some of the ISOC documents to their sponsoring members). We consider ICANN as an interesting source of (good and bad) experience in the "IN" class and default ASCII presentation. 2009/7/9 Gervase Markham > On 08/07/09 23:16, Marie-France Berny wrote: > >> Gervase, >> Mark gives a very fair account of the Unicode sub-problem he faces. The >> same as you gave a very fair account of the UI sub-problem you are >> concerned about. However, prior to addressing sub-problems we need to >> address the main problem. The main problem is that: >> >> - (1) none of the existing tools sets (browsers, protocols, codes, >> procedures, applications, IDNA2003, etc. ) is prepared to answer the >> demands of the linguistic diversity. >> > > I know little of ICANN politics or the relationship of your group to them, > the IETF, or any other organization whose acronym begins with an I, but it > seems self-evident to me that the above is not "the main problem", at least > not for this group. This is correct as the main problem I explained is not point (1) or (2) but the conjunction of both. > We are not here to boil the sea. Correct but as you may know the global warming takes care of it. And we must cope with it. Life is imperfect. Unicode is imperfect. The DNS is not capable of > representing all words in Latin-script languages, let alone words in all the > other scripts. I can't have www.O'Markham.org. Dear, why would you not ??? This is precisely the purpose of IDNA. Why would the Scottish language be limited by IDNA? > If there is an expectation from some language communities that every single > word they can think of to type in can become a valid and different domain > name, then they will be disappointed, just as the English and other > Latin-using language communities have been for the past 30+ years. I am afraid you confuse disapointment in the Internet and disapointment in the Internet standards and ICANN commercial management. This kind of self-imposed technical and R&D limitations on commercial grounds is chastised in the IAB RFC 3869. > If that makes them go off and form a separate Internet, there's little we > can do about it apart from tell them they have unrealistic expectations. The problem is not that one. The problem is how realistic is it to behave as if the rest of the world could not circumvent this IETF imposed disappointment. While we are documenting it. It will be a Draft as soon as we understand how to port our bilingual wiki document under an RFC-Editor acceptable entry in unsing XML2RFC. Take care. Marie-France Berny --0015174c40b025c9ea046e45901f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gervase,
your questions are a repetition. Your broadside of points is an= excellent way for us to check our positions. Thank you. You definitly are = an "IETF user" like us (IUCG stands for Internet users contributi= ng group). We take "users" as Internet and RFC lead users.

In initating the IUCG, the initial idea was to limit ourselves to input= s and comments. The IAB asked us more so they could discuss with us over fo= rmated inputs. This is in line with RFC 3935 which says that "The IETF= has traditionally been a community for experimentation with things that ar= e not fully understood, standardization of protocols for which some underst= anding has been reached, and publication of (and refinement of) protocols o= riginally specified outside the IETF process." We take that our job al= so as to specify protocols in _parallel_ to the IETF process, in the hope i= t could speed up the internal as well as the external process.

We do not feel at ease with the "acquisition" of the IETF by = ISOC (this is the way we read some of the ISOC documents to their sponsorin= g members). We consider ICANN as an interesting source of (good and bad) ex= perience in the "IN" class and default ASCII presentation.

2009/7/9 Gervase Markham &= lt;gerv@mozilla.org>
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 08/07/09 23:16, Marie-France Berny wrote:
Gervase,
Mark gives a very fair account of the Unicode sub-problem he faces. The
same as you gave a very fair account of the UI sub-problem you are
concerned about. However, prior to addressing sub-problems we need to
address the main problem. The main problem is that:

- (1) none of the existing tools sets (browsers, protocols, codes,
procedures, applications, IDNA2003, etc. ) is prepared to answer the
demands of the linguistic diversity.

I know little of ICANN politics or the relationship of your group to them, = the IETF, or any other organization whose acronym begins with an I, but it = seems self-evident to me that the above is not "the main problem"= , at least not for this group.

This is correct as the main problem I explained is not point (1) o= r (2) but the conjunction of both.
=A0
We are not here to boil the sea.

Correct but as you ma= y know the global warming takes care of it. And we must cope with it.
<= br>
Life is imperfect. Unicode is imperfect. The DNS is not capable of represen= ting all words in Latin-script languages, let alone words in all the other = scripts. I can't have www.O'Markham.org.

Dear, why would you not ??? This is precisely the purpose of IDNA. Why woul= d the Scottish language be limited by IDNA?
=A0
If there is an expectation from some language communities that every single= word they can think of to type in can become a valid and different domain = name, then they will be disappointed, just as the English and other Latin-u= sing language communities have been for the past 30+ years.

I am afraid you confuse disapointment in the Internet and disapoin= tment in the Internet standards and ICANN commercial management. This kind = of self-imposed technical and R&D limitations on commercial grounds is = chastised in the IAB RFC 3869.
=A0
If t= hat makes them go off and form a separate Internet, there's little we c= an do about it apart from tell them they have unrealistic expectations.

The problem is not that one. The problem is how realistic is it to= behave as if the rest of the world could not circumvent this IETF imposed = disappointment. While we are documenting it. It will be a Draft as soon as = we understand how to port our bilingual wiki document under an RFC-Editor a= cceptable entry in unsing XML2RFC.

Take care.
Marie-France Berny

--0015174c40b025c9ea046e45901f-- From jefsey@jefsey.com Thu Jul 9 17:35:23 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 A93393A6CCE for ; Thu, 9 Jul 2009 17:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 gwWuMYgx4flh for ; Thu, 9 Jul 2009 17:35:22 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 582FB3A6AD3 for ; Thu, 9 Jul 2009 17:35:22 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:3434 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MP45W-0004C8-2p; Thu, 09 Jul 2009 17:35:42 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Jul 2009 02:35:40 +0200 To: iucg@ietf.org From: jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_175712687==.ALT" 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: <20090710003522.582FB3A6AD3@core3.amsl.com> Cc: listegenerale@franceatlarge.org, housley@vigilsec.com, Vint Cerf , Lisa Dusseault , arabic Scripts IDNA Subject: [iucg] call for suggestions - october concertation meeting 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, 10 Jul 2009 00:35:23 -0000 --=====================_175712687==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear friends, Further to different discussions introduced/held/closed this week, I suggest that we stop being overly involved in the WG-IDNABIS and ASIWG. They now have perfectly identified the point at stake and we must consider how to best contribute to what has become a debate over different opinions. We will only confuse them all in calling on concepts that they have not yet investigated and that are out of their Charter (they need, however, to shape the Internet in the Charter's area so that it can cope with the coming semiotic tide that we have started investigating). IETF must decide if IDNA stand for Integrated, Internationalized, Internet Domain Names. IMHO, only full scale real life testing can truly help in establishing a better understanding of where we stand. However, testing in turn calls for a test-bed and a clear project and, therefore, clear documentation. 1. our basic response to the IDNA level of concerns is online: http://iucg.org/wiki/Interplus. In our ISO like format. We will most probably publish it at least as a glossary along with the interplus document. 2. we are experimenting difficulties with my conversion tool from wiki to xml2rfc. I just decided to redevelop a direct I_D text production tool. This may take a few weeks, though, because I will try to support several formats, and because I will be on vacations. 3. we are currently preparing a working framework for a submission set, in order to document the path "from the Internet, to the Internet Plus, to the multilingual Intersem". This document will probably require a few months to complete as it will be kept in tune with the preparation of the various documents as they are being developed. In which, it will also serve as an executive summary. The submissions should concern the intersem, semantic addressing system, polynym metastructure, intertest to ensure that the real-life testing (technology and governance) does not interfere with daily traffic, a global semiotic approach, the technical formalization of commercial as well as private spheres and built-in micropayment, the much needed glossary, etc. no to speak of the much necessary underlaying research on linguistic, metatechnic, ethitechnic, anthrobotic sociology, governance methodology, facilitation reasoning, etc. So, it will there is a big task ahead. I suspect it will not be a lead user lead topic for a long and that a reticular semantician community may develop. 4. We plan, according to the IETF standardization rules, to deploy two major running projects along this plan: - "projet.fra" for a French language open ontology that shall use its own extended namespace (semantic addressing) as its open taxonomy - "multilinc", for African languages - in this case, we plan to progressively publish a guide on the way to port a language, as well as a culture, on the intersem. 5. Our main concern is that the existing Internet's possibilities, which we may activate/unleash, could result in new governance, adminance (technical and administrative governance), and network economy evolution challenges. We, therefore, should be rather careful and liaise with all the concerned international organizations (UNESCO, ITU, WSIS, ISO, ICANN, IAB, EU, MINC, MAAYA, OECD, ASIWG, etc.) in order to keep them well informed. This is why I hereby suggest that we consider an open IUCG "Intersem preparation" concertation meeting to be held in early October in Versailles. As the MLTF used to. Have great and studious vacations. jfc --=====================_175712687==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
Dear friends,

Further to different discussions introduced/held/closed this week, I suggest that we stop being overly involved in the WG-IDNABIS and ASIWG. They now have perfectly identified the point at stake and we must consider how to best contribute to what has become a debate over different opinions. We will only confuse them all in calling on concepts that they have not yet investigated and that are out of their Charter (they need, however, to shape the Internet in the Charter's area so that it can cope with the coming semiotic tide that we have started investigating).

IETF must decide if IDNA stand for Integrated, Internationalized, Internet Domain Names. IMHO, only full scale real life testing can truly help in establishing a better understanding of where we stand. However, testing in turn calls for a test-bed and a clear project and, therefore, clear documentation.

1. our basic response to the IDNA level of concerns is online: http://iucg.org/wiki/Interplus. In our ISO like format. We will most probably publish it at least as a glossary along with the interplus document.

2. we are experimenting difficulties with my conversion tool from wiki to xml2rfc. I just decided to redevelop a direct I_D text production tool. This may take a few weeks, though, because I will try to support several formats, and because I will be on vacations.

3. we are currently preparing a working framework for a submission set, in order to document the path "from the Internet, to the Internet Plus, to the multilingual Intersem". This document will probably require a few months to complete as it will be kept in tune with the preparation of the various documents as they are being developed. In which, it will also serve as an executive summary. The submissions should concern the intersem, semantic addressing system, polynym metastructure, intertest to ensure that the real-life testing (technology and governance) does not interfere with daily traffic, a global semiotic approach, the technical formalization of commercial as well as private spheres and built-in micropayment, the much needed glossary, etc. no to speak of the much necessary underlaying research on linguistic, metatechnic, ethitechnic, anthrobotic sociology, governance methodology, facilitation reasoning, etc. So, it will there is a big task ahead. I suspect it will not be a lead user lead topic for a long and that a reticular semantician community may develop.

4. We plan, according to the IETF standardization rules, to deploy two major running projects along this plan:

-  "projet.fra" for a French language open ontology that shall use its own extended namespace (semantic addressing) as its open taxonomy
-  "multilinc", for African languages - in this case, we plan to progressively publish a guide on the way to port a language, as well as a culture, on the intersem.

5. Our main concern is that the existing Internet’s possibilities, which we may activate/unleash, could result in new governance, adminance (technical and administrative governance), and network economy evolution challenges. We, therefore, should be rather careful and  liaise with all the concerned international organizations (UNESCO, ITU, WSIS, ISO, ICANN, IAB, EU, MINC, MAAYA, OECD, ASIWG, etc.) in order to keep them well informed.

This is why I hereby suggest that we consider an open IUCG "Intersem preparation" concertation meeting to be held in early October in Versailles. As the MLTF used to.

Have great and studious vacations.

jfc
--=====================_175712687==.ALT-- From jefsey@jefsey.com Fri Jul 10 15:34:47 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 A324928C3DD for ; Fri, 10 Jul 2009 15:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oiaWwfnvEEvM for ; Fri, 10 Jul 2009 15:34:46 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 9443228C3DE for ; Fri, 10 Jul 2009 15:34:16 -0700 (PDT) Received: from eurolab.net2.nerim.net ([213.41.175.161]:2973 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MPOfy-0008Vd-S3; Fri, 10 Jul 2009 15:34:43 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Jul 2009 00:34:18 +0200 To: iucg@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: <20090710223416.9443228C3DE@core3.amsl.com> X-Mailman-Approved-At: Fri, 10 Jul 2009 16:35:18 -0700 Cc: Shawn Steele , Paul Hoffman , Mark Davis , John C Klensin , Lisa Dusseault , Ram Mohan , Pete Resnick , Gervase Markham , vint Cerf , Andrew Sullivan Subject: [iucg] please don't 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, 10 Jul 2009 22:34:47 -0000 Dear IUCG participants, I strongly advise you not to keep involving yourselves into the current WG-IDNABIS debate, moreover using material we work on for a different purpose. This debate is now very well documented by IETF leaders explaining the point at hand in ways that other long time IETF participants can understand. This may certainly seem boring, or even deeply hurting, or childish to you when all the participants are English mother tongue engineers, give you the feeling they decide for the other 29.999 natural languages, or pretend to speak your own language better than you, specially when you are an high level academic, are from other communities, etc.. However .... You have to accept that this is a long standing IETF debate, not a young IUCG debate. IETF is part of the Internet architecture. Its English is part of the IETF. In addition some participants who are involved today are actually new to the debate. We must not confuse them with points they never considered yet. Let give them time to bring themselves up to speed. If they join the debate it is because they feel it has reached an important point. Please also remember two basic rules: "don't feed the troll" - "don't feed competition either". We have made our point for the records (IAB, IESG, IETF/LC). As being lead users with a proposition: - we 100% agree with the Charter, - we respect every contributor's experience in the current engineering debate (linguistic, orthotypographic issue are now over, as long as their support is not blocked/disregarded) - we support the forming rough consensus, - we certainly welcome the UI layer concept as an open field to application developpers (including open source) - we contributed in explaining how and what we will build on top of the current experience in 100%, respecting and protecting the currents DNS and Internet - how we plan two real life, full size, test projects in order to get experience about some of the questions being raised and to validate our proposition - we intend to carry these projects along rules we will submit to the community. As Vint advised, discussions on Interplus, Internet Plus, and Intersem should be on a separate list. Now there is no more opposition with the WG, such a list will not appear as competition to IDNA. The document framework I introduced the idea yesterday will also serve as a charter for such a list. Once this document is drafted, I will start such a list and invite everyone who could be interested on a personnal basis. I am on vacations tonight and I plan to develop a wiki-to-draft formater, have a look to Haraway and Wittegeinstein, refresh wome of my maths, review the Interplus pages, relax and think over fundamentals of semiotics/semantics. Let wish the IETF to get a good IDNA2008 document set, with a coherent and structured vision of mapping strategy - from user, application, IDNA, etc. down to the DNS. Best jfc From dunham@vjf.cnrs.fr Sat Jul 11 01:43:35 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 6AC7B3A6B62 for ; Sat, 11 Jul 2009 01:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 UHKRb7z4OZJc for ; Sat, 11 Jul 2009 01:43:34 -0700 (PDT) Received: from smtp.vjf.cnrs.fr (smtp.vjf.cnrs.fr [193.49.17.116]) by core3.amsl.com (Postfix) with ESMTP id D7E433A6AAE for ; Sat, 11 Jul 2009 01:43:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.vjf.cnrs.fr (Postfix) with ESMTP id 912E18340D6; Sat, 11 Jul 2009 10:43:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at vjf.cnrs.fr Received: from smtp.vjf.cnrs.fr ([127.0.0.1]) by localhost (smtp.vjf.cnrs.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2krFb8K+ZUDH; Sat, 11 Jul 2009 10:43:58 +0200 (CEST) Received: from www.vjf.cnrs.fr (newhttpd.vjf.cnrs.fr [193.49.17.120]) by smtp.vjf.cnrs.fr (Postfix) with ESMTP id 675058340D0; Sat, 11 Jul 2009 10:43:58 +0200 (CEST) Received: from 90.57.179.197 (SquirrelMail authenticated user dunham) by www.vjf.cnrs.fr with HTTP; Sat, 11 Jul 2009 10:43:58 +0200 Message-ID: In-Reply-To: <20090710003609.8792B8340B2@smtp.vjf.cnrs.fr> References: <20090710003609.8792B8340B2@smtp.vjf.cnrs.fr> Date: Sat, 11 Jul 2009 10:43:58 +0200 From: "Margaret Dunham" To: "jefsey" User-Agent: SquirrelMail/1.4.19-1.fc10 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: listegenerale@franceatlarge.org, housley@vigilsec.com, iucg@ietf.org, Lisa Dusseault , Vint Cerf , arabic Scripts IDNA Subject: Re: [iucg] [listegenerale] call for suggestions - october concertation meeting X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dunham@vjf.cnrs.fr, 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, 11 Jul 2009 08:43:35 -0000 Dear Jefsey, A concertation meeting sounds like a very good idea. Personally, the morning of Saturday 3 October would suit me perfectly. Enjoy your well earned vacation! Margaret Le Ven 10 juillet 2009 02:35, jefsey a écrit : > > Dear friends, > > Further to different discussions introduced/held/closed this week, I > suggest that we stop being overly involved in the WG-IDNABIS and > ASIWG. They now have perfectly identified the point at stake and we > must consider how to best contribute to what has become a debate over > different opinions. We will only confuse them all in calling on > concepts that they have not yet investigated and that are out of > their Charter (they need, however, to shape the Internet in the > Charter's area so that it can cope with the coming semiotic tide that > we have started investigating). > > IETF must decide if IDNA stand for Integrated, Internationalized, > Internet Domain Names. IMHO, only full scale real life testing can > truly help in establishing a better understanding of where we stand. > However, testing in turn calls for a test-bed and a clear project > and, therefore, clear documentation. > > 1. our basic response to the IDNA level of concerns is online: > http://iucg.org/wiki/Interplus. In > our ISO like format. We will most probably publish it at least as a > glossary along with the interplus document. > > 2. we are experimenting difficulties with my conversion tool from > wiki to xml2rfc. I just decided to redevelop a direct I_D text > production tool. This may take a few weeks, though, because I will > try to support several formats, and because I will be on vacations. > > 3. we are currently preparing a working framework for a submission > set, in order to document the path "from the Internet, to the > Internet Plus, to the multilingual Intersem". This document will > probably require a few months to complete as it will be kept in tune > with the preparation of the various documents as they are being > developed. In which, it will also serve as an executive summary. The > submissions should concern the intersem, semantic addressing system, > polynym metastructure, intertest to ensure that the real-life testing > (technology and governance) does not interfere with daily traffic, a > global semiotic approach, the technical formalization of commercial > as well as private spheres and built-in micropayment, the much needed > glossary, etc. no to speak of the much necessary underlaying research > on linguistic, metatechnic, ethitechnic, anthrobotic sociology, > governance methodology, facilitation reasoning, etc. So, it will > there is a big task ahead. I suspect it will not be a lead user lead > topic for a long and that a reticular semantician community may develop. > > 4. We plan, according to the IETF standardization rules, to deploy > two major running projects along this plan: > > - "projet.fra" for a French language open ontology that shall use > its own extended namespace (semantic addressing) as its open taxonomy > - "multilinc", for African languages - in this case, we plan to > progressively publish a guide on the way to port a language, as well > as a culture, on the intersem. > > 5. Our main concern is that the existing Internet's possibilities, > which we may activate/unleash, could result in new governance, > adminance (technical and administrative governance), and network > economy evolution challenges. We, therefore, should be rather careful > and liaise with all the concerned international organizations > (UNESCO, ITU, WSIS, ISO, ICANN, IAB, EU, MINC, MAAYA, OECD, ASIWG, > etc.) in order to keep them well informed. > > This is why I hereby suggest that we consider an open IUCG "Intersem > preparation" concertation meeting to be held in early October in > Versailles. As the MLTF used to. > > Have great and studious vacations. > > jfc > _______________________________________________ > listegenerale mailing list > listegenerale@franceatlarge.org > http://franceatlarge.org/mailman/listinfo/listegenerale_franceatlarge.org > -- Margaret Dunham Persée - Université Lyon2 86 rue pasteur. 69007 Lyon. FRANCE tél : (+33) 4 78 69 74 66 http://www.persee.fr From peter@peter-dambier.de Sat Jul 11 01:55:44 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 368283A68AD for ; Sat, 11 Jul 2009 01:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2Wj6Nenv+oP for ; Sat, 11 Jul 2009 01:55:42 -0700 (PDT) Received: from ns6.cesidio.net (racine.cesidio.net [88.198.54.195]) by core3.amsl.com (Postfix) with ESMTP id 976333A6887 for ; Sat, 11 Jul 2009 01:55:42 -0700 (PDT) Received: from [62.227.215.9] (helo=[7.19.30.27]) by ns6.cesidio.net with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MPYOy-0001e3-JN for iucg@ietf.org; Sat, 11 Jul 2009 08:57:49 +0000 Message-ID: <4A5853A5.3010202@peter-dambier.de> Date: Sat, 11 Jul 2009 10:56:05 +0200 From: Peter Dambier Organization: Cesidian Root User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: internet users contributing group References: <20090710223416.9443228C3DE@core3.amsl.com> In-Reply-To: <20090710223416.9443228C3DE@core3.amsl.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [iucg] please don't X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: peter@peter-dambier.de, 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, 11 Jul 2009 08:55:44 -0000 Have a nice holiday, Jefsey. And yes, I agree with charter and rough consensus. Don't touch the waste pipe (tuyau de chute) as long as the water is running. :) Cheers Peter and Karin jefsey wrote: > Dear IUCG participants, > I strongly advise you not to keep involving yourselves into the current > WG-IDNABIS debate, moreover using material we work on for a different > purpose. This debate is now very well documented by IETF leaders > explaining the point at hand in ways that other long time IETF > participants can understand. This may certainly seem boring, or even > deeply hurting, or childish to you when all the participants are English > mother tongue engineers, give you the feeling they decide for the other > 29.999 natural languages, or pretend to speak your own language better > than you, specially when you are an high level academic, are from other > communities, etc.. However .... > > You have to accept that this is a long standing IETF debate, not a young > IUCG debate. IETF is part of the Internet architecture. Its English is > part of the IETF. In addition some participants who are involved today > are actually new to the debate. We must not confuse them with points > they never considered yet. Let give them time to bring themselves up to > speed. If they join the debate it is because they feel it has reached an > important point. Please also remember two basic rules: "don't feed the > troll" - "don't feed competition either". > > We have made our point for the records (IAB, IESG, IETF/LC). As being > lead users with a proposition: > > - we 100% agree with the Charter, > - we respect every contributor's experience in the current engineering > debate (linguistic, orthotypographic issue are now over, as long as > their support is not blocked/disregarded) > - we support the forming rough consensus, > - we certainly welcome the UI layer concept as an open field to > application developpers (including open source) > - we contributed in explaining how and what we will build on top of the > current experience in 100%, respecting and protecting the currents DNS > and Internet > - how we plan two real life, full size, test projects in order to get > experience about some of the questions being raised and to validate our > proposition > - we intend to carry these projects along rules we will submit to the > community. > > As Vint advised, discussions on Interplus, Internet Plus, and Intersem > should be on a separate list. Now there is no more opposition with the > WG, such a list will not appear as competition to IDNA. The document > framework I introduced the idea yesterday will also serve as a charter > for such a list. Once this document is drafted, I will start such a list > and invite everyone who could be interested on a personnal basis. > > I am on vacations tonight and I plan to develop a wiki-to-draft > formater, have a look to Haraway and Wittegeinstein, refresh wome of my > maths, review the Interplus pages, relax and think over fundamentals of > semiotics/semantics. Let wish the IETF to get a good IDNA2008 document > set, with a coherent and structured vision of mapping strategy - from > user, application, IDNA, etc. down to the DNS. > > Best > jfc > > > _______________________________________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/listinfo/iucg -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 From jefsey@jefsey.com Sat Jul 11 13:31:23 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 54A053A6B1B for ; Sat, 11 Jul 2009 13:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[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 tkyM7IBUuS+3 for ; Sat, 11 Jul 2009 13:31:22 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 961753A6B12 for ; Sat, 11 Jul 2009 13:31:22 -0700 (PDT) Received: from 84.132.94-79.rev.gaoland.net ([79.94.132.84]:1770 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MPjEc-00048H-ED; Sat, 11 Jul 2009 13:31:50 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Jul 2009 22:05:21 +0200 To: iucg@ietf.org From: jefsey In-Reply-To: <6aad7a210907111006s7229dfcbxd3c83bc8885bc070@mail.gmail.co m> References: <4A54FB80.6020407@mozilla.org> <4A574621.7050407@mozilla.org> <4A583442.8090807@it.aoyama.ac.jp> <3AF4C27D-2D26-4525-A9B5-B4C1299B1515@google.com> <6aad7a210907111006s7229dfcbxd3c83bc8885bc070@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: <20090711203122.961753A6B12@core3.amsl.com> Cc: Andrew Sullivan Subject: [iucg] definition of mapping, resolution, reversing 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, 11 Jul 2009 20:31:23 -0000 At 19:06 11/07/2009, jean-michel bernier de portzamparc wrote: >Might we first define what mapping means in order to be sure that when >we use the word "mapping" we do not initiate unexpected side effects. > >I understand mapping as transcoding at the same layer and resolving as >cross-layer transcoding. > >Best >Portzamparc Jean-Michel, thank you for reminding us. I think we need to insert it in the DN part. - mapping : transcoding at the same layer level - a -> b (name.a -> name.b) - restoring : back-mapping - b -> a (name.b -> name.a) - resolving : down-layer transcoding a -> 12.111.31.22 (name -> address) - reversing : up-layer transcoding 12.111.31.22 -> a (address -> name) The habit in the DNS family is to use LDH for "a" or "b" in this example (Letter, Digital, Hyphen). The way we clarify the DNS I will prefer to speak of "name" and "address", since we consider DNS labels and sub-labels made of 0-Z figures and civic and semantic addresses are strings. Best jfc From mfberny@gmail.com Sun Jul 12 09:34: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 20DDC28C159 for ; Sun, 12 Jul 2009 09:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=1.100, 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 zKMN-wHwqeJ9 for ; Sun, 12 Jul 2009 09:34:41 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id BBDA428C151 for ; Sun, 12 Jul 2009 09:34:40 -0700 (PDT) Received: by ewy26 with SMTP id 26so2088689ewy.37 for ; Sun, 12 Jul 2009 09:35:08 -0700 (PDT) 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=SfQgei2DPyDx5NXM+1oEehG8lan6dUnRlrmEH5YnORo=; b=qOUOZQIH8EUby1J/tO57PoconWeQkBdj2lzWJ2Rhr6E6OxHpOZHELjnOzm9Bts94sQ 3x/MlbR9/fOuSHRlTwFbG5uF6Mi/9pWzJgjNi+p3bCm+JeF4v1YJTDGmPHg4o2kwyERC LqZVA59cGKLVGHQH/xJew0nC0wi7e19Bod9k0= 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=BNSip4SCzKnM05hV9SXTAP70tfW0R9YRPjcikdc8O6IsB3uq4Q0LkDeNJXlfe5d64o B/6WwnUO2y9159+FkEAI6+9MFg3q5hkil0k8KjLM4pgQplRCye39Vhxf8nmnzIljzs1q 4OmvXje5Sre1JiYBI/4bVA7zKGahSY0/BNJvU= MIME-Version: 1.0 Received: by 10.210.133.19 with SMTP id g19mr1904706ebd.3.1247416508071; Sun, 12 Jul 2009 09:35:08 -0700 (PDT) In-Reply-To: <20090711203122.961753A6B12@core3.amsl.com> References: <4A54FB80.6020407@mozilla.org> <4A583442.8090807@it.aoyama.ac.jp> <3AF4C27D-2D26-4525-A9B5-B4C1299B1515@google.com> <6aad7a210907111006s7229dfcbxd3c83bc8885bc070@mail.gmail.com> <20090711203122.961753A6B12@core3.amsl.com> Date: Sun, 12 Jul 2009 18:35:08 +0200 Message-ID: <58ee45520907120935g60001e41j84df5d0924dcabf1@mail.gmail.com> From: Marie-France Berny To: internet users contributing group Content-Type: multipart/alternative; boundary=0015174c3b6ad9be7b046e84c96b Cc: Andrew Sullivan Subject: Re: [iucg] definition of mapping, resolution, reversing 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, 12 Jul 2009 16:34:42 -0000 --0015174c3b6ad9be7b046e84c96b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not much my cup of tea, but I feel there is a missing difference depending on the context. I mean that "converting" could be better than resolving if the result is not final. For example would not converting better for an UDN to an ADN or to an IDN, and resolving for an IDN to an IP? Also, may would we want to introduce "aliasing" by the same tocken. What is interesting is that this general wording includes string to string mapping (like ss to eszett) and char to char as the greek final s. Salut et bonne vacances =E0 tous. Vu l'incroyable superbe anglo-saxone qui traite all=E9grement des caract=E8res allemands, turcs, grecs, fran=E7ais = =E0 tue mieux mieux, il serait peut-=EAtre plus judicieux de continuer le d=E9bat e= n tagalog (y a m=EAme l'antiborg de service qui ram=E8ne son klingon !) Marie-France Berny 2009/7/11 jefsey > At 19:06 11/07/2009, jean-michel bernier de portzamparc wrote: > >> Might we first define what mapping means in order to be sure that when >> we use the word "mapping" we do not initiate unexpected side effects. >> >> I understand mapping as transcoding at the same layer and resolving as >> cross-layer transcoding. >> >> Best >> Portzamparc >> > > Jean-Michel, > thank you for reminding us. I think we need to insert it in the DN part. > > - mapping : transcoding at the same layer level - a -> b (name.a -> name.= b) > - restoring : back-mapping - b -> a (name.b -> name.a) > - resolving : down-layer transcoding a -> 12.111.31.22 (name -> address) > - reversing : up-layer transcoding 12.111.31.22 -> a (address -> name) > > The habit in the DNS family is to use LDH for "a" or "b" in this example > (Letter, Digital, Hyphen). The way we clarify the DNS I will prefer to sp= eak > of "name" and "address", since we consider DNS labels and sub-labels made= of > 0-Z figures and civic and semantic addresses are strings. > > Best > jfc > > > > > > _______________________________________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/listinfo/iucg > --0015174c3b6ad9be7b046e84c96b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not much my cup of tea, but I feel there is a missing difference depending = on the context. I mean that "converting" could be better than res= olving if the result is not final. For example would not converting better = for an UDN to an ADN or to an IDN, and resolving for an IDN to an IP?

Also, may would we want to introduce "aliasing" by the same t= ocken.

What is interesting is that this general wording includes st= ring to string mapping (like ss to eszett) and char to char as the greek fi= nal s.

Salut et bonne vacances =E0 tous. Vu l'incroyable superbe anglo-sax= one qui traite all=E9grement des caract=E8res allemands, turcs, grecs, fran= =E7ais =E0 tue mieux mieux, il serait peut-=EAtre plus judicieux de continu= er le d=E9bat en tagalog (y a m=EAme l'antiborg de service qui ram=E8ne= son klingon !)

Marie-France Berny


2009/7/11 jefs= ey <jefsey@jefsey= .com>
At 19:06 11/07/2009, jean-michel bernier de portzamparc wrote:
Might we first define what mapping means in order to be sure that when
we use the word "mapping" we do not initiate unexpected side effe= cts.

I understand mapping as transcoding at the same layer and resolving as
cross-layer transcoding.

Best
Portzamparc

Jean-Michel,
thank you for reminding us. I think we need to insert it in the DN part.
- mapping : transcoding at the same layer level - a -> b (name.a -> n= ame.b)
- restoring : back-mapping - b -> a (name.b -> name.a)
- resolving : down-layer transcoding =A0a -> 12.111.31.22 (name -> ad= dress)
- reversing : up-layer transcoding =A012.111.31.22 -> a (address -> n= ame)

The habit in the DNS family is to use LDH for "a" or "b"= ; in this example (Letter, Digital, Hyphen). The way we clarify the DNS I w= ill prefer to speak of "name" and "address", since we c= onsider DNS labels and sub-labels made of 0-Z figures and civic and semanti= c addresses are strings.

Best
jfc





_______________________________________________
iucg mailing list
iucg@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/iucg

--0015174c3b6ad9be7b046e84c96b-- From jefsey@jefsey.com Sun Jul 12 13:49:41 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1533628C1CA for ; Sun, 12 Jul 2009 13:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.162 X-Spam-Level: X-Spam-Status: No, score=0.162 tagged_above=-999 required=5 tests=[AWL=1.118, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] 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 uGY+c3I4lNCd for ; Sun, 12 Jul 2009 13:49:40 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 88C9728C1D7 for ; Sun, 12 Jul 2009 13:48:55 -0700 (PDT) Received: from 132.142.98-84.rev.gaoland.net ([84.98.142.132]:4286 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MQ5zA-0005RH-9W; Sun, 12 Jul 2009 13:49:24 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Jul 2009 22:39:45 +0200 To: internet users contributing group , internet users contributing group From: jefsey In-Reply-To: <58ee45520907120935g60001e41j84df5d0924dcabf1@mail.gmail.co m> References: <4A54FB80.6020407@mozilla.org> <4A583442.8090807@it.aoyama.ac.jp> <3AF4C27D-2D26-4525-A9B5-B4C1299B1515@google.com> <6aad7a210907111006s7229dfcbxd3c83bc8885bc070@mail.gmail.com> <20090711203122.961753A6B12@core3.amsl.com> <58ee45520907120935g60001e41j84df5d0924dcabf1@mail.gmail.com> 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: <20090712204855.88C9728C1D7@core3.amsl.com> Subject: Re: [iucg] definition of mapping, resolution, reversing 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, 12 Jul 2009 20:49:41 -0000 At 18:35 12/07/2009, Marie-France Berny wrote: >(y a même l'antiborg de service qui ramène son klingon !) C'est un espion de ta Reine des Borgs. Il est payé par Unicode comme chien de garde. Il en a reçu le prix "Bulldog". Excellent typographe au demeurant. jfc From mfberny@gmail.com Mon Jul 13 02:41:03 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 9CD9628C2C3 for ; Mon, 13 Jul 2009 02:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 XIrcCXw-QX-V for ; Mon, 13 Jul 2009 02:41:02 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 2843928C2BA for ; Mon, 13 Jul 2009 02:41:02 -0700 (PDT) Received: by ewy26 with SMTP id 26so2397369ewy.37 for ; Mon, 13 Jul 2009 02:41:30 -0700 (PDT) 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=V2Nk75fPuD6BIKQQXhj1K4iF64J914PJqmrwowsdB1U=; b=SZCLzL0PJ3AYr7tVLtlLTU2gu5iLacitrSfkPTuMyoQj4TdimnjUsmzzHqtMepMjUq Q6R+ZFV4EvmMeljKzvrhggB40KJsXXq3u/V3vkcspThTDjiqjQ00Vnunfkl6Dr2mj3Ge asx1nbDeM5wYZkrenODwDATkT8HCciBkFVPZs= 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=Uc3w3ElSTXxvF/zSelfxmZY/lGGzOFHN4bvIgsit12m6OI07gBPKFBtTb9WKtuKjme 2gX60MzEWT0o/u1csgk+nKELMuRVoRHMpDDjPhQncbzN199TtGC7SF865489Ns2mO1Gu lOJ/OPNP9joWgbXnVoXmXFLGrUeODylUVox50= MIME-Version: 1.0 Received: by 10.211.180.15 with SMTP id h15mr4123681ebp.72.1247478089904; Mon, 13 Jul 2009 02:41:29 -0700 (PDT) In-Reply-To: References: <88CE8310BCD02256BC4B495E@PST.JCK.COM> Date: Mon, 13 Jul 2009 11:41:29 +0200 Message-ID: <58ee45520907130241w39241446o94d5c09514108f50@mail.gmail.com> From: Marie-France Berny To: Pete Resnick Content-Type: multipart/alternative; boundary=00151748e7286a00a8046e932084 Cc: Erik van der Poel , update , internet users contributing group , IDNA@eikenes.alvestrand.no, Paul Hoffman , John C Klensin , Vint Cerf Subject: Re: [iucg] mappings-01 and the general procedure 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, 13 Jul 2009 09:41:03 -0000 --00151748e7286a00a8046e932084 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just remember that if mapping to lower-cases is a MUST you force us to split. And that any other MUST MAY lead to the same result. Your decision. Good luck! Marie France Berny 2009/7/13 Pete Resnick > On 7/12/09 at 4:47 PM -0700, Erik van der Poel wrote: > > >The order of the steps in the mappings draft should probably be > >lower-casing, wide/narrow mapping, then NFC. > > Consider it done for -02. > > pr > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > --00151748e7286a00a8046e932084 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just remember that if mapping to lower-cases is a MUST you force us to spli= t.=A0
And that any other MUST MAY lead to the same result.
Your decision.
Good luck!
Marie France Berny

2009/7/13 Pete Resnick <presnick@qualcomm.com><= br>
On 7/12/09 at 4:47 PM -0700, Erik van der Poel wrote:

>The order of the steps in the mappings draft should probably be
>lower-casing, wide/narrow mapping, then NFC.

Consider it done for -02.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
__________________________________= _____________
Idna-update mailing list
Idna-update@alvestrand.no<= br> http://www.alvestrand.no/mailman/listinfo/idna-update

--00151748e7286a00a8046e932084-- From klensin@jck.com Mon Jul 13 04:15: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 CC1603A6D78 for ; Mon, 13 Jul 2009 04:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 9-04yqPEbEy2 for ; Mon, 13 Jul 2009 04:15:48 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 679173A6D6D for ; Mon, 13 Jul 2009 04:15:48 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MQJW4-0007gv-7q; Mon, 13 Jul 2009 07:16:16 -0400 Date: Mon, 13 Jul 2009 07:16:15 -0400 From: John C Klensin To: Marie-France Berny Message-ID: In-Reply-To: <58ee45520907130241w39241446o94d5c09514108f50@mail.gmail.com> References: <88CE8310BCD02256BC4B495E@PST.JCK.COM> <58ee45520907130241w39241446o94d5c09514108f50@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Mon, 13 Jul 2009 14:01:27 -0700 Cc: update , internet users contributing group Subject: Re: [iucg] mappings-01 and the general procedure 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, 13 Jul 2009 11:15:49 -0000 --On Monday, July 13, 2009 11:41 +0200 Marie-France Berny wrote: > Just remember that if mapping to lower-cases is a MUST you > force us to split. And that any other MUST MAY lead to the > same result. Your decision. Actually, no. And one last time... The decision that upper case and lower case should compare equal for undecorated Latin characters was made in the middle of 1971. I say "undecorated Latin characters" rather than, e.g., "ASCII" because, at the time and despite RFC 20, it wasn't clear that ASCII would succeed. I've explained a bit about the basis for that decision and bear some small blame for it, but very few of the other participants in the WG do... and it is not a decision to be made today. FWIW, my recollection is that there was some participation in the work that contributed to the decision from folks at CII Bull, so the decision was not entirely an "American" one. For the benefit of those who now believe the distinction is important and has always been, that syntax and matching rule applied to both host and network names. When the DNS was designed, there were only two choices. One was to preserve the earlier behavior. The other would have been to create an incompatibility situation far worse than anything we have today, with no realistic transition plan. I don't believe that second option was even discussed. For IDNs, there are the following possibilities (in theory at least) for Latin-based characters: * "A" and "a" could match for strings that contained zero non-ASCII characters, but be different if even a single non-ASCII appeared in the string. That would cause the worst sort of user astonishment, at least for users of most of the languages that use Latin-based scripts. * "A" and "a" could match always, but "=C3=81" and "=C3=A1" = would not match and neither would "=C3=85" and "=C3=A5". That would be a = very strange result globally, even though it might be desirable for French words (but not necessary French mnenomics). * If they are all permitted, for some sense of "permitted", "A" would match "a", "=C3=81" would match "=C3=A1", "=C3=85" would = match "=C3=A5", and so on. =20 The third option was the decision made for IDNA2003, largely because the two other options seemed intolerable. That decision affects orders of magnitude more labels than the Eszett and Final Sigma cases that keep coming up over and over again on this list. It is too late to change it, even if we all concluded that it was wrong (and that conclusion has not been reached). The IDNA2008 "no mapping" strategy doesn't help you because, while it would eliminate the automatic and mandatory mapping, it would do so at the cost of making "=C3=81", = "=C3=85", etc., DISALLOWED -- you still would not be able to convert them into ACE form and preserve them on reverse mapping. I don't think anyone has dismissed the legitimacy of your underlying concerns in your own context, although several of us have tried to point out that these decisions about the DNS affect the ability to distinguish among certain types of identifiers and mnemonics and not the ability to write (and consider and compare) running text --sentences or paragraphs in French or any other language. If you need a solution for the problems you and others continue to identify, the answer appears to me to be the same one that has prevailed for years: (i) Invent a "keyword" or similar system so that your users do not have to deal directly with DNS-based identifiers. Tailor those identifiers and their interpretation to French as you understand it. (ii) Have those keywords map into fully-qualified DNS names so that all network name resolution functions work properly. Those names can use randomly-generated labels: it is not necessary that they be related to any language and my personal recommendation is that you not use IDNs at all. Indeed, the best solution might be to use numeric labels or labels that contained an alphabetic character or two as a code followed by numeric strings. Finally, as with other issues, I believe it is not productive to keep trying to reopen this topic. The answer has been the same for a very long time -- 35 or more years if one considers the basic choices-- and no new evidence is being offered as to why it should be reexamined. Even if you don't accept the above and are therefore faced with a decision to "split" or not split, you (and everyone else) are better off if the WG finishes its work so you can start making decisions... dragging things out further helps no one. regards, john From vesely@tana.it Tue Jul 14 03:01:57 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 652D43A69E3 for ; Tue, 14 Jul 2009 03:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=1.921, 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 FJnbEJXGzIm6 for ; Tue, 14 Jul 2009 03:01:56 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 794B53A68F5 for ; Tue, 14 Jul 2009 03:01:56 -0700 (PDT) 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; Tue, 14 Jul 2009 12:00:35 +0200 id 00000000005DC033.000000004A5C5743.0000109D Message-ID: <4A5C5742.402@tana.it> Date: Tue, 14 Jul 2009 12:00:34 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: internet users contributing group References: <88CE8310BCD02256BC4B495E@PST.JCK.COM> <58ee45520907130241w39241446o94d5c09514108f50@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: update Subject: Re: [iucg] mappings-01 and the general procedure 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, 14 Jul 2009 10:01:57 -0000 John C Klensin wrote: > For IDNs, there are the following possibilities (in theory at > least) for Latin-based characters: > > * "A" and "a" could match for strings that contained zero > non-ASCII characters, but be different if even a single > non-ASCII appeared in the string. That would cause the worst > sort of user astonishment, at least for users of most of the > languages that use Latin-based scripts. > > * "A" and "a" could match always, but "Á" and "á" would not > match and neither would "Å" and "å". That would be a very > strange result globally, even though it might be desirable for > French words (but not necessary French mnenomics). > > * If they are all permitted, for some sense of "permitted", "A" > would match "a", "Á" would match "á", "Å" would match "å", > and so on. Since this is a theoretical enumeration, there's another two classes of possibilities that may be worth mentioning, just for the sake of completeness: * Match all of "a", "A", "á", "Á", "å", "Å", etcetera. Possibly also match "l" and "1", like old typewriters, so that, e.g., "paypal" and "paypa1" match. A procedure could even do complicate phonetics processing. * Define the mapping parametrically in _mapping.TLD, for each IDN-enabled TLD. Even if this may answer what are TLDs good for, a global mapping would still be needed for the tld label itself. From mfberny@gmail.com Wed Jul 15 13:09: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 135F13A6F4C for ; Wed, 15 Jul 2009 13:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 W35fAMT7FEUn for ; Wed, 15 Jul 2009 13:09:35 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id B24183A6F55 for ; Wed, 15 Jul 2009 13:09:11 -0700 (PDT) Received: by ewy26 with SMTP id 26so4338980ewy.37 for ; Wed, 15 Jul 2009 13:08:59 -0700 (PDT) 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=mAa5klzFBysZhSaQULuib3bIJtU50WMG9Fd5DsxIfOg=; b=lBOMU0YLofXjGNmgAnfOITYH9i6pH8yUYiP9mlX4TaP4W3y1zrgua8Ph4iBiepk0AU /iP8TCAjiDsGC/j0kUDzhN8NRwK0j/DkAGPrgDCLVr+NvLMt0Y/Ray3J3dfHD4rToSkr gUSL4J9+g3b80/P3x6iu3KF/fcqiy0gsLB3nY= 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=GsBharuS5yPAG4lFVOK9NPSuXvvPyLRRORhEB6PkyYfa5iJtZk9KosfSQitmW84Gqo ManVrvRLrVGyD7tfxc8QrVabTVxA8oclCTj6y6FO1Q774zcf28C+v+sA0iNJvBnny5oF s13Er8pKIzDY8eggt/t8y0a2EUzlW0lOTqS4s= MIME-Version: 1.0 Received: by 10.211.196.3 with SMTP id y3mr2472394ebp.96.1247686955790; Wed, 15 Jul 2009 12:42:35 -0700 (PDT) In-Reply-To: References: <200907142256.n6EMuqY26530@birdie.sybase.com> <4A5D2096.6060002@abenaki.wabanaki.net> <58ee45520907150413g722d3742i999c873ecd000b08@mail.gmail.com> Date: Wed, 15 Jul 2009 21:42:35 +0200 Message-ID: <58ee45520907151242w69e90948n7b397c61210215a7@mail.gmail.com> From: Marie-France Berny To: Vint Cerf Content-Type: multipart/alternative; boundary=0015174c0ea4ca7263046ec3c133 Cc: internet users contributing group Subject: Re: [iucg] U+07FA, NKO LAJANYALAN (was Re: consensus on TATWEEL) 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, 15 Jul 2009 20:09:36 -0000 --0015174c0ea4ca7263046ec3c133 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sorry, but the bulk of this WG are engineers and typographers, not users, not grammarians, not semanticians, not elected representatives, not operators, not vendors, i.e. not from the bulk of those who will actually decide, design, propagate, manage and use. MFBerny 2009/7/15 Vint Cerf > Sorry, but the bulk of the email on this subject was in favor of > disallowing the character. > this is finished business. > vint > --0015174c0ea4ca7263046ec3c133 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, but the bulk of this WG are engineers and typographers, not users, n= ot grammarians, not semanticians, not elected representatives, not operator= s, not vendors, i.e. not from the bulk of those who will actually decide, d= esign, propagate, manage and use.
MFBerny


2009/7/15 Vint Cerf <vint@google.com>
Sorry, but the bulk of the email on this subject was in fav= or of disallowing the character.

this is finished busine= ss.
vint

=A0
--0015174c0ea4ca7263046ec3c133-- From eblanconil@gmail.com Wed Jul 15 15:46: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 445E43A6B45 for ; Wed, 15 Jul 2009 15:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOrHK7lhMkW2 for ; Wed, 15 Jul 2009 15:46:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id BAF753A68CD for ; Wed, 15 Jul 2009 15:46:19 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so887879fga.18 for ; Wed, 15 Jul 2009 15:44:48 -0700 (PDT) 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 :content-transfer-encoding; bh=dhDFG8fKddMzUWGrBA6rBtarnCbiW0c8UEbZTTYBoeE=; b=sH7oC5qxL06lQ8ocAzeT3HptdpbLwi/O1kRGF6WCLpf2/6TJHmKI1xT8FnaYADmTuj Sgs0SMZmuDZqxUaHS+jQxkEqBXuVaztCMWkae0eWs6Tr39TDRIQlA1GviaQzlaNk+pfp uv9nC0WzM/15BU2TLm5eIBIx4lM4B/XPXkLkU= 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:content-transfer-encoding; b=RcN/CuLvcerFpnk10N5oOdZcKNoPkLU98SXdPDb49r5wNrfHkBLv+x5cIR3C5LEj7O QoOpyAmxAsX5qPH3fHLYd7Kj3nAxRPCEcsGExjbFcYOGhx863lTXMCMXYdlkOfaCvfme eoIJvCNkG6dw50rdptZafpgJAt2BlUvnkMQR0= MIME-Version: 1.0 Received: by 10.86.54.8 with SMTP id c8mr5537012fga.38.1247697888103; Wed, 15 Jul 2009 15:44:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Jul 2009 00:44:48 +0200 Message-ID: <6589127a0907151544s3c59491co67f2b70fcfee2dd3@mail.gmail.com> From: Elisabeth Blanconil To: dready@gmail.com, Vint Cerf , listegenerale@franceatlarge.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: internet users contributing group Subject: Re: [iucg] Updates to Exceptions and BackwardCompatible Sets 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, 15 Jul 2009 22:46:21 -0000 Bingo ! They did it, just in time !!! 16 months ago, JFC explained us that: * the WG would proceed slowlly, trying to make us look the bad guys. * that just before the end of the ICANN JPA there would be a blunt pressure probably using an IETF meeting. * it would be for a crash packaged wrapp-up including an industry controlled Classified Character Reviewer using another IETF-alvestrand.no mailing list. * this would be to provide an IETF maintenance of a IANA/Unicode IDNA table and lists. * that would extend the CLDR locale files to complete globalization (internationalization, localization, filtering, IDN). The reason why they refused to discuss IDNs at the WG-LTRU.. * this could even be merged with RFC 4646 alvestrand.no mailing list so Michael Everson might manage the table, correct Patrick's suggestions, and offer a lighter-weight process having some real experience of containing undue requests. Here it is, clearly introduced within a few minutes, after just resurecting the "overwhelming" TATWEEL consensus, 10 days before being the WG is welcomed by .se and .museum, and probably some ICANN, ccTLD, linguists, "hurluberlus" (US Industry French supporters), ISOC sponsors good coming support during the week. 2009/7/15 23:26 Wil Tan : > What are the WG's expectations on possible updates to the list of excepti= ons? 2009/7/15 23:40 Vint Cerf (int@google.com>: nominally I think we hope that we will not have to deal with going from disallowed to contextO. I think the current view is that such changes should require IETF-level intervention in the near term although a lighter-weight process might be considered based on experience. Does anyone see this differently? vint 2009/7/15 23:49 Mark Davis =E2=8C=9B : > I think we need to strictly forbid, for stability's sake, any changes in = the following direction: Making any change in the other direction should pr= obably require IETF-level intervention in the near term, but as you say, mi= ght be made lighter-weight over time. DISALLOWED =3D> CONTEXT* =3D> PVALID,= Does this match what you think, Vint? Mark Sure it does! Bravo, JFC !!! I do no not need a france@large consensus call :-). We all waited for this suggestion !!!. So, we all know the answer by core. We gave it from the very beginning. We are fully OK as long as this may be legitimatelly circumvented when needed, meaning there is no other MUST than to _fully_ support the DNS and that at least the Reviewer is actually periodically designated by the IESG ("as per non-applied RFC 4646" [JFC's quote]). Or the suggestion also is, (JFC says that it could please Mark) that ISO 639, 3106 and 10646 and Unicode co-chair the Reviewing committee. We just wish a dialog with the corresponding FLOSS/users approach that may result from our testing projects. france@large's position is quite simple: let respect the Charter, i.e. let not force orthotypography, character (and language) filtering at protocol level. Question is: is this also what Microsoft and Firefox want? MFBerny PS. Jefsey a gagn=C3=A9 son pari ! je n'en reviens pas :-) On lui doit donc un d=C3=AEner. Il est =C3=A0 Montpellier, je peux venir de Marseille. O=C3= =B9 =C3=AAtes vous en vacances d'ici la fin du mois ? From jmabdp@gmail.com Wed Jul 15 16:43:16 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD37B3A6F92 for ; Wed, 15 Jul 2009 16:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ezZlfIHdkbUM for ; Wed, 15 Jul 2009 16:43:15 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 36FFD3A6F84 for ; Wed, 15 Jul 2009 16:43:15 -0700 (PDT) Received: by ewy26 with SMTP id 26so4461636ewy.37 for ; Wed, 15 Jul 2009 16:43:15 -0700 (PDT) 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=9iNcl0T1TC27X17dX6NqnoJiIqJsqK+HCCBhJ3WPZbI=; b=Yn3/ld/NfBoY5aoM2Dvtr8lpvH9yOdRl3BhkYh43vU69hSVv1N1xx6augElAexdhVH XQw/wBKQ78bMH76rM6rYM1awITmvtzWLsyCk40JO4TI3bBTXGNrL/9nRmkmwAdeL9sd7 TdUaBUiOtsiwI9rstxa11uytuEv4+bpWjmzqo= 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=h2ZDwVl/DpncUI88Bzth7DQmrNuBIeVin3Z7dKDXhCDWBDt9MJar6zlQlbKOOjh/q0 HRsVhySLVQXFTsRwNKvdm/6xb09GGLnIZKBjp1CZXr5+cvUbfr9svyRv+262NXwfjCKq g/vFum+QwmETkKTjnHiLMH+V+4KTdFRAv93rQ= MIME-Version: 1.0 Received: by 10.216.15.85 with SMTP id e63mr2181051wee.199.1247700970371; Wed, 15 Jul 2009 16:36:10 -0700 (PDT) In-Reply-To: <6589127a0907151544s3c59491co67f2b70fcfee2dd3@mail.gmail.com> References: <6589127a0907151544s3c59491co67f2b70fcfee2dd3@mail.gmail.com> Date: Thu, 16 Jul 2009 01:36:09 +0200 Message-ID: <6aad7a210907151636ub426272q3a623c4deff375a4@mail.gmail.com> From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=0016e64c1ab4200299046ec7056b Cc: listegenerale@franceatlarge.org, dready@gmail.com, Vint Cerf Subject: Re: [iucg] Updates to Exceptions and BackwardCompatible Sets 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, 15 Jul 2009 23:43:17 -0000 --0016e64c1ab4200299046ec7056b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Elisabeth, the mail of Marie France was internal to the Interplus mailing list. It discloses our coopetitive strategy at a time when it may not help anyone. I just got JFC on Skype. He repeats that we should stay quite and leave the US industry to decide if they respect or not the Charter. This is really not our cup of tea. If they can help mastering Unicode we will benefit from it at User Interface or Interplus layers. JFC said he just sent a mail to the Chair and the AD on all this and sort of apologize for your mail at the end. This is the IETF, not ISOC France or the cafedu.com mailing list. Best. Portzamparc. 2009/7/16 Elisabeth Blanconil > Bravo, JFC !!! > I do no not need a france@large consensus call :-). We all waited for > this suggestion !!!. So, we all know the answer by core. > > We gave it from the very beginning. We are fully OK as long as this > may be legitimatelly circumvented when needed, meaning there is no > other MUST than to _fully_ support the DNS and that at least the > Reviewer is actually periodically designated by the IESG ("as per > non-applied RFC 4646" [JFC's quote]). Or the suggestion also is, (JFC > says that it could please Mark) that ISO 639, 3106 and 10646 and > Unicode co-chair the Reviewing committee. We just wish a dialog with > the corresponding FLOSS/users approach that may result from our > testing projects. > > france@large's position is quite simple: let respect the Charter, i.e. > let not force orthotypography, character (and language) filtering at > protocol level. Question is: is this also what Microsoft and Firefox > want? > > MFBerny > --0016e64c1ab4200299046ec7056b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Elisabeth,
the mail of Marie France was internal to the Interplus mailin= g list. It discloses our coopetitive strategy at a time when it may not hel= p anyone. I just got JFC on Skype. He repeats that we should stay quite and= leave the US industry to decide if they respect or not the Charter. This i= s really not our cup of tea. If they can help mastering Unicode we will ben= efit from it at User Interface or Interplus layers. JFC said he just sent a= mail to the Chair and the AD on all this and sort of apologize for your ma= il at the end. This is the IETF, not ISOC France or the cafedu.com mailing list.
Best.
Portzamparc.

2009/7/16 Elisabeth= Blanconil <eb= lanconil@gmail.com>
Bravo, JFC !!!
I do no not need a france@large consensus call :-). We all waited for
this suggestion !!!. So, we all know the answer by core.

We gave it from the very beginning. We are fully OK as long as this
may be legitimatelly circumvented when needed, meaning there is no
other MUST than to _fully_ support the DNS and that at least the
Reviewer is actually periodically designated by the IESG ("as per
non-applied RFC 4646" [JFC's quote]). Or the suggestion also is, (= JFC
says that it could please Mark) that ISO 639, 3106 and 10646 and
Unicode co-chair the Reviewing committee. We just wish a dialog with
the corresponding FLOSS/users approach that may result from our
testing projects.

france@large's position is quite simple: let respect the Charter, i.e.<= br> let not force orthotypography, character (and language) filtering at
protocol level. Question is: is this also what Microsoft and Firefox
want?

MFBerny
--0016e64c1ab4200299046ec7056b-- From eblanconil@gmail.com Wed Jul 15 17:09:26 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D54F28C11D for ; Wed, 15 Jul 2009 17:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdzLU2S7u2Ol for ; Wed, 15 Jul 2009 17:09:25 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 6C1D328C1AB for ; Wed, 15 Jul 2009 17:09:21 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1107499fgg.18 for ; Wed, 15 Jul 2009 17:09:50 -0700 (PDT) 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 :content-transfer-encoding; bh=U33qnLcmv6M3fzwDgHRDywOQpcQblzMVNFsS0HLfR7s=; b=SIILHZv9GFt9EhD40K5RkeWgRia8cOCoB61A7NkQhpxHHymqiTgAQmGU8j54QOa5v9 84Sd9UehMP6DBudgYL5ZWGJL+yBFwrvY+JHuWddJJnV96LBDVKa0Eq96enBbk/DjYgO0 0+vJjwCE/+9yytdSYV9fl5ipXdXQvMY23YKIQ= 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:content-transfer-encoding; b=MQrzwTDjfnEF3OI4x0eoVLgBw3lhE75hlMavTraU73j8Hy7TgrAS6BdfQu4wwcoZ1O DQ5LREErDYRbU/jQ2nN4clPRJo2MWdMAd/lFZi+Gw7QF8BNYvk+vVuz6cj1qV/eaVNrT NgO4sQgPEApeC3Q0k23KpRCtDb8NTpTaPxoKs= MIME-Version: 1.0 Received: by 10.239.167.10 with SMTP id d10mr609720hbe.118.1247702986698; Wed, 15 Jul 2009 17:09:46 -0700 (PDT) In-Reply-To: <6589127a0907151544s3c59491co67f2b70fcfee2dd3@mail.gmail.com> References: <6589127a0907151544s3c59491co67f2b70fcfee2dd3@mail.gmail.com> Date: Thu, 16 Jul 2009 02:09:46 +0200 Message-ID: <6589127a0907151709u1b9925acya7369674cf9b751c@mail.gmail.com> From: Elisabeth Blanconil To: idna-update@alvestrand.no, listegenerale@franceatlarge.org, internet users contributing group , interplus@thinkingthe.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [iucg] Updates to Exceptions and BackwardCompatible Sets 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, 16 Jul 2009 00:09:26 -0000 I apologize for having sent this mail on different maling lists. It discloses an exchange on another mailing list and and the strategy of this list. Please disregard it. Elisabeth Blanconil 2009/7/16 Elisabeth Blanconil : > Bingo ! They did it, just in time !!! > > 16 months ago, JFC explained us that: >> * the WG would proceed slowlly, trying to make us look the bad guys. > * that just before the end of the ICANN JPA there would be a blunt > pressure probably using an IETF meeting. > * it would be for a crash packaged wrapp-up including an industry > controlled Classified Character Reviewer using another > IETF-alvestrand.no mailing list. > * this would be to provide an IETF maintenance of a IANA/Unicode IDNA > table and lists. > * that would extend the CLDR locale files to complete globalization > (internationalization, localization, filtering, IDN). The reason why > they refused to discuss IDNs at the WG-LTRU.. > * this could even be merged with RFC 4646 alvestrand.no mailing list > so Michael Everson might manage the table, correct Patrick's > suggestions, and offer a lighter-weight process having some real > experience of containing undue requests. > > Here it is, clearly introduced within a few minutes, after just > resurecting the "overwhelming" TATWEEL consensus, 10 days before being > the WG is welcomed by .se and .museum, and probably some ICANN, ccTLD, > linguists, "hurluberlus" (US Industry French supporters), ISOC > sponsors good coming support during the week. > > 2009/7/15 23:26 Wil Tan : >> What are the WG's expectations on possible updates to the list of except= ions? > > 2009/7/15 23:40 Vint Cerf (int@google.com>: > nominally I think we hope that we will not have to deal with going > from disallowed to contextO. I think the current view is that such > changes should require IETF-level intervention in the near term > although a lighter-weight process might be considered based on > experience. Does anyone see this differently? vint > > 2009/7/15 23:49 Mark Davis =E2=8C=9B : >> I think we need to strictly forbid, for stability's sake, any changes in= the following direction: Making any change in the other direction should p= robably require IETF-level intervention in the near term, but as you say, m= ight be made lighter-weight over time. DISALLOWED =3D> CONTEXT* =3D> PVALID= , Does this match what you think, Vint? Mark > > Sure it does! > > Bravo, JFC !!! > > > I do no not need a france@large consensus call :-). We all waited for > this suggestion !!!. So, we all know the answer by core. > > We gave it from the very beginning. We are fully OK as long as this > may be legitimatelly circumvented when needed, meaning there is no > other MUST than to _fully_ support the DNS and that at least the > Reviewer is actually periodically designated by the IESG ("as per > non-applied RFC 4646" [JFC's quote]). Or the suggestion also is, (JFC > says that it could please Mark) that ISO 639, 3106 and 10646 and > Unicode co-chair the Reviewing committee. We just wish a dialog with > the corresponding FLOSS/users approach that may result from our > testing projects. > > france@large's position is quite simple: let respect the Charter, i.e. > let not force orthotypography, character (and language) filtering at > protocol level. Question is: is this also what Microsoft and Firefox > want? > > MFBerny > > > PS. Jefsey a gagn=C3=A9 son pari ! je n'en reviens pas :-) On lui doit do= nc > un d=C3=AEner. Il est =C3=A0 Montpellier, je peux venir de Marseille. O= =C3=B9 =C3=AAtes > vous en vacances d'ici la fin du mois ? > > Elisabeth Blanconil From patrik@frobbit.se Wed Jul 15 02:26: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 9AF953A6B49 for ; Wed, 15 Jul 2009 02:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, 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 IZxx5KZNbH9n for ; Wed, 15 Jul 2009 02:26:08 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id E15C13A6BA7 for ; Wed, 15 Jul 2009 02:26:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id CF022613991F; Wed, 15 Jul 2009 11:24:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb43ZmoRtBxy; Wed, 15 Jul 2009 11:24:02 +0200 (CEST) Received: from [156.106.204.93] (rtp-isp-nat1.cisco.com [64.102.254.33]) by srv01.frobbit.se (Postfix) with ESMTP id C0DB86139911; Wed, 15 Jul 2009 11:24:00 +0200 (CEST) Message-Id: <883F7654-55E4-4465-837F-163A96ADCEDC@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Alessandro Vesely In-Reply-To: <4A5C5742.402@tana.it> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-13-907182204" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 11:23:58 +0200 References: <88CE8310BCD02256BC4B495E@PST.JCK.COM> <58ee45520907130241w39241446o94d5c09514108f50@mail.gmail.com> <4A5C5742.402@tana.it> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Thu, 16 Jul 2009 11:45:42 -0700 Cc: update , internet users contributing group Subject: Re: [iucg] mappings-01 and the general procedure 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, 15 Jul 2009 09:26:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-13-907182204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 14 jul 2009, at 12.00, Alessandro Vesely wrote: > * Match all of "a", "A", "=E1", "=C1", "=E5", "=C5", etcetera. = Possibly also > match "l" and "1", like old typewriters, so that, e.g., "paypal" and > "paypa1" match. A procedure could even do complicate phonetics =20 > processing. Not acceptable for us in Sweden, as 'a' and '=E4' are two different =20 letters in the alphabet. The '=E4' is not an accented 'a', as it is in =20= some other languages. They should in Swedish absolutely NOT match each other. Patrik --Apple-Mail-13-907182204 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFKXaAurMabGguI180RAp20AJ40LZRgL3N64ATNjruoMrnCseArJACgklpM HomtAw62XBPYz9pEaVXLo9E= =GsYq -----END PGP SIGNATURE----- --Apple-Mail-13-907182204-- From klensin@jck.com Wed Jul 15 06:12: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 168573A6D4E for ; Wed, 15 Jul 2009 06:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 q7w7LoI8zfjI for ; Wed, 15 Jul 2009 06:12:30 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 9EC623A6D27 for ; Wed, 15 Jul 2009 06:12:29 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MR4Hc-000Pj7-B7; Wed, 15 Jul 2009 09:12:28 -0400 Date: Wed, 15 Jul 2009 09:12:27 -0400 From: John C Klensin To: Alessandro Vesely , internet users contributing group Message-ID: <6E5EB50CED2423030064C3AB@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Thu, 16 Jul 2009 11:45:42 -0700 Cc: update Subject: Re: [iucg] mappings-01 and the general procedure 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, 15 Jul 2009 13:12:31 -0000 --On Tuesday, July 14, 2009 12:00 +0200 Alessandro Vesely wrote: > Since this is a theoretical enumeration, there's another two > classes of possibilities that may be worth mentioning, just > for the sake of completeness: >=20 > * Match all of "a", "A", "=C3=A1", "=C3=81", "=C3=A5", = "=C3=85", etcetera. > Possibly also match "l" and "1", like old typewriters, so > that, e.g., "paypal" and "paypa1" match. A procedure could > even do complicate phonetics processing. Yes. Of course, matching all of those decorated characters to each other and to the basic Latin forms would largely eliminate at least some of the primary reasons for doing IDNs at all, at least for extended Latin characters. Patrik's example for Swedish is only one example here: depending on language, some "decorated" Latin characters are really separate characters that cannot possibly match and others (or the same ones in a different language) may be optional, or semi-optional accents, phoneme-modifiers, or stress marks. But it is logically possible. > * Define the mapping parametrically in _mapping.TLD, for each > IDN-enabled TLD. Even if this may answer what are TLDs good > for, a global mapping would still be needed for the tld label > itself. I haven't thought about this enough to say "impossible", but I don't think it could be made to work in an acceptable way in practice. First, there is really no such thing as an "IDN-enabled TLD" unless you mean "TLDs who were required to ask ICANN for permission, or who asked as a courtesy, and got that permission". The number who are required to ask is a small fraction of the total number of TLDs. Second, that permission, or lack thereof, applies only at the second level. If I'm got control of the zone for BigMultinational.SomeTLD, then I can put IDNs in my zone regardless of what permissions the registry to SomeTLD has or needs. =20 And, finally and most important, and again using BigMultinational.SomeTLD as an example, it would be perfectly natural for me to set up national, regional, or language subdomains to reflect my business organization or marketing policies. The domains en-uk.BigMultinational.SomeTLD, en-us..BigMultinational.SomeTLD, de-de.BigMultinational.SomeTLD, de-ch.BigMultinational.SomeTLD, fr.BigMultinational.SomeTLD, cn.BigMultinational.SomeTLD, jp.BigMultinational.SomeTLD, and so on are all rational, reflect contemporary practice in many organizations, and would probably all consider different mapping rules appropriate. That means _mapping.TLD really needs to be _mapping.ParentDomain. And that then gets tied up with the CNAME/ DNAME problem and figuring out which parent domain is really intended, probably rules for searching up the tree for grandparent domains if there is no table at a given level. =20 It may not be impossible, but I don't think it is even vaguely plausible given the DNS. john From jefsey@jefsey.com Thu Jul 16 15:14:16 2009 Return-Path: X-Original-To: iucg@core3.amsl.com Delivered-To: iucg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF9228C1FA for ; Thu, 16 Jul 2009 15:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 tCMatI7GBe27 for ; Thu, 16 Jul 2009 15:14:14 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id A6CFC3A6D78 for ; Thu, 16 Jul 2009 15:13:46 -0700 (PDT) Received: from 98.165.193-77.rev.gaoland.net ([77.193.165.98]:2259 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MRZDG-0005qZ-Ap; Thu, 16 Jul 2009 15:14:03 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Jul 2009 00:14:00 +0200 To: Lisa Dusseault From: JFC Morfin In-Reply-To: References: <8CEF048B9EC83748B1517DC64EA130FB3C1A2BF4EF@off-win2003-01.ausregistrygroup.local> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_166693984==.ALT" 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: <20090716221346.A6CFC3A6D78@core3.amsl.com> Cc: iucg@ietf.org Subject: Re: [iucg] Disallowing code 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: Thu, 16 Jul 2009 22:14:16 -0000 --=====================_166693984==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 13:42 16/07/2009, Vint Cerf wrote: >The problem we foresee is that not all registry operators (remember >this is not just at top or second level but all through the >hierarchy) will show the same diligence. So the most troubling >cases can be excluded by protocol. The Charter says: >The WG will stop work and recommend that a new charter be generated >if it concludes that any of the following are necessary to meet its >goals: (iii) A change to the basic approach taken in the design team >documents (Namely: independence from Unicode version and elimination >of character mapping in the protocol) DISALLOWing being a "mapping to nil", here voluntarily included in the protocol, I hereby formally request that this WG stops all work and a new charter is subsequently generated. However, as expressed in my mail sent yesterday, I fully realize that we are currently in the process of a coup by Unicode members. They are simply trying to force a new extension of their "globalization" doctrine layer violation (cf. attached note). They actually maneuvered just as we had foresaw, including utilizing us. The alternative they propose is: (1) either the IETF will accept their control over the Internet linguistic architecture (2) or they will claim that some people, like myself and IUCG@IETF members, are delaying the "overwhelming consensus" that they have identified, and in turn make topics of the future, such as the sex of the glyphs, a priority. As a result, they have been forced to proceed independently. This is exactly why I will not appeal now against a negative or non-response from you: I prefer the regular IETF/LC to apply first. I, therefore, shall leave them with the responsibility to modify the Internet architecture as well as to introduce constraints in favor of a business interest group vs. the rest of the world languages, cultures, and nations. However, I will quote this mail in my appeal should the IETF/LC fail to protect the Internet neutrality the WG-IDNABIS Charter adequately protects. (May I remind you that I will not participate to the WG/LC and to the IETF due to other maneuvers of the same influence group, in the same lengthy opposition they have to the people' interests I try to defend). As far as I am concerned, when back from vacations, I will continue to support the IUCG, so it may proceed with its user documentation of the way the existing Internet architecture does address the "multilingualization" they need, in an adequate, open, cross-technology, presentation layer based, off-the-shelf, neutral, pollution free, and semantic addressing ready manner (cf. attached note). Our alternative is outside of their trap. Actually, I have to thank the Unicode consortium members for having gallantly answered the challenge that I forced them into. They have far superior knowledge in the Unicode area compared to simple users such as us on that issue. We had to force them to document, from the horse's mouth, as to "why we were wrong and why they were right", and who was really concerned politically and why. We also needed their tables to be conveniently documented. We would never have obtained otherwise such precious material for ensuring that the Internet's existing possibilities would permit the support of multilingualization as we know now it does. jfc For the convenience of the readers, the context is as follows: 1. There is a linguistic (semiotic) support pile wherein: - Universalization consists in the neutral, equal, and technical support of every language, script, orthotypography (the way in which a culture will semantically interpret the way something is written) and quoting capacity of other languages, i.e. every existing language entity is fully supported and understood. Universalization is today commonly obtained through the use of metaconcepts being numerically transcoded. Further work in that area belongs to the semantic facilitation technologies. - Multilingualization is the architectural approach that permits universalization through, for example, the globalization (cf. below) of every language. Its simplest support is provided by the presentation layer. As in all network architecture, the Internet includes a presentation layer. However, up to now its exploration and documentation were limited. - Globalization is a method that is documented by Unicode that enables the reduction of the linguistic barriers between a given language and other natural languages. It involves (to this day): --- the internationalization of the media by including the signs of every script (ex. Unicode). The NFC is a reduction of the Unicode list that can be utilized via the Internet. What is being discussed today is to attain a further reduction for the Internet namespace. --- the localization of the other end, through the use of "locale" files. --- the langtagging (permitting language filtering) of the content for the application's benefit. 2. The CSoC It so happens that the Unicode members seem to also benefit from a centralizing set of chances (CSoC) that could defeat the distributed nature of the world and of the Internet, and in turn sterilize the tremendous innovation capacity of the Internet presentation layer. This would be great for the present form of the Internet economy and governance that they dominate or participate in (stakeholders), which have not been properly prepared to cope with the impact of the activation of the presentation layer. This is why they are striving for innovation moratoria that they like to call the "status quo", in spite of the detriment that it represents for all the people. A technical, business, and political status quo is permitted by the CSoC. By luck, the CSoC seems to result from porting globalization tasks within the multilingualization layer, something ASCII users fond convenient and with e-business favorable consequences. This layer violation limits the multilingualization layer to a single globalization occurrence: in this case, this is the ASCII English language globalization presentation. This is technically an exceedingly unstable layer violation because it only rests on the subjective user acceptation to limit his/her Internet usage due to a misunderstanding. However, unexpectedly the CSoC happens to technically, commercially, and politically influence those who design, use, and manage the Internet in favor of such an auto-limitation. In particular, its constraints result in violations of the Internet neutrality that might make more difficult a deployment of the presentation layer (some 63 character DNS labels will be mapped to others, or to nil, upon the sole IETF engineering authority). This would equate to the machines and engineers (of some major corporations) to prevail on all the people of the world and their languages and culture. This is purely bad luck. 3. Interplus Interplus comprises a two (interapplication and pseudo-network) layer transparent "post-wire" continuation (interplug) of the network on the user side. It completes the Internet architecture on an edge to edge basis (the network ends on the users side), in which now every user has an intelligent syste. This was not the case in 1983 when the Internet and DNS began. The Interplus (interplugged layers on the user side system) includes a double interapplication networking capacity (through the Internet or through OPES [open pluggable edge services(*)] overlays) and an unlimited capacity for network interrelated services applications. (*) RFC One of these services is to support presentations, i.e. the appearing change of the network to a qualified externet (an external network look alike within the Internet). The qualifications can include linguistic networks (the default being the English ASCII version), encryption, the support of other codes than Unicode or algorithms than punycode, etc. Presentations can be identified through label headers, (such as "xn--" for IDNA), TLD (as in the ".fra" experiment), classes, or a mix of them. Presentations are transparent to applications. Another service is the support of the Domain Names Pile. This is a smart extension of the Host.txt possibility. The user name space can fully support the orthotypography of every language and trademarks through User/Universal Domain Names (UDN). UDNs will first be converted into Application Domain Names (ADNs) in order to relate with applications (such as Skype, authentication, payment services, etc.). If needed, they will in turn be converted into regular Domain Names (for example, through punycode). UDNs are independent from the Internet and can be used for application, TV, process resolution, IA, etc. As far as the Internet is concerned, IDNs (Internet Domain Names), as accepted and resolved by the DNS, are the reference. This reference should become universal and be read as based upon the 0-Z numbering set as well as the "." and "-" strong and weak separators. (*) RFC3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services RFC3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios RFC3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols RFC3835 An Architecture for Open Pluggable Edge Services (OPES) RFC3837 Security Threats and Risks for Open Pluggable Edge Services (OPES) RFC3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES) RFC3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication RFC3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations RFC4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core RFC4236 HTTP Adaptation with Open Pluggable Edge Services (OPES) RFC4496 Open Pluggable Edge Services (OPES) SMTP Use Cases RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP --=====================_166693984==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 13:42 16/07/2009, Vint Cerf wrote:
The problem we foresee is that not all registry operators (remember this is not just at top or second level but all through the hierarchy) will show the same diligence. So  the most troubling cases can be excluded by protocol.

The Charter says:
The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and elimination of character mapping in the protocol)


DISALLOWing being a "mapping to nil", here voluntarily included in the protocol, I hereby formally request that this WG stops all work and a new charter is subsequently generated.


However, as expressed in my mail sent yesterday, I fully realize that we are currently in the process of a coup by Unicode members. They are simply trying to force a new extension of their "globalization" doctrine layer violation (cf. attached note). They actually maneuvered just as we had foresaw, including utilizing us. The alternative they propose is:
 
(1) either the IETF will accept their control over the Internet linguistic architecture
(2) or they will claim that some people, like myself and IUCG@IETF members, are delaying the "overwhelming consensus" that they have identified, and in turn make topics of the future, such as the sex of the glyphs, a priority. As a result, they have been forced to proceed independently.

This is exactly why I will not appeal now against a negative or non-response from you: I prefer the regular IETF/LC to apply first. I, therefore, shall leave them with the responsibility to modify the Internet architecture as well as to introduce constraints in favor of a business interest group vs. the rest of the world languages, cultures, and nations. However, I will quote this mail in my appeal should the IETF/LC fail to protect the Internet neutrality the WG-IDNABIS Charter adequately protects. (May I remind you that I will not participate to the WG/LC and to the IETF due to other maneuvers of the same influence group, in the same lengthy opposition they have to the people' interests I try to defend). As far as I am concerned, when back from vacations, I will continue to support the IUCG, so it may proceed with its user documentation of the way the existing Internet architecture does address the "multilingualization" they need, in an adequate, open, cross-technology, presentation layer based, off-the-shelf, neutral, pollution free, and semantic addressing ready manner (cf. attached note). Our alternative is outside of their trap.

Actually, I have to thank the Unicode consortium members for having gallantly answered the challenge that I forced them into. They have far superior knowledge in the Unicode area compared to simple users such as us on that issue. We had to force them to document, from the horse's mouth, as to "why we were wrong and why they were right", and who was really concerned politically and why. We also needed their tables to be conveniently documented. We would never have obtained otherwise such precious material for ensuring that the Internet’s existing possibilities would permit the support of multilingualization as we know now it does.

jfc



For the convenience of the readers, the context is as follows:

1. There is a linguistic (semiotic) support pile wherein:

- Universalization consists in the neutral, equal, and technical support of every language, script, orthotypography (the way in which a culture will semantically interpret the way something is written) and quoting capacity of other languages, i.e. every existing language entity is fully supported and understood. Universalization is today commonly obtained through the use of metaconcepts being numerically transcoded. Further work in that area belongs to the semantic facilitation technologies.

- Multilingualization is the architectural approach that permits universalization through, for example, the globalization (cf. below) of every language. Its simplest support is provided by the presentation layer. As in all network architecture, the Internet includes a presentation layer. However, up to now its exploration and documentation were limited.

- Globalization is a method that is documented by Unicode that enables the reduction of the linguistic barriers between a given language and other natural languages. It involves (to this day):

--- the internationalization of the media by including the signs of every script (ex. Unicode). The NFC is a reduction of the Unicode list that can be utilized via the Internet. What is being discussed today is to attain a further reduction for the Internet namespace.
--- the localization of the other end, through the use of "locale" files.
--- the langtagging (permitting language filtering) of the content for the application’s benefit.

 
2. The CSoC

It so happens that the Unicode members seem to also benefit from a centralizing set of chances (CSoC) that could defeat the distributed nature of the world and of the Internet, and in turn sterilize the tremendous innovation capacity of the Internet presentation layer. This would be great for the present form of the Internet economy and governance that they dominate or participate in (stakeholders), which have not been properly prepared to cope with the impact of the activation of the presentation layer. This is why they are striving for innovation moratoria that they like to call the "status quo", in spite of the detriment that it represents for all the people.

A technical, business, and political status quo is permitted by the CSoC. By luck, the CSoC seems to result from porting globalization tasks within the multilingualization layer, something ASCII users fond convenient and with e-business favorable consequences. This layer violation limits the multilingualization layer to a single globalization occurrence: in this case, this is the ASCII English language globalization presentation.
 
This is technically an exceedingly unstable layer violation because it only rests on the subjective user acceptation to limit his/her Internet usage due to a misunderstanding. However, unexpectedly the CSoC happens to technically, commercially, and politically influence those who design, use, and manage the Internet in favor of such an auto-limitation. In particular, its constraints result in violations of the Internet neutrality that might make more difficult a deployment of the presentation layer (some 63 character DNS labels will be mapped to others, or to nil, upon the sole IETF engineering authority). This would equate to the machines and engineers (of some major corporations) to prevail on all the people of the world and their languages and culture. This is purely bad luck.
 

3. Interplus
 
Interplus comprises a two (interapplication and pseudo-network) layer transparent "post-wire" continuation (interplug) of the network on the user side. It completes the Internet architecture on an edge to edge basis (the network ends on the users side), in which now every user has an intelligent syste. This was not the case in 1983 when the Internet and DNS began.
 
The Interplus (interplugged layers on the user side system) includes a double interapplication networking capacity (through the Internet or through OPES [open pluggable edge services(*)] overlays) and an unlimited capacity for network interrelated services applications. (*) RFC
 
One of these services is to support presentations, i.e. the appearing change of the network to a qualified externet (an external network look alike within the Internet). The qualifications can include linguistic networks (the default being the English ASCII version), encryption, the support of other codes than Unicode or algorithms than punycode, etc. Presentations can be identified through label headers, (such as "xn--" for IDNA), TLD (as in the ".fra" experiment), classes, or a mix of them. Presentations are transparent to applications.
 
Another service is the support of the Domain Names Pile. This is a smart extension of the Host.txt possibility. The user name space can fully support the orthotypography of every language and trademarks through User/Universal Domain Names (UDN). UDNs will first be converted into Application Domain Names (ADNs) in order to relate with applications (such as Skype, authentication, payment services, etc.). If needed, they will in turn be converted into regular Domain Names (for example, through punycode). UDNs are independent from the Internet and can be used for application, TV, process resolution, IA, etc. As far as the Internet is concerned, IDNs (Internet Domain Names), as accepted and resolved by the DNS, are the reference. This reference should become universal and be read as based upon the 0-Z numbering set as well as the "." and "-" strong and weak separators.


(*)
RFC3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services 
RFC3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios
RFC3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols
RFC3835 An Architecture for Open Pluggable Edge Services (OPES)
RFC3837 Security Threats and Risks for Open Pluggable Edge Services (OPES) 
RFC3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)
RFC3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication
RFC3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations 
RFC4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core 
RFC4236 HTTP Adaptation with Open Pluggable Edge Services (OPES)
RFC4496 Open Pluggable Edge Services (OPES) SMTP Use Cases
RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP



--=====================_166693984==.ALT-- From jefsey@jefsey.com Thu Jul 16 19: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 3945028C255 for ; Thu, 16 Jul 2009 19:04:45 -0700 (PDT) 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=[AWL=-0.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 6tHTdINmOixV for ; Thu, 16 Jul 2009 19:04:43 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 9F61C28C24A for ; Thu, 16 Jul 2009 19:03:52 -0700 (PDT) Received: from 98.165.193-77.rev.gaoland.net ([77.193.165.98]:3847 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MRcoB-0002Ru-La; Thu, 16 Jul 2009 19:04:24 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Jul 2009 04:04:23 +0200 To: Lisa Dusseault , John C Klensin From: JFC Morfin In-Reply-To: References: <8CEF048B9EC83748B1517DC64EA130FB3C1A2BF4EF@off-win2003-01.ausregistrygroup.local> <4a5fa63b.1aba720a.6a02.3eccSMTPIN_ADDED@mx.google.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_180516343==.ALT" 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: <20090717020352.9F61C28C24A@core3.amsl.com> Cc: Pete Resnick , iucg@ietf.org Subject: Re: [iucg] Disallowing code 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, 17 Jul 2009 02:04:45 -0000 --=====================_180516343==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Lisa, John, I agree with Shawn Steel, let call a cat a cat. There are too many words being used without considering their whole implications. This is like just thinking over details instead of also taking care of the whole picture. I can't and I do not think it can be productive, moreover in a reticular system like the Internet? 1. When a character is DISALLOWED this means that one way or another if it used something is going to be discarded, i.e. that "something" is mapped to nil. The "something" may be a single code point or the whole domain name, or something in between - the application decides. The consequence is the same: loss of information and typographic bandwidth reduction. 2. I consider "protocol level" as a fundamental point indeed (I do not think the IESG and IAB use nearly meaningless phrases in a Charter, moreover when issuing strict conditions). If the Charter says "elimination of character mapping in the protocol" this may only mean one thing. That thing - as we understood it, and the reason we are waiting for Vint's plan to complete - is well documented in Pete Draft: the mapping is to happen outside of the protocol, i.e. not on the wire. Because what is involved is outside of the network control and of the IETF network territory. It is users' usage operation territory. This clearly translates in Pete's I_D: >This document describes the operations that can be First fundamental point: there is no MUST, this is consistent with the rest of the position. The only MUST is to be acceptable to the DNS. >applied to user input in order to get it into a form acceptable by >the Internationalized Domain Names in Applications (IDNA) protocol >[I-D.ietf-idnabis-protocol]. The document describes the underlying >architectural principles (in section 2 and the general >implementation procedure (in section 3). I class Patrick's document among the underlying architectural principles the WG is to define that "can be applied to user input" (meaning by the application). This is a BCP not a Standard. >It should be noted that this document does not specify the behavior >of a protocol that appears "on the wire". This conforms to the Charter. Character mapping of any kind MUST not appear on the wire, but off the wire. >It describes an operation that is to be applied to user input in >order to prepare that user input for use in an "on the network" protocol. All this clearly describe something which is outside the "on the network" protocol. > As unusual as this may be for an IETF protocol document, it is a > necessary operation to maintain interoperability. The text underlines that it is unusual and qualifies what is not part of the protocol as an operation. We have widely published that we are in agreement with the Charter and with this text. 3. The coup consists in trying to obtain URL indexing stability in invading and annexing that territory, my/our territory. And then starting rulling it, through MUSTs where interoperability calls for negociation based upon SHOULDs. If I want to make Tatweel resolve the IETF site, I just have to use the 1972 host.txt service, making the Tatweel code-point correspond to the IETF IP. What ever the way I can enter a tatweel and punycode it, it will work. If I try the same under IDNA2008, my entry will be mapped to nil and nothing will happen. I do not really call this innovation and progress in 37 years :-) Worse, I might also name it an alias/domain name conflict. Gee! I am on vacations ! jfc At 00:44 17/07/2009, Lisa Dusseault wrote: >1. I will wait until the WG *concludes* that it needs to take a >different approach than that described in its charter. Explorations >of different approaches are not contrary to the charter (although >the chair may rule such explorations out of scope and/or decide that >the WG came to consensus not to follow the different approach). > >2. I don't consider DISALLOWED to be a mapping to nil at all. There >is no requirement for clients to map DISALLOWED characters to nil >and then request a domain -- a client could reject a string with >DISALLOWED characters. Thus, even if the WG concludes to have >DISALLOWED characters, that does not depart from the charter- it was >very clear when the charter was written that some character classes >were to be DISALLOWED. > >In a similar light although this is a little off-topic, I would ask >you to relook at how people are using the phrase "at the protocol >level". Personally, I think it's nearly a meaningless phrase, and >I'm disappointed that so many arguments are focusing on whether >mappings are happening at the protocol level or not. But to the >extent that it has a meaning, I think your interpretation is not >quite the common one. Suggesting to user interface implementations >that they could offer alternatives to disallowed characters, to help >the user find the site they are looking for, is about as far from >"at the protocol level' as you can get. --=====================_180516343==.ALT Content-Type: text/html; charset="us-ascii" Lisa, John,
I agree with Shawn Steel, let call a cat a cat.  There are too many words being used without considering their whole implications. This is like just thinking over details instead of also taking care of the whole picture. I can't and I do not think it can be productive, moreover in a reticular system like the Internet?

1. When a character is DISALLOWED this means that one way or another if it used something is going to be discarded, i.e. that "something" is mapped to nil. The "something" may be a single code point or the whole domain name, or something in between - the application decides. The consequence is the same: loss of information and typographic bandwidth reduction.

2. I consider "protocol level" as a fundamental point indeed (I do not think the IESG and IAB use nearly meaningless phrases in a Charter, moreover when issuing strict conditions). If the Charter says "elimination of character mapping in the protocol" this may only mean one thing. That thing - as we understood it, and the reason we are waiting for Vint's plan to complete - is well documented in Pete Draft: the mapping is to happen outside of the protocol, i.e. not on the wire. Because what is involved is outside of the network control and of the IETF network territory. It is users' usage operation territory.

This clearly translates in Pete's I_D: 

This document describes the operations that can be

First fundamental point: there is no MUST, this is consistent with the rest of the position. The only MUST is to be acceptable to the DNS.

applied to user input in order to get it into a form acceptable by the Internationalized Domain Names in Applications (IDNA) protocol [I-D.ietf-idnabis-protocol]. The document describes the underlying architectural principles (in section 2 and the general implementation procedure (in section 3).

I class Patrick's document among the underlying architectural principles the WG is to define that "can be applied to user input" (meaning by the application). This is a BCP not a Standard.

It should be noted that this document does not specify the behavior of a protocol that appears "on the wire".

This conforms to the Charter. Character mapping of any kind MUST not appear on the wire, but off the wire.

It describes an operation that is to be applied to user input in order to prepare that user input for use in an "on the network" protocol.

All this clearly describe something which is outside the "on the network" protocol.

 As unusual as this may be for an IETF protocol document, it is a necessary operation to maintain interoperability.

The text underlines that it is unusual and qualifies what is not part of the protocol as an operation. We have widely published that we are in agreement with the Charter and with this text.

3. The coup consists in trying to obtain URL indexing stability in invading and annexing that territory, my/our territory. And then starting rulling it, through MUSTs where interoperability calls for negociation based upon SHOULDs. If I want to make Tatweel resolve the IETF site, I just have to use the 1972 host.txt service, making the Tatweel code-point correspond to the IETF IP. What ever the way I can enter a tatweel and punycode it, it will work. If I try the same under IDNA2008, my entry will be mapped to nil and nothing will happen. I do not really call this innovation and progress in 37 years :-) Worse, I might also name it an alias/domain name conflict.

Gee! I am on vacations !

jfc


At 00:44 17/07/2009, Lisa Dusseault wrote:
1.  I will wait until the WG *concludes* that it needs to take a different approach than that described in its charter.  Explorations of different approaches are not contrary to the charter (although the chair may rule such explorations out of scope and/or decide that the WG came to consensus not to follow the different approach).

2. I don't consider DISALLOWED to be a mapping to nil at all.  There is no requirement for clients to map DISALLOWED characters to nil and then request a domain -- a client could reject a string with DISALLOWED characters.  Thus, even if the WG concludes to have DISALLOWED characters, that does not depart from the charter- it was very clear when the charter was written that some character classes were to be DISALLOWED.

In a similar light although this is a little off-topic, I would ask you to relook at how people are using the phrase "at the protocol level".  Personally, I think it's nearly a meaningless phrase, and I'm disappointed that so many arguments are focusing on whether mappings are happening at the protocol level or not.  But to the extent that it has a meaning, I think your interpretation is not quite the common one.  Suggesting to user interface implementations that they could offer alternatives to disallowed characters, to help the user find the site they are looking for, is about as far from "at the protocol level' as you can get. 
--=====================_180516343==.ALT-- From jefsey@jefsey.com Thu Jul 16 19:09: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 AD6CB3A6D60 for ; Thu, 16 Jul 2009 19:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3yseqNtHO6KD for ; Thu, 16 Jul 2009 19:09:49 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id A27EA3A6E12 for ; Thu, 16 Jul 2009 19:09:47 -0700 (PDT) Received: from 98.165.193-77.rev.gaoland.net ([77.193.165.98]:3920 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MRctp-0003N6-E4; Thu, 16 Jul 2009 19:10:15 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Jul 2009 04:10:13 +0200 To: Lisa Dusseault , John C Klensin From: JFC Morfin In-Reply-To: References: <8CEF048B9EC83748B1517DC64EA130FB3C1A2BF4EF@off-win2003-01.ausregistrygroup.local> <4a5fa63b.1aba720a.6a02.3eccSMTPIN_ADDED@mx.google.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: <20090717020947.A27EA3A6E12@core3.amsl.com> Cc: Pete Resnick , iucg@ietf.org Subject: Re: [iucg] Disallowing code 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, 17 Jul 2009 02:09:50 -0000 I forgot a point. At 00:44 17/07/2009, Lisa Dusseault wrote: >Suggesting to user interface implementations that they could offer >alternatives to disallowed characters, to help the user find the >site they are looking for, is about as far from "at the protocol >level' as you can get. Yes. But "suggesting" is not carried in using MUSTs (while SHOULD is acceptabe). This is why I am OK with everything that has no other MUST than DNS respect and resolvability. Because the user may want to use tatweel. It is also illusory to use a MUST: how are you going to enforce it? jfc From lisa.dusseault@gmail.com Thu Jul 16 15:44: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 6731A3A6C82 for ; Thu, 16 Jul 2009 15:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.013 X-Spam-Level: X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=-0.415, 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 foo6O5TRJmMd for ; Thu, 16 Jul 2009 15:44:13 -0700 (PDT) Received: from mail-vw0-f184.google.com (mail-vw0-f184.google.com [209.85.212.184]) by core3.amsl.com (Postfix) with ESMTP id 062A83A69AB for ; Thu, 16 Jul 2009 15:43:49 -0700 (PDT) Received: by vwj14 with SMTP id 14so472175vwj.29 for ; Thu, 16 Jul 2009 15:44:20 -0700 (PDT) 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=JsYhqandE1/nJa0ophZNMYHcEUYLUERmZ20we9UayeM=; b=dF+wyUP7ukfTWNbP3nb7Q2PRWs0Wg2eRDiM1JA3vSgABKMn6edJ/ngUz0F7LwTBtXT vhnFdIav1g/Uy4FOhjxtHTppgFBC5H8yS5WZ4L6Fc6w37I9P+sWx/leGxQoPvjPifej5 IAJjbh3ARjqH7F+U1Jghd36dG8l/dlU7ZuWRQ= 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=GiN1gYryjxVUC+bUYkcvJ1Oy24PGQGJ9nrEHgecbJsPz9dXChSBlELtgjlKLBIDym5 g7SKxpequo/oWYSNM3TVj2GS/3FHUj2Z4EzuXes5jXpCWd5CghY8mWnHDWkgZXnTYa3v 9DXiKjOO9rLOG78a7GC9FFzZO7fSwrh5utrlI= MIME-Version: 1.0 Received: by 10.220.93.65 with SMTP id u1mr538233vcm.58.1247784260650; Thu, 16 Jul 2009 15:44:20 -0700 (PDT) In-Reply-To: <4a5fa63b.1aba720a.6a02.3eccSMTPIN_ADDED@mx.google.com> References: <8CEF048B9EC83748B1517DC64EA130FB3C1A2BF4EF@off-win2003-01.ausregistrygroup.local> <4a5fa63b.1aba720a.6a02.3eccSMTPIN_ADDED@mx.google.com> Date: Thu, 16 Jul 2009 15:44:20 -0700 Message-ID: From: Lisa Dusseault To: JFC Morfin Content-Type: multipart/alternative; boundary=0016364ed3869cc67d046eda69c7 X-Mailman-Approved-At: Thu, 16 Jul 2009 19:10:33 -0700 Cc: iucg@ietf.org Subject: Re: [iucg] Disallowing code 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: Thu, 16 Jul 2009 22:44:15 -0000 --0016364ed3869cc67d046eda69c7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I've CC'ed Vint on this response to your request to have the WG recharter. I'm very aware of the charter text that requires the WG to recharter, and I'm keeping an eye on that. I will certainly press the WG to modify its charter if it concludes that a different approach from that described in th= e charter. However, I am interpreting some things in a somewhat different light than you. 1. I will wait until the WG *concludes* that it needs to take a different approach than that described in its charter. Explorations of different approaches are not contrary to the charter (although the chair may rule suc= h explorations out of scope and/or decide that the WG came to consensus not t= o follow the different approach). 2. I don't consider DISALLOWED to be a mapping to nil at all. There is no requirement for clients to map DISALLOWED characters to nil and then reques= t a domain -- a client could reject a string with DISALLOWED characters. Thus, even if the WG concludes to have DISALLOWED characters, that does not depart from the charter- it was very clear when the charter was written tha= t some character classes were to be DISALLOWED. In a similar light although this is a little off-topic, I would ask you to relook at how people are using the phrase "at the protocol level". Personally, I think it's nearly a meaningless phrase, and I'm disappointed that so many arguments are focusing on whether mappings are happening at th= e protocol level or not. But to the extent that it has a meaning, I think your interpretation is not quite the common one. Suggesting to user interface implementations that they could offer alternatives to disallowed characters, to help the user find the site they are looking for, is about a= s far from "at the protocol level' as you can get. Thank-you, Lisa Dusseault On Thu, Jul 16, 2009 at 3:14 PM, JFC Morfin wrote: > *At 13:42 16/07/2009, Vint Cerf wrote: > * > > The problem we foresee is that not all registry operators (remember this = is > not just at top or second level but all through the hierarchy) will show = the > same diligence. *So the most troubling cases can be excluded by protocol= . > * > > > *The Charter says: > > The WG will stop work and recommend that a new charter be generated > > * if it concludes that any of the following are necessary to meet its > goals: (iii) A change to the basic approach taken in the design team > documents (Namely: independence from Unicode version and *elimination of > character mapping in the protocol*) > > DISALLOWing being a "mapping to nil", here voluntarily included in the > protocol,* I hereby formally request that this WG stops all work and a ne= w > charter is subsequently generated.* > > > *However,* as expressed in my mail sent yesterday, I fully realize that w= e > are currently in the process of a coup by Unicode members. They are simpl= y > trying to force a new extension of their "globalization" doctrine layer > violation (cf. attached note). They actually maneuvered just as we had > foresaw, including utilizing us. The alternative they propose is: > > (1) either the IETF will accept their control over the Internet linguisti= c > architecture > (2) or they will claim that some people, like myself and IUCG@IETFmembers= , are delaying the "overwhelming consensus" that they have > identified, and in turn make topics of the future, such as the sex of the > glyphs, a priority. As a result, they have been forced to proceed > independently. > > This is exactly why I will not appeal now against a negative or > non-response from you: I prefer the regular IETF/LC to apply first. I, > therefore, shall leave them with the responsibility to modify the Interne= t > architecture as well as *to introduce constraints in favor of a business > interest group vs. the rest of the world languages, cultures, and nations= *. > However, I will quote this mail in my appeal should the IETF/LC fail to > protect the Internet neutrality the WG-IDNABIS Charter adequately protect= s. > (May I remind you that I will not participate to the WG/LC and to the IET= F > due to other maneuvers of the same influence group, in the same lengthy > opposition they have to the people' interests I try to defend). As far as= I > am concerned, when back from vacations, I will continue to support the IU= CG, > so it may proceed with its user documentation of the way the existing > Internet architecture does address the "multilingualization" they need, i= n > an adequate, open, cross-technology, presentation layer based, > off-the-shelf, neutral, pollution free, and semantic addressing ready man= ner > (cf. attached note). Our alternative is outside of their trap. > > Actually,* I have to thank the Unicode consortium members *for having > gallantly answered the challenge that I forced them into. They have far > superior knowledge in the Unicode area compared to simple users such as u= s > on that issue. We had to force them to document, from the horse's mouth, = as > to "why we were wrong and why they were right", and who was really concer= ned > politically and why. We also needed their tables to be conveniently > documented. We would never have obtained otherwise such precious material > for ensuring that the Internet=92s existing possibilities would permit th= e > support of multilingualization as we know now it does. > > jfc > > > > For the convenience of the readers, the context is as follows: > > *1. There is a linguistic (semiotic) support pile wherein*: > > - *Universalization* consists in the neutral, equal, and technical suppor= t > of every language, script, orthotypography (the way in which a culture wi= ll > semantically interpret the way something is written) and quoting capacity= of > other languages, i.e. every existing language entity is fully supported a= nd > understood. Universalization is today commonly obtained through the use o= f > metaconcepts being numerically transcoded. Further work in that area belo= ngs > to the semantic facilitation technologies. > > *- Multilingualization* is the architectural approach that permits > universalization through, for example, the globalization (cf. below) of > every language. Its simplest support is provided by the presentation laye= r. > As in all network architecture, the Internet includes a presentation laye= r. > However, up to now its exploration and documentation were limited. > > - *Globalization* is a method that is documented by Unicode that enables > the reduction of the linguistic barriers between a given language and oth= er > natural languages. It involves (to this day): > > --- the *internationalization *of the media by including the signs of > every script (ex. Unicode). The NFC is a reduction of the Unicode list th= at > can be utilized via the Internet. What is being discussed today is to att= ain > a further reduction for the Internet namespace. > --- the *localization *of the other end, through the use of "locale" > files. > --- the *langtagging *(permitting language filtering) of the content for > the application=92s benefit. > > > *2. The CSoC > > *It so happens that the Unicode members seem to also benefit from a * > centralizing* set of chances (*CSoC*) that could defeat the *distributed = *nature > of the world and of the Internet, and in turn sterilize the tremendous > innovation capacity of the Internet presentation layer. This would be gre= at > for the present form of the Internet economy and governance that they > dominate or participate in (stakeholders), which have not been properly > prepared to cope with the impact of the activation of the presentation > layer. This is why they are striving for innovation moratoria that they l= ike > to call the "status quo", in spite of the detriment that it represents fo= r > all the people. > > A technical, business, and political status quo is permitted by the CSoC. > By luck, the CSoC seems to result from porting globalization tasks within > the multilingualization layer, something ASCII users fond convenient and > with e-business favorable consequences. This layer violation limits the > multilingualization layer to a single globalization occurrence: in this > case, this is the ASCII English language globalization presentation. > > This is technically an exceedingly unstable layer violation because it on= ly > rests on the subjective user acceptation to limit his/her Internet usage = due > to a misunderstanding. However, unexpectedly the CSoC happens to > technically, commercially, and politically influence those who design, us= e, > and manage the Internet in favor of such an auto-limitation. In particula= r, > its constraints result in violations of the Internet neutrality that migh= t > make more difficult a deployment of the presentation layer (some 63 > character DNS labels will be mapped to others, or to nil, upon the sole I= ETF > engineering authority). This would equate to the machines and engineers (= of > some major corporations) to prevail on all the people of the world and th= eir > languages and culture. This is purely bad luck. > > > *3. Interplus > * > Interplus comprises a two (interapplication and pseudo-network) layer > transparent "post-wire" continuation (interplug) of the network on the us= er > side. It completes the Internet architecture on an edge to edge basis (th= e > network ends on the users side), in which now every user has an intellige= nt > syste. This was not the case in 1983 when the Internet and DNS began. > > The Interplus (interplugged layers on the user side system) includes a > double interapplication networking capacity (through the Internet or thro= ugh > OPES [open pluggable edge services(*)] overlays) and an unlimited capacit= y > for network interrelated services applications. (*) RFC > > One of these services is to support* presentations*, i.e. the appearing > change of the network to a qualified externet (an external network look > alike within the Internet). The qualifications can include linguistic > networks (the default being the English ASCII version), encryption, the > support of other codes than Unicode or algorithms than punycode, etc. > Presentations can be identified through label headers, (such as "xn--" fo= r > IDNA), TLD (as in the ".fra" experiment), classes, or a mix of them. > Presentations are transparent to applications. > > Another service is the support of the *Domain Names Pile*. This is a smar= t > extension of the Host.txt possibility. The user name space can fully supp= ort > the orthotypography of every language and trademarks through User/Univers= al > Domain Names (UDN). UDNs will first be converted into Application Domain > Names (ADNs) in order to relate with applications (such as Skype, > authentication, payment services, etc.). If needed, they will in turn be > converted into regular Domain Names (for example, through punycode). UDNs > are independent from the Internet and can be used for application, TV, > process resolution, IA, etc. As far as the Internet is concerned, IDNs > (Internet Domain Names), as accepted and resolved by the DNS, are the > reference. This reference should become universal and be read as based up= on > the 0-Z numbering set as well as the "." and "-" strong and weak separato= rs. > > > > (*) > RFC3238 IAB Architectural and Policy Considerations for Open Pluggable Ed= ge > Services > RFC3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment > Scenarios > RFC3836 Requirements for Open Pluggable Edge Services (OPES) Callout > Protocols > RFC3835 An Architecture for Open Pluggable Edge Services (OPES) > RFC3837 Security Threats and Risks for Open Pluggable Edge Services (OPES= ) > > RFC3838 Policy, Authorization, and Enforcement Requirements of the Open > Pluggable Edge Services (OPES) > RFC3897 Open Pluggable Edge Services (OPES) Entities and End Points > Communication > RFC3914 Open Pluggable Edge Services (OPES) Treatment of IAB > Considerations > RFC4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core > RFC4236 HTTP Adaptation with Open Pluggable Edge Services (OPES) > RFC4496 Open Pluggable Edge Services (OPES) SMTP Use Cases > RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge Services > (OPES) for SMTP > > > > --0016364ed3869cc67d046eda69c7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

I've CC'ed Vint on this response to your request to have the WG rec= harter.=A0

I'm very aware of the charter text that requires the WG to recharter, and I'm keeping an eye on that.=A0 I will certainly press the WG to modify its charter if it concludes that a different approach from that described in the charter.

However, I am interpreting some things in a somewhat different light than y= ou.

1.=A0 I will wait until the WG *concludes* that it needs to take a different approach than that described in its charter.=A0 Explorations of different approaches are not contrary to the charter (although the chair may rule such explorations out of scope and/or decide that the WG cam= e to consensus not to follow the different approach).

2. I don't consider DISALLOWED to be a mapping to nil at all.=A0 There = is no requirement for clients to map DISALLOWED characters to nil and then request a domain -- a client could reject a string with DISALLOWED characters.=A0 Thus, even if the WG concludes to have DISALLOWED characters, that does not depart from the charter- it was very clear when the charter was written that some character classes were to be DISALLOWED.

In a similar light although this is a little off-topic, I would ask you to = relook at how people are using the phrase "at the protocol level".=A0 Personally, I think it's n= early a meaningless phrase, and I'm disappointed that so many arguments are foc= using on whether mappings are happening at the protocol level or not.=A0 But to the extent that it has a meaning, I think your interpretation is not quite the common one.=A0 Suggesting to user interface implementations that they could offer alternatives to disallowed characters, to help the user find the site they are looking for, is about as far from "at the protocol level' as you can get.= =A0

Thank-you,
Lisa Dusseault

On Thu, Jul 16, 2009 at 3:= 14 PM, JFC Morfin <jefsey@jefsey.com> wrote:
At 13:42 16/07/2009, Vint Cerf wrote:
The problem we foresee is that not all registry operators (remember this is not just at top or second level but all through the hierarchy) will show the same diligence. So=A0 the most troubling cases can be excluded by protocol.

The Charter says:
The WG will stop work and recommend that a new charter be generated
 if it concludes = that any of the following are necessary to meet its goals: (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and elimination of character mapping in the protocol)

DISALLOWing being a "mapping to nil", here voluntarily included in the protocol, I hereby formally request that this WG stops all work and a new charter is subsequently generated.


However, as expressed in my mail sent yesterday, I fully realize that we are currently in the process of a coup by Unicode members. They are simply trying to force a new extension of their "globalization" doctrine layer violation (cf. attached note). They actually maneuvered just as we had foresaw, including utilizing us. The alternative they propose is:
=A0
(1) either the IETF will accept their control over the Internet linguistic architecture
(2) or they will claim that some people, like myself and IUCG@IETF members, are delaying the "overwhelming consensus" that they have identified, and in turn make topics of the future, such as the sex of the glyphs, a priority. As a result, they have been forced to proceed independently.

This is exactly why I will not appeal now against a negative or non-response from you: I prefer the regular IETF/LC to apply first. I, therefore, shall leave them with the responsibility to modify the Internet architecture as well as to introduce constraints in favor of a business interest group vs. the rest of the world languages, cultures, and nations. However, I will quote this mail in my appeal should the IETF/LC fail to protect the Internet neutrality the WG-IDNABIS Charter adequately protects. (May I remind you that I will not participate to the WG/LC and to the IETF due to other maneuvers of the same influence group, in the same lengthy opposition they have to the people' interests I try to defend). As far as I am concerned, when back from vacations, I will continue to support the IUCG, so it may proceed with its user documentation of the way the existing Internet architecture does address the "multilingualization" they need, in an adequate, open, cross-technology, presentation layer based, off-the-shelf, neutral, pollution free, and semantic addressing ready manner (cf. attached note). Our alternative is outside of their trap.

Actually, I have to thank the Unicode consortium members for having gallantly answered the challenge that I forced them into. They have far superior knowledge in the Unicode area compared to simple users such as us on that issue. We had to force them to document, from the horse's mouth, as to "why we were wrong and why they were right", and who was really concerned politically and why. We also needed their tables to be conveniently documented. We would never have obtained otherwise such precious material for ensuring that the Internet=92s existing possibilities would permit the support of multilingualization as we know now it does.

jfc



For the convenience of the readers, the context is as follows:

1. There is a linguistic (semiotic) support pile wherein:

- Universalization consists in the neutral, equal, and technical support of every language, script, orthotypography (the way in which a culture will semantically interpret the way something is written) and quoting capacity of other languages, i.e. every existing language entity is fully supported and understood. Universalization is today commonly obtained through the use of metaconcepts being numerically transcoded. Further work in that area belongs to the semantic facilitation technologies.

- Multilingualization is the architectural approach that permits universalization through, for example, the globalization (cf. below) of every language. Its simplest support is provided by the presentation layer. As in all network architecture, the Internet includes a presentation layer. However, up to now its exploration and documentation were limited.

- Globalization is a method that is documented by Unicode that enables the reduction of the linguistic barriers between a given language and other natural languages. It involves (to this day):

--- the internationalization of the media by including the signs of every script (ex. Unicode). The NFC is a reduction of the Unicode list that can be utilized via the Internet. What is being discussed today is to attain a further reduction for the Internet namespace.
--- the localization of the other end, through the use of "locale" files.
--- the langtagging (permitting language filtering) of the content for the application=92s benefit.

=A0
2. The CSoC

It so happens that the Unicode members seem to also benefit from a centralizing set of chances (CSoC) that could defeat the distributed nature of the world and of the Internet, and in turn sterilize the tremendous innovation capacity of the Internet presentation layer. This would be great for the present form of the Internet economy and governance that they dominate or participate in (stakeholders), which have not been properly prepared to cope with the impact of the activation of the presentation layer. This is why they are striving for innovation moratoria that they like to call the "status quo", in spite of the detriment that it represents for all the people.

A technical, business, and political status quo is permitted by the CSoC. By luck, the CSoC seems to result from porting globalization tasks within the multilingualization layer, something ASCII users fond convenient and with e-business favorable consequences. This layer violation limits the multilingualization layer to a single globalization occurrence: in this case, this is the ASCII English language globalization presentation.
=A0
This is technically an exceedingly unstable layer violation because it only rests on the subjective user acceptation to limit his/her Internet usage due to a misunderstanding. However, unexpectedly the CSoC happens to technically, commercially, and politically influence those who design, use, and manage the Internet in favor of such an auto-limitation. In particular, its constraints result in violations of the Internet neutrality that might make more difficult a deployment of the presentation layer (some 63 character DNS labels will be mapped to others, or to nil, upon the sole IETF engineering authority). This would equate to the machines and engineers (of some major corporations) to prevail on all the people of the world and their languages and culture. This is purely bad luck.
=A0

3. Interplus
=A0
Interplus comprises a two (interapplication and pseudo-network) layer transparent "post-wire" continuation (interplug) of the network on the user side. It completes the Internet architecture on an edge to edge basis (the network ends on the users side), in which now every user has an intelligent syste. This was not the case in 1983 when the Internet and DNS began.
=A0
The Interplus (interplugged layers on the user side system) includes a double interapplication networking capacity (through the Internet or through OPES [open pluggable edge services(*)] overlays) and an unlimited capacity for network interrelated services applications. (*) RFC
=A0
One of these services is to support presentations, i.e. the appearing change of the network to a qualified externet (an external network look alike within the Internet). The qualifications can include linguistic networks (the default being the English ASCII version), encryption, the support of other codes than Unicode or algorithms than punycode, etc. Presentations can be identified through label headers, (such as "xn--" for IDNA), TLD (as in the ".fra" experiment), classes, or a mix of them. Presentations are transparent to applications.
=A0
Another service is the support of the Domain Names Pile. This is a smart extension of the Host.txt possibility. The user name space can fully support the orthotypography of every language and trademarks through User/Universal Domain Names (UDN). UDNs will first be converted into Application Domain Names (ADNs) in order to relate with applications (such as Skype, authentication, payment services, etc.). If needed, they will in turn be converted into regular Domain Names (for example, through punycode). UDNs are independent from the Internet and can be used for application, TV, process resolution, IA, etc. As far as the Internet is concerned, IDNs (Internet Domain Names), as accepted and resolved by the DNS, are the reference. This reference should become universal and be read as based upon the 0-Z numbering set as well as the "." and "-" strong and weak separators.


(*)
RFC3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services=A0
RFC3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios
RFC3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols
RFC3835 An Architecture for Open Pluggable Edge Services (OPES)
RFC3837 Security Threats and Risks for Open Pluggable Edge Services (OPES)=A0
RFC3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)
RFC3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication
RFC3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations=A0
RFC4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core=A0
RFC4236 HTTP Adaptation with Open Pluggable Edge Services (OPES)
RFC4496 Open Pluggable Edge Services (OPES) SMTP Use Cases
RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP




--0016364ed3869cc67d046eda69c7-- From john@jck.com Thu Jul 16 15:58: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 987493A69AB for ; Thu, 16 Jul 2009 15:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 f4HXAUwGoRME for ; Thu, 16 Jul 2009 15:58:36 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id CB7F53A688C for ; Thu, 16 Jul 2009 15:58:35 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MRZus-000CL4-Ab; Thu, 16 Jul 2009 18:59:06 -0400 Date: Thu, 16 Jul 2009 18:59:05 -0400 From: John C Klensin To: JFC Morfin , Lisa Dusseault Message-ID: <9DB9660E2D2AF1EBB02E5A44@PST.JCK.COM> References: <8CEF048B9EC83748B1517DC64EA130FB3C1A2BF4EF@off-win2003-01.ausregistrygroup.local> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Thu, 16 Jul 2009 19:10:33 -0700 Cc: iucg@ietf.org Subject: Re: [iucg] Disallowing code 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: Thu, 16 Jul 2009 22:58:36 -0000 --On Friday, July 17, 2009 00:14 +0200 JFC Morfin wrote: > DISALLOWing being a "mapping to nil", here voluntarily > included in the protocol, I hereby formally request that this > WG stops all work and a new charter is subsequently generated. Disallowing is _not_ "mapping to nil". It is a simple prohibition of the use of the code point (I'm reluctant to say "character" here) in DNS labels. While there were some mappings to nil in IDNA2003, we have eliminated all of them (despite a few objections from some of the Unicode folks) in IDNA2008. I believe any attempt to revisit those decisions will meet very strong resistance from the WG (or at least from me). It would help with this process if you would read the documents carefully enough to know what you are talking about. regards, john From eblanconil@gmail.com Fri Jul 17 02:57:39 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 DE3FD3A6E61 for ; Fri, 17 Jul 2009 02:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, 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 rlzVOPb4uks5 for ; Fri, 17 Jul 2009 02:57:38 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id A264A3A6AE1 for ; Fri, 17 Jul 2009 02:57:38 -0700 (PDT) Received: by fxm18 with SMTP id 18so625930fxm.37 for ; Fri, 17 Jul 2009 02:58:09 -0700 (PDT) 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 :content-transfer-encoding; bh=F2wbvktW90isC3DLWPr7EPAPlI1J9PPs9BNA+qhyASs=; b=Omg95Ufv2cOhRiu4t430oNlkClYAgFGnCrlmyoou59LOEQgxVPK5+RgWvNBpp0Ty69 jNJklAhyZFCSo48ZxW5yBBVq2DSoKr1old+zGpMmPsqgot6kukNsaT69f0i3Ms9hx2lM m3p4ZRxYdRrf2hMWQtQxQr6zUdGKI0n/5xJwM= 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:content-transfer-encoding; b=lM5iObMmdPmitgDD6zoChWXirq32UR+ZgkldEFsMu/FADCgPxr5YJhQf0QVjfbbjan dwSdyjAv/DBloPmbvUQrbbY6vnYz8fMOty4pVd1v6vrGp6stGhIEYEt997GN22AB8z6J +NWrpyUT8gUM1qN58p2P7qcpVVVgsMe3KDFdo= MIME-Version: 1.0 Received: by 10.239.179.19 with SMTP id b19mr85767hbg.2.1247824689021; Fri, 17 Jul 2009 02:58:09 -0700 (PDT) In-Reply-To: <4A5F927D.2070407@mozilla.org> References: <30b660a20907161028g649894c2u476a0d723ea5df2a@mail.gmail.com> <4A5F927D.2070407@mozilla.org> Date: Fri, 17 Jul 2009 11:58:08 +0200 Message-ID: <6589127a0907170258v62fd631dh86e3f5331e663d95@mail.gmail.com> From: Elisabeth Blanconil To: Gervase Markham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= , idna-update@alvestrand.no, internet users contributing group Subject: Re: [iucg] IDNA Comparisons 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, 17 Jul 2009 09:57:39 -0000 This is a general semiotic issue. As long as a technical inability obliges to a discrimination law considers it as an act of God. There is no other technical limitation here than an act of Unicode. The law will most probly not buy it, moreover if legal experts testify that the presentation layer in network architecture is precisely the multiple code support layer. This case is adequately discussed in the mapping document. Elisabeth Blanconil 2009/7/16 Gervase Markham : > On 16/07/09 13:28, Mark Davis =E2=8C=9B wrote: >> I put together a table that shows the assignments made by IDNA2008 and >> IDNA2003, respectively. I would urge people to review these for problems >> before Stockholm. For example, do we particularly want a hue and cry >> from the blind community because the rules exclude Braille? > > Braille is, according to my limited understanding, a method for encoding > another character set in a form readable by people without sight. (The > version I know of encodes something pretty like ASCII, but perhaps in > other places in the world there are other versions encoding other > character sets.) I therefore can't see why one would want Braille domain > names; surely one would create the domain names in the character set in > question, and convert that to Braille on output (e.g. using Braille TTY)? > > Gerv > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > From jefsey@jefsey.com Fri Jul 17 05:05:47 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 D101B3A6E83 for ; Fri, 17 Jul 2009 05:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 fQQ2kWnDbek8 for ; Fri, 17 Jul 2009 05:05:46 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 25FD83A6E82 for ; Fri, 17 Jul 2009 05:05:46 -0700 (PDT) Received: from 98.165.193-77.rev.gaoland.net ([77.193.165.98]:1919 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MRmCX-0008TY-3N; Fri, 17 Jul 2009 05:06:10 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Jul 2009 14:06:02 +0200 To: John C Klensin , Lisa Dusseault From: JFC Morfin In-Reply-To: <1D5C4004CDCE63B318C0DFC4@PST.JCK.COM> References: <8CEF048B9EC83748B1517DC64EA130FB3C1A2BF4EF@off-win2003-01.ausregistrygroup.local> <4a5fa63b.1aba720a.6a02.3eccSMTPIN_ADDED@mx.google.com> <1D5C4004CDCE63B318C0DFC4@PST.JCK.COM> 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: <20090717120546.25FD83A6E82@core3.amsl.com> Cc: Pete Resnick , iucg@ietf.org Subject: Re: [iucg] Disallowing code 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, 17 Jul 2009 12:05:47 -0000 At 05:36 17/07/2009, John C Klensin wrote: >--On Friday, July 17, 2009 04:04 +0200 JFC Morfin > wrote: > > > Lisa, John, > > I agree with Shawn Steel, let call a cat a cat. There are too > > many words being used without considering their whole > > implications. This is like just thinking over details instead > > of also taking care of the whole picture. I can't and I do not > > think it can be productive, moreover in a reticular system > > like the Internet? > >I think it is precisely the whole picture that we are concerned >about. The whole, global identifier, picture, not one country >or language group at a time. Dear John, from 40 years experience in navy, communications and policy this is the fundamental issue the world has with the american culture and language. It is not an opposition. It is a built-in misunderstanding. The understanding of the string "global" is opposed. This is the core of the IDNA issue. In American English "global" means the entire Globe. In British English, French and other languages "global" means all the parts of the same Globe. For example, someone like José Bové fiercely stands for smart globalisation against imposed globalization. Globalisation is a fact that the Internet technically supports, globalization ("mondialisme" in French) is a policy using the Internet to propagate, in particular by standardisation infuence (cf. RFC 3935). There is an inner contradiction in your sentence that we meet here. The intended proposition is unilateral while reality is diverse, i.e. we care about the sum of all the countries, languages, and people. This translates very simply: the ISOC motto is user centric. The WSIS objective is people centric. Technical totalitarism is the difference : users go by the user guide. People go by their informed free-will. Pete's document is unilateral and as such it can only apply to one single presentation. However, it is flexible enough (SHOULDs and MAYs) to accomodate a legitimate diversity. So, it is a reasonable compromise against both rigidity and laxism. > > 1. When a character is DISALLOWED this means that one way or > > another if it used something is going to be discarded, i.e. > > that "something" is mapped to nil. The "something" may be a > > single code point or the whole domain name, or something in > > between - the application decides. The consequence is the > > same: loss of information and typographic bandwidth reduction. > >Again, no. If a character is DISALLOWED, then the string that >it contains is prohibited at a label, is not looked up, and, I >hope results in a message to the user that it is invalid. That >has nothing to do with discarding all or part of the string and >then looking something else (or a subset) up. The latter would >be a clear violation of the protocol. I do not refer to any protocol. I refer to the relation between the user and the proposed system. I refer also to the way I would/have implement the code and the answered error message. Let keep it simple in using a common metric to the people/process involved. This is what I call detail vs. the global diversity of the whole picture. > > 2. I consider "protocol level" as a fundamental point indeed > > (I do not think the IESG and IAB use nearly meaningless > > phrases in a Charter, moreover when issuing strict > > conditions). If the Charter says "elimination of character > > mapping in the protocol" this may only mean one thing. That > > thing - as we understood it, and the reason we are waiting for > > Vint's plan to complete - is well documented in Pete Draft: > > the mapping is to happen outside of the protocol, i.e. not on > > the wire. Because what is involved is outside of the network > > control and of the IETF network territory. It is users' usage > > operation territory. > >Yes. We actually agree about that. But it has nothing to do >with which characters are DISALLOWED, which the mapping document >carefully does not touch. It has to do with who (IETF or User) disallows and under which constraint/advise (SHOULD or MUST). > > This clearly translates in Pete's I_D: > > > >> This document describes the operations that can be > > > > First fundamental point: there is no MUST, this is consistent > > with the rest of the position. The only MUST is to be > > acceptable to the DNS. > >No. The MUST is to be consistent with the core IDNA2008 specs, >which include consistency with the DNS. And that is exactly >what the rest of the sentence says. OK: what are the other constraints made necessary by the IDNA2008 Mapping document? Except IDNA2003 I do not discuss. > >> applied to user input in order to get it into a form > >> acceptable by the Internationalized Domain Names in > >> Applications (IDNA) protocol [I-D.ietf-idnabis-protocol]. > >> The document describes the underlying architectural > >> principles (in section 2 and the general implementation > >> procedure (in section 3). > > > > I class Patrick's document among the underlying architectural > > principles the WG is to define that "can be applied to user > > input" (meaning by the application). This is a BCP not a > > Standard. > >If, by "Patrick's (sic) document" you mean >draft-ietf-idnabis-tables, it is referenced normatively from >Protocol and is a core part of the Standards-Track IDNA2008 >specification, not a BCP. As long as the mapping document does not make it a MUST it can legitimately be optionnal at User's decision. In such a case the User will use it as a Unicode related BCP. Actually, as I say it is an NFC restriction, NFC being itself a Unicode restriction. At the end of the day we will obtain a more restricted version of the visually based alternative to Unicode I wanted. > >> It should be noted that this document does not specify the > >> behavior of a protocol that appears "on the wire". > > > > This conforms to the Charter. Character mapping of any kind > > MUST not appear on the wire, but off the wire. > >Sure. But, strictly speaking, IDNA does not appear on the wire. >Only A-labels do. That has been the source of a lot of >confusion. Note that the IRI document, which is well outside >the WG's scope, does refer to IRIs as protocol elements, which >pushes them into the "on the wire" category, including their IDN >components. This is a topology closure problem. You can define the end of a protocol where you want, including using a virtual wire. A protocol is univesal. Here we deal with the edges (network and user sides), i.e. with a global issue. In other words, the border between the network and the user is not a line, it is thick. This thickness is the Interplus. It can be supported via OPES if to keep with IETF documentation. Actually networked OPES I call ONES for a few decades (Open Network Extended Services). My Tymnet 1985 department. > >> It describes an operation that is to be applied to user input > >> in order to prepare that user input for use in an "on the > >> network" protocol. > > > > All this clearly describe something which is outside the "on > > the network" protocol. > >Yes. So? > > >> As unusual as this may be for an IETF protocol document, it > >> is a necessary operation to maintain interoperability. > > > > The text underlines that it is unusual and qualifies what is > > not part of the protocol as an operation. We have widely > > published that we are in agreement with the Charter and with > > this text. > >Ok. So we are arguing about what? > > > 3. The coup consists in trying to obtain URL indexing > > stability in invading and annexing that territory, my/our > > territory. And then starting rulling it, through MUSTs where > > interoperability calls for negociation based upon SHOULDs. If > > I want to make Tatweel resolve the IETF site, I just have to > > use the 1972 host.txt service, making the Tatweel code-point > > correspond to the IETF IP. What ever the way I can enter a > > tatweel and punycode it, it will work. If I try the same under > > IDNA2008, my entry will be mapped to nil and nothing will > > happen. I do not really call this innovation and progress in > > 37 years :-) Worse, I might also name it an alias/domain name > > conflict. > >There is no coup and the above is either a misinterpretation or >outside the WG's scope. It is out the WG technical scope. By nature, and because the Charter says so. This is why we do not support the coup and support the Charter. Actually I do not bother about WG scopes, I bother about what hurts me. I bother about Charters only because I consider it as a contract every party said it will respect. >URIs are prohibited from containing >non-ASCII domain names -- I believe globally although there are >some factions who believe that such names can be included in >%-escaped UTF-8 in those fields. In my daily life I never meet an URI, but would I, I would be hurt the same in understanding what they may refer to if the orthotypography is wrong. >And you can't use the 1972 Hosts.TXT service because it was shut >down long ago. More important, it was strictly limited >--technically and administratively-- to ASCII letters, digits, >and hyphens, so there is no way to express a Tatweel in those >tables. I keep using "http://nuts" to access ICANN's site. Hosts.txt works perfeclty well with punycoded entries. >In IDNA2008, you simply cannot express Tatweel in a label so, in >that narrow sense, the behavior under the Hosttable rules and >that under IDNA2008 is identical. For the time being I do not know what IDNA2008 is going to be. But I am pretty sure that Pouzin's keyword service can support tatweel. > > Gee! I am on vacations ! > >Yeah. And I'm trying to retire. I am suppose to retire on oct. 7th (in France they become less rigid, so I am creating a new business) Best jfc > > At 00:44 17/07/2009, Lisa Dusseault wrote: > >... > >> 2. I don't consider DISALLOWED to be a mapping to nil at all. > >> There is no requirement for clients to map DISALLOWED > >> characters to nil and then request a domain -- a client > >> could reject a string with DISALLOWED characters. > >Indeed, I think the client is required to do so and that simply >mapping a DISALLOWED character to nothing would be a violation >of the specification. Except for those characters that >IDNA2003 _required_ by mapped to nothing, that is also true of >IDNA2003. There is no provision in either for a conforming >implement to drop prohibited characters and look up the rest of >the label. NB. the first thing a parser should do is to look for the disallowed code points and reject the entry (with an error message or a log entry), the same action as if the entry was empty. You can ask for more a subtle operation through a SHOULD. You cannot oblige to it (via a MUST) as this has no impact on the wire. From john-ietf@jck.com Thu Jul 16 20:36: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 ECAE83A67B3 for ; Thu, 16 Jul 2009 20:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=1.071, 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 I13q+2dNRACf for ; Thu, 16 Jul 2009 20:36:01 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id ED0DA3A6B24 for ; Thu, 16 Jul 2009 20:36:00 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MReFH-000LnG-EH; Thu, 16 Jul 2009 23:36:27 -0400 Date: Thu, 16 Jul 2009 23:36:26 -0400 From: John C Klensin To: JFC Morfin , Lisa Dusseault Message-ID: <1D5C4004CDCE63B318C0DFC4@PST.JCK.COM> References: <8CEF048B9EC83748B1517DC64EA130FB3C1A2BF4EF@off-win2003-01.ausregistrygroup.local> <4a5fa63b.1aba720a.6a02.3eccSMTPIN_ADDED@mx.google.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Fri, 17 Jul 2009 05:06:14 -0700 Cc: Pete Resnick , iucg@ietf.org Subject: Re: [iucg] Disallowing code 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, 17 Jul 2009 03:36:03 -0000 --On Friday, July 17, 2009 04:04 +0200 JFC Morfin wrote: > Lisa, John, > I agree with Shawn Steel, let call a cat a cat. There are too > many words being used without considering their whole > implications. This is like just thinking over details instead > of also taking care of the whole picture. I can't and I do not > think it can be productive, moreover in a reticular system > like the Internet? I think it is precisely the whole picture that we are concerned about. The whole, global identifier, picture, not one country or language group at a time. > 1. When a character is DISALLOWED this means that one way or > another if it used something is going to be discarded, i.e. > that "something" is mapped to nil. The "something" may be a > single code point or the whole domain name, or something in > between - the application decides. The consequence is the > same: loss of information and typographic bandwidth reduction. Again, no. If a character is DISALLOWED, then the string that it contains is prohibited at a label, is not looked up, and, I hope results in a message to the user that it is invalid. That has nothing to do with discarding all or part of the string and then looking something else (or a subset) up. The latter would be a clear violation of the protocol. > 2. I consider "protocol level" as a fundamental point indeed > (I do not think the IESG and IAB use nearly meaningless > phrases in a Charter, moreover when issuing strict > conditions). If the Charter says "elimination of character > mapping in the protocol" this may only mean one thing. That > thing - as we understood it, and the reason we are waiting for > Vint's plan to complete - is well documented in Pete Draft: > the mapping is to happen outside of the protocol, i.e. not on > the wire. Because what is involved is outside of the network > control and of the IETF network territory. It is users' usage > operation territory. Yes. We actually agree about that. But it has nothing to do with which characters are DISALLOWED, which the mapping document carefully does not touch. > This clearly translates in Pete's I_D: > >> This document describes the operations that can be > > First fundamental point: there is no MUST, this is consistent > with the rest of the position. The only MUST is to be > acceptable to the DNS. No. The MUST is to be consistent with the core IDNA2008 specs, which include consistency with the DNS. And that is exactly what the rest of the sentence says. >> applied to user input in order to get it into a form >> acceptable by the Internationalized Domain Names in >> Applications (IDNA) protocol [I-D.ietf-idnabis-protocol]. >> The document describes the underlying architectural >> principles (in section 2 and the general implementation >> procedure (in section 3). > > I class Patrick's document among the underlying architectural > principles the WG is to define that "can be applied to user > input" (meaning by the application). This is a BCP not a > Standard. If, by "Patrick's (sic) document" you mean draft-ietf-idnabis-tables, it is referenced normatively from Protocol and is a core part of the Standards-Track IDNA2008 specification, not a BCP. >> It should be noted that this document does not specify the >> behavior of a protocol that appears "on the wire". > > This conforms to the Charter. Character mapping of any kind > MUST not appear on the wire, but off the wire. Sure. But, strictly speaking, IDNA does not appear on the wire. Only A-labels do. That has been the source of a lot of confusion. Note that the IRI document, which is well outside the WG's scope, does refer to IRIs as protocol elements, which pushes them into the "on the wire" category, including their IDN components. >> It describes an operation that is to be applied to user input >> in order to prepare that user input for use in an "on the >> network" protocol. > > All this clearly describe something which is outside the "on > the network" protocol. Yes. So? >> As unusual as this may be for an IETF protocol document, it >> is a necessary operation to maintain interoperability. > > The text underlines that it is unusual and qualifies what is > not part of the protocol as an operation. We have widely > published that we are in agreement with the Charter and with > this text. Ok. So we are arguing about what? > 3. The coup consists in trying to obtain URL indexing > stability in invading and annexing that territory, my/our > territory. And then starting rulling it, through MUSTs where > interoperability calls for negociation based upon SHOULDs. If > I want to make Tatweel resolve the IETF site, I just have to > use the 1972 host.txt service, making the Tatweel code-point > correspond to the IETF IP. What ever the way I can enter a > tatweel and punycode it, it will work. If I try the same under > IDNA2008, my entry will be mapped to nil and nothing will > happen. I do not really call this innovation and progress in > 37 years :-) Worse, I might also name it an alias/domain name > conflict. There is no coup and the above is either a misinterpretation or outside the WG's scope. URIs are prohibited from containing non-ASCII domain names -- I believe globally although there are some factions who believe that such names can be included in %-escaped UTF-8 in those fields. And you can't use the 1972 Hosts.TXT service because it was shut down long ago. More important, it was strictly limited --technically and administratively-- to ASCII letters, digits, and hyphens, so there is no way to express a Tatweel in those tables. In IDNA2008, you simply cannot express Tatweel in a label so, in that narrow sense, the behavior under the Hosttable rules and that under IDNA2008 is identical. > Gee! I am on vacations ! Yeah. And I'm trying to retire. > At 00:44 17/07/2009, Lisa Dusseault wrote: >... >> 2. I don't consider DISALLOWED to be a mapping to nil at all. >> There is no requirement for clients to map DISALLOWED >> characters to nil and then request a domain -- a client >> could reject a string with DISALLOWED characters. Indeed, I think the client is required to do so and that simply mapping a DISALLOWED character to nothing would be a violation of the specification. Except for those characters that IDNA2003 _required_ by mapped to nothing, that is also true of IDNA2003. There is no provision in either for a conforming implement to drop prohibited characters and look up the rest of the label. >... regards, john From jefsey@jefsey.com Sat Jul 18 16:34: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 7C5A13A6B14 for ; Sat, 18 Jul 2009 16:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 2oKiw5oiI32j for ; Sat, 18 Jul 2009 16:34:48 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id CC82C3A68BC for ; Sat, 18 Jul 2009 16:34:45 -0700 (PDT) Received: from 98.165.193-77.rev.gaoland.net ([77.193.165.98]:3832 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MSJPd-0007If-GM; Sat, 18 Jul 2009 16:33:54 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 19 Jul 2009 01:04:24 +0200 To: Vint Cerf ,John C Klensin , Pete Resnick , Andrew Sullivan , Lisa Dusseault 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: <20090718233448.CC82C3A68BC@core3.amsl.com> Cc: iucg@ietf.org Subject: Re: [iucg] Preparation for IDNABIS Stockholm 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, 18 Jul 2009 23:34:49 -0000 Dear all, 1. I started answering John's mail with a first part which takes time. However, it is only a rationale that explains my/france@large positions. It does not affect IDNA at this stage. 2. what is proposed is a ballanced compromise. As every ballanced compromise it can turn catastrophic, but the IETF/LC is the part of the Internet standard process to discuss that risk. So, I do support at this stage this compromise provided "Mapping should NOT be a MUST on lookup, to allow for the fact that a substantial range of transformations may take place from the time a possible DNS reference is input into an application to the point where a DNS query is made." 3. I have also the following comment on documents: - I consider some points in the Mapping Document as architecturally fundamental, and therefore that this document needs to be a standard track document. - I consider draft-ietf-idnabis-tables should be a BCP implementing a IANA informational open DDDS registry to record the current status of the considered codepoints by application designers, registries, and in the future presentations and coding systems. The presented tables would be considered as the default of such a registry. We intend to focus on the preparation of a presentation of the Interplus, built over the IDNA2008 premises, in January 2010 at a telecommunications industry meeting in Paris where Vint Cerf was invited but declined. Hopefully, IDNA2008 should have at least been approved by the IESG at this date. jfc At 21:02 18/07/2009, Vint Cerf wrote: >Folks, >We must achieve consensus on our documents and submit them to the AD >at or shortly after our WG meeting in Stockholm. > >here is where I think we are: > >We have essential consensus on the five primary documents (rationale, >defs, bidi and protocol). There are ongoing discussions about some >specifics in Tables. We are also discussing the language of the sixth >document (mapping). Bidi and Tables have expired as I-Ds and need to >be re-issued. From jefsey@jefsey.com Tue Jul 28 16:01: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 8B17F3A6928 for ; Tue, 28 Jul 2009 16:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.758 X-Spam-Level: X-Spam-Status: No, score=0.758 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SUBJECT_FUZZY_TION=0.156] 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 pMUeMoUQa3ob for ; Tue, 28 Jul 2009 16:01:26 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 834643A6904 for ; Tue, 28 Jul 2009 16:01:26 -0700 (PDT) Received: from 199.148.76-86.rev.gaoland.net ([86.76.148.199]:2777 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MVve9-0000Wz-DP; Tue, 28 Jul 2009 15:59:52 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Jul 2009 00:59:23 +0200 To: "Dr. Francis MUGUET" From: JFC Morfin Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_137877375==.ALT" 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: <20090728230126.834643A6904@core3.amsl.com> X-Mailman-Approved-At: Wed, 29 Jul 2009 02:14:44 -0700 Cc: Donald Eastlake , Shawn Steele , Andrew Sullivan , Harald Alvestrand , iucg@ietf.org, Lisa Dusseault , John C Klensin , Vint Cerf , "W.C.A. Wijngaards" Subject: [iucg] your ITU study on Internet classes based DNS competition and multilinguisation 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, 28 Jul 2009 23:01:28 -0000 --=====================_137877375==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Dear Francis, Unless your target is only to create a governance political issue, I suggest your priority to be not so much to explore the technical and political possibilities that are allowed by the use of the class parameter in the way that you described it in your presentation, but rather the technical and political impossibilities and blockings that it would meet and that you would have to overcome first as well as how to obtain the adherence of those who could oppose such a class system, or suffer from it. You may want to consider these three aspects of importance: * Internet classes are actually a TLD suffix, i.e., a super-root. As such, they are included in the Interplus ULDs. Their particular problem is not their mechanics but rather their interoperability with other resolving services from other technologies as well as with usage. Are you excited about using "in%ibm.com" "hs%ibm.com", etc.? Please let us not confuse the technical (classes) and commercial/political issues. Classes have many possible uses other than commercial/political layer violations and mnemonic confusion. The ITU and IETF do not deal with the same communications strata. Let not engage them into political and economic issues without serious technical feasilibilty discussions first. * the DNS fully supports UTF-8 naming. This is something that Microsoft seems to be very involved in for private networks. Technical debates seem to show that one of the main strengths of the DNS is to be rustic and to use 7 bits LDH. Wanting to go any further with Unicode tools is inappropriate. We had a similar experience with Debbie Garside's UK/GAC/ICANN/Unicode attempt to internationalize ISO 3166 (which is the true multilingualization paradigm, precisely because it is only published in French/English). This is the same kind of impracticability that the WG-IDNABIS is faced with. I presume there are some meta-stability relations with GCD properties. * the digital technology convergence. I have two problems with the Internet Classes (IC). (1) there is no way to police them and, therefore, they are a huge source of possible pollution by mismanagement or independent use, (2) their number is limited, while the present need would at least be of one per relational space, i.e. billions of them. This is a need that Interplus is designed to support. Let us clearly understand that I have lived with classes, groups, and externets (class + group restrictions, closed-user-groups, etc.) for more than 30 years now. These are basic distributed network building blocks the internet does not use (and actually blocks). Therefore, I would be worried indeed if you were proposing, with personal talent, political visibility, and international ITU authority, something that would not address the entire issue on shot (my advice) and not have been previously advised or reviewed by the people who I listed in the copy. They are, IMHO, able to technically comment and give their suggestions on this matter. I also Bccd a few persons who can in turn assist you in the political area, if they so desire. I will certainly continue cooperating on this issue, moreover if you extend it to the general evolution of the internet as the pervasive multitechnology communication system of the digital ecosystem. Best. jfc >From: "Dr. Francis MUGUET" >To: "WSIS Civil Soc. WG on...snip... governance@lists.cpsr.org> >Subject: [Gov 691] Opening / Ouverture competition DNS / ITU /IUT >expert mission > >English / Français > >Dear friends > >Your kind contributions and suggestions ( whether open or >confidential, formal or informal ) are going to be most welcome. >Indeed, following my presentation at the WSIS Forum, ( >Opening to competition the >namespace infrastructure 20 May 2009, Geneva ) , an expert mission >was granted to me by ITU in order to : > * Explore the technical possibilities allowed by the use of the > class parameter ( cf. RFC 5395 > superseding RFC 2929) > in order to open to competition the DNS namespace services > infrastructure of IP-based networks ; > * Assess the consequences in terms of IP-based networks ( > including Internet ) policies and governance, as well as for the > general economy, in particular to confront the economic crisis ; > * Assess other applications, as appropriate, such as, inter > alia, tools to enable the semantic web, to facilitate linguistic > diversity, to improve security , and to provide namespace services > for the "Net of Things", and "Next Generation Networks". >that I intend to conduct in the most inclusive way.. >As output of this mission, two documents shall be available in an >open access manner : > * A background paper for the general public > * An issue paper for decision makers, analyzing the policy > aspects of the usage of DNS classes, >---------------------------------------------------------------------------------------------------- > >All the best > >Francis > >======================================================= > >Chers amis > >Vos contributions et suggestions (qu'elles soientt publiques ou >confidentielles, formelles ou informelles) vont être les bienvenues. >En effet, à la suite de ma présentation dans le cadre du Forum >du SMSI Forum, ( ( >Opening to competition the >namespace infrastructure , Ouverture à la concurrence de >l'infrastructure de l'espace de nommage 20 Mai 2009, Genève), une >mission d'expert m'a été confiée par l'UIT en vue de: > > 1. Explorez les possibilités techniques permises par > l'utilisation du paramètre class >(cf. RFC 5395 qui remplace >la RFC 2929) afin >d'ouvrir à la compétition, l'infrastructure des services de nommage >DNS des réseaux IP; > 2. Évaluer les conséquences en termes des politiques et de la > gouvernance des réseaux IP (en incluant l'Internet lainsi que > pour l'économie en général, en particulier pour faire face à la > crise économique; > 3. Évaluer d'autres applications appropriéés, telles que, entre > autres, des outils afin de permettre l'épanouissement de la Toile > Sémantique, afin de faciliter la diversité linguistique, afin > d'améliorer la sécurité, et de fournir des services de nommage pour > le "Réseau des Objets" et les Réseaux de Nouvelle Génération. > >que j'ai l'intention de conduire d'une façon aussi inclusive que >faire se peut. > > Comme résultat de cette mission, deux documents seront > disponibles en libre accès: > > 1. Un document d'information pour le grand public > 2. Un document pour les décideurs, analysant les aspects > politiques et gouvernance de l'utilisation des classes DNS, > > > > >-- > >------------------------------------------------------ >Francis F. MUGUET Ph.D > >MDPI Foundation Open Access Journals >http://www.mdpi.org http://www.mdpi.net >muguet@mdpi.org >muguet@mdpi.net > >KNIS http://knis.org >Academic Collaboration / University of Geneva >http://syinf.unige.ch/cooperation > >Mobile France +33 6 71 91 42 10 > Switzerland +41 78 927 06 97 > Cameroun +237 96 55 69 62 ( mostly in July ) > >World Summit On the Information Society (WSIS) >Civil Society Working Groups >Scientific Information >: http://www.wsis-si.org chair >Patents & >Copyrights : http://www.wsis-pct.org co-chair >Financing >Mechanismns : http://www.wsis-finance.org web >Info. Net. >Govermance : http://www.wsis-gov.org web > >NET4D : http://www.net4D.org >UNMSP : http://www.unmsp.org >WTIS : http://www.wtis.org REUSSI : >http://www.reussi.org >------------------------------------------------------ >_______________________________________________ >Gov mailing list >Gov@wsis-gov.org >http://mail.conferences.tv/mailman/listinfo/gov --=====================_137877375==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear Francis,

Unless your target is only to create a governance political issue, I suggest your priority to be not so much to explore the technical and political possibilities that are allowed by the use of the class parameter in the way that you described it in your presentation, but rather the technical and political impossibilities and blockings that it would meet and that you would have to overcome first as well as how to obtain the adherence of those who could oppose such a class system, or suffer from it.

You may want to consider these three aspects of importance:

* Internet classes are actually a TLD suffix, i.e., a super-root. As such, they are included in the Interplus ULDs. Their particular problem is not their mechanics but rather their interoperability with other resolving services from other technologies as well as with usage. Are you excited about using "in%ibm.com" "hs%ibm.com", etc.? Please let us not confuse the technical (classes) and commercial/political issues. Classes have many possible uses other than commercial/political layer violations and mnemonic confusion. The ITU and IETF do not deal with the same communications strata. Let not engage them into political and economic issues without serious technical feasilibilty discussions first.

* the DNS fully supports UTF-8 naming. This is something that Microsoft seems to be very involved in for private networks. Technical debates seem to show that one of the main strengths of the DNS is to be rustic and to use 7 bits LDH. Wanting to go any further with Unicode tools is inappropriate. We had a similar experience with Debbie Garside's UK/GAC/ICANN/Unicode attempt to internationalize ISO 3166 (which is the true multilingualization paradigm, precisely because it is only published in French/English). This is the same kind of impracticability that the WG-IDNABIS is faced with. I presume there are some meta-stability relations with GCD properties.

* the digital technology convergence. I have two problems with the Internet Classes (IC). (1) there is no way to police them and, therefore, they are a huge source of possible pollution by mismanagement or independent use, (2) their number is limited, while the present need would at least be of one per relational space, i.e. billions of them. This is a need that  Interplus is designed to support.

Let us clearly understand that I have lived with classes, groups, and externets (class + group restrictions, closed-user-groups, etc.) for more than 30 years now. These are basic distributed network building blocks the internet does not use (and actually blocks). Therefore, I would be worried indeed if you were proposing, with personal talent, political visibility, and international ITU authority, something that would not address the entire issue on shot (my advice) and not have been previously advised or reviewed by the people who I listed in the copy. They are, IMHO, able to technically comment and give their suggestions on this matter. I also Bccd a few persons who can in turn assist you in the political area, if they so desire.

I will certainly continue cooperating on this issue, moreover if you extend it to the general evolution of the internet as the pervasive multitechnology communication system of the digital ecosystem.

Best.

jfc

From: "Dr. Francis MUGUET" <muguet@mdpi.net>
To: "WSIS Civil Soc. WG on...snip... governance@lists.cpsr.org>
Subject: [Gov 691] Opening / Ouverture competition DNS / ITU /IUT expert mission

English / Français

Dear friends

Your kind contributions and suggestions  ( whether  open or confidential, formal or informal   )   are going to  be  most welcome.
Indeed, following my presentation at the WSIS Forum,  ( Opening to competition the namespace infrastructure 20 May 2009, Geneva ) , an expert mission was granted to me by ITU in order to :
  1. Explore the technical possibilities allowed by the use of the class parameter  ( cf. RFC 5395 superseding  RFC 2929) in order to open to competition the DNS namespace services infrastructure of IP-based networks ;
  2. Assess the consequences in terms of IP-based networks ( including Internet ) policies and governance, as well as for the general economy, in particular to confront the economic crisis ;
  3. Assess other applications, as appropriate, such as, inter alia, tools to enable the semantic web, to facilitate linguistic diversity, to improve security , and to provide namespace services for the “Net of Things”, and “Next Generation Networks”.
that I intend to conduct in the most inclusive way..
As output of this mission, two documents shall be available in an open access manner :
  1. A background paper for the general public
  2. An issue paper for decision makers, analyzing the policy aspects of the usage of DNS classes,
----------------------------------------------------------------------------------------------------

All the best

Francis

=======================================================

Chers amis

Vos contributions et suggestions (qu'elles soientt publiques ou confidentielles, formelles ou informelles) vont être les bienvenues.
En effet, à la suite de ma présentation dans le cadre du Forum du  SMSI Forum, ( ( Opening to competition the namespace infrastructure , Ouverture à la concurrence de l'infrastructure  de l'espace de nommage 20 Mai 2009, Genève), une mission d'expert m'a été confiée par l'UIT en vue de:

    1. Explorez les possibilités techniques permises par l'utilisation du paramètre class  
(cf. RFC 5395 qui remplace la   RFC 2929)  afin d'ouvrir à la compétition, l'infrastructure des services de nommage DNS des réseaux IP;
    2. Évaluer les conséquences en termes des politiques et de la gouvernance des  réseaux IP (en incluant l'Internet  lainsi que pour l'économie en général, en particulier pour faire face à la crise économique;
    3. Évaluer d'autres applications appropriéés, telles que, entre autres, des outils afin de permettre l'épanouissement de la Toile Sémantique, afin de faciliter la diversité linguistique, afin d'améliorer la sécurité, et de fournir des services de nommage pour le "Réseau des Objets" et les Réseaux de Nouvelle Génération.

que j'ai l'intention de conduire d'une façon aussi inclusive que faire se peut.

  Comme résultat de cette mission, deux documents seront disponibles en libre accès:

    1.        Un document d'information pour le grand public
    2.        Un document pour les décideurs, analysant les aspects politiques et gouvernance de l'utilisation des  classes DNS, 




-- 

------------------------------------------------------ 
Francis F. MUGUET Ph.D 

MDPI Foundation Open Access Journals
http://www.mdpi.org  
http://www.mdpi.net
muguet@mdpi.org
      
muguet@mdpi.net

KNIS http://knis.org
Academic Collaboration / University of Geneva

http://syinf.unige.ch/cooperation

Mobile France       +33 6 71 91 42 10
       Switzerland  +41 78 927 06 97
       Cameroun    +237 96
55 69 62 ( mostly in July )

World Summit On the Information Society (WSIS)
Civil Society Working Groups
Scientific Information : 
http://www.wsis-si.org  chair 
Patents & Copyrights   : 
http://www.wsis-pct.org co-chair
Financing Mechanismns  : 
http://www.wsis-finance.org
web
Info. Net. Govermance  : 
http://www.wsis-gov.org  web

NET4D : http://www.net4D.org 
UNMSP : http://www.unmsp.org 
WTIS : http://www.wtis.org  
REUSSI : http://www.reussi.org
------------------------------------------------------
_______________________________________________
Gov mailing list
Gov@wsis-gov.org
http://mail.conferences.tv/mailman/listinfo/gov
--=====================_137877375==.ALT-- From jefsey@jefsey.com Fri Jul 31 08:11:06 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 0D3983A68A8 for ; Fri, 31 Jul 2009 08:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=2.678, 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 MCXeHMJ+Y43K for ; Fri, 31 Jul 2009 08:11:05 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 0199D3A67AD for ; Fri, 31 Jul 2009 08:11:04 -0700 (PDT) Received: from 199.148.76-86.rev.gaoland.net ([86.76.148.199]:2050 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1MWtlB-0001wm-Gr; Fri, 31 Jul 2009 08:11:06 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 31 Jul 2009 17:11:00 +0200 To: iucg@ietf.org From: JFC Morfin Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_135481734==.ALT" 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: <20090731151105.0199D3A67AD@core3.amsl.com> Cc: John C Klensin , Vint Cerf , Lisa Dusseault Subject: [iucg] Fwd: Re: IDNABIS Status post-IETF 75 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, 31 Jul 2009 15:11:06 -0000 --=====================_135481734==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Members, this mail was sent by Lisa Dussault, Applications Area Director. As soon as the documents are finalized, I will put them on the WIKIDNA and the IUCG Wiki IDNABIS for internal review. I will then ask you to carefully review them IRT to the Interplus documents we will then be able to finalize (I am half-way through my I_D generation program from our wiki bilingual pages). In the meanwhile, I thank you to continue not to interfere with debates on the WG-IDNABIS. The consensus has been reached eventhough some participants continue to have their own ideas. There always are differences between WG and IETF LCs and implementations. We are interested in the real life interoperability between the IETF/LC consensus and the way Browsers, application and Interplus implementation designers will understand and accept it. Once we are sure there is no blocking aspect in IDNA2008, our job will at last be to build on top of it. The way we may eventually implement IDNA2008 MAY be different because we will use an architecture and routines that may extend it. Nevertheless it will be the full "IDNA2008 xn-- internationalised presentation" that we will transparently support. Have great vacations! jfc >Subject: Re: IDNABIS Status post-IETF 75 >From: Lisa Dusseault >To: Vint Cerf >Cc: idna-update@alvestrand.no > >On Wed, Jul 29, 2009 at 10:45 PM, Vint Cerf ><vint@google.com> wrote: >By way of this message, I am asking Lisa Dusseault, the Area Director, >to outline the procedures for Working Group Last Call. Once these >procedures are complete, I plan to submit the finalized documents to >the Area Director along with a brief cover letter outlining our work >for presentation to the IESG. The IESG will either authorize the >documents to enter IETF Last Call or return them to the Area Director >(and implicitly to me as working group chair) for revision. > > >It is customary to do a Working Group Last Call, as part of >determining Working Group consensus for the documents. Vint has >asked for new issues during this WGLC, and has indicated over the >past year a number of issues that the WG has closed (already come to >consensus on). Posting overall impressions of the current state of >documents can be useful during this time as part of demonstrating consensus. > >After WG consensus is determined, the documents would go to me for >Area Director review (though I've been following closely all along), >then I send the documents to IETF Last Call as required by RFC2026, >and finally for IESG Approval. > >Thanks for your contributions & reviews, >Lisa --=====================_135481734==.ALT Content-Type: text/html; charset="us-ascii" Dear Members,
this mail was sent by Lisa Dussault, Applications Area Director. As soon as the documents are finalized, I will put them on the WIKIDNA and the IUCG Wiki IDNABIS for internal review. I will then ask you to carefully review them IRT to the Interplus documents we will then be able to finalize (I am half-way through my I_D generation program from our wiki bilingual pages). In the meanwhile, I thank you to continue not to interfere with debates on the WG-IDNABIS. The consensus has been reached eventhough some participants continue to have their own ideas.

There always are differences between WG and IETF LCs and implementations. We are interested in the real life interoperability between the IETF/LC consensus and the way Browsers, application and Interplus implementation designers will understand and accept it. Once we are sure there is no blocking aspect in IDNA2008, our job will at last be to build on top of it. The way we may eventually implement IDNA2008 MAY be different because we will use an architecture and routines that may extend it. Nevertheless it will be the full "IDNA2008 xn-- internationalised presentation" that we will transparently support.

Have great vacations!
jfc

Subject: Re: IDNABIS Status post-IETF 75
From: Lisa Dusseault <lisa.dusseault@gmail.com>
To: Vint Cerf <vint@google.com>
Cc: idna-update@alvestrand.no

On Wed, Jul 29, 2009 at 10:45 PM, Vint Cerf <vint@google.com> wrote:
By way of this message, I am asking Lisa Dusseault, the Area Director,
to outline the procedures for Working Group Last Call. Once these
procedures are complete, I plan to submit the finalized documents to
the Area Director along with a brief cover letter outlining our work
for presentation to the IESG. The IESG will either authorize the
documents to enter IETF Last Call or return them to the Area Director
(and implicitly to me as working group chair) for revision.


It is customary to do a Working Group Last Call, as part of determining Working Group consensus for the documents.  Vint has asked for new issues during this WGLC, and has indicated over the past year a number of issues that the WG has closed (already come to consensus on).  Posting overall impressions of the current state of documents can be useful during this time as part of demonstrating consensus.

After WG consensus is determined, the documents would go to me for Area Director review (though I've been following closely all along), then I send the documents to IETF Last Call as required by RFC2026, and finally for IESG Approval. 

Thanks for your contributions & reviews,
Lisa
--=====================_135481734==.ALT--