From jefsey@jefsey.com Fri Dec 9 06:13:10 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3405321F853B for ; Fri, 9 Dec 2011 06:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.742 X-Spam-Level: X-Spam-Status: No, score=-100.742 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAsN9GDxBFjY for ; Fri, 9 Dec 2011 06:13:09 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 55BCC21F84DA for ; Fri, 9 Dec 2011 06:13:09 -0800 (PST) Received: from 29.15-227-89.dsl.completel.net ([89.227.15.29]:52864 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RZ1CA-0004xO-Lk; Fri, 09 Dec 2011 06:13:03 -0800 Message-Id: <7.0.1.0.2.20111209145113.07e46270@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 09 Dec 2011 15:22:03 +0100 To: Gervase Markham ,idna-update@alvestrand.no From: JFC Morfin In-Reply-To: <4EE1ED1D.5000604@mozilla.org> References: <4EE1ED1D.5000604@mozilla.org> 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: Cc: "maaya@funredes.org" , iucg@ietf.org, "ca@linguasphere.info" Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 09 Dec 2011 14:13:10 -0000 Dear Gervase, IMHO if we want to force everyone to be happy in the only way we would want and use mandatory lists, we will make no one happy. IDNofA as an architecture is broken: your questions demonstrate it: five sister applications, at least 3 approximative different behaviours, and possibly five different IP resolution. The only stable solution is a single common IDNApplication because there is a single common Internet DNS. This was not in our charter, but this was Lisa Dussault's wished us to address once we agreed over the WG/LC. Either the IAB eventually documents it, or we will disseminate it. The point is in the "WITISWISISWIS" IDNApplications requirement: what I type is what I see is what I send. Please let us explain around that : - there are 22500 language entities throught the world listed by the FLOSS Linguasphere database. - there will be billions of TLDs and trillions of IDNs supported by IDv6 (IPv6 ID used on a global basis) - the open code browsers will be forked to support IDNA transparent support. Why not to just keep the browsers transparent and support your 3 buckets as a single option set (one can chose the default depending on the local needs pattern). As they are I really fail to see how each of these bucket can clearly and easily support plurilingual users, multilingual applications or be used in an aerport or hotel cybercafe. jfc At 12:12 09/12/2011, Gervase Markham wrote: >Recently, Mozilla community member Jothan Frakes was kind enough to do >some research about how different popular web browsers implement IDN, >and when they display the real characters and when they display >Punycode. This is in the context of a Mozilla review of our policy. I am >interested in the opinions of people on this list (see below). > >As it turns out, the behaviour of all popular browsers is summarised at >the bottom a Chromium project document here: >http://www.chromium.org/developers/design-documents/idn-in-google-chrome > >The policies fall into 3 approximate buckets: > >A (IE, Chrome): Unicode if the (single) 'language' of the string is >configured in the options, Punycode otherwise. > >B (Firefox, Opera): Unicode if the TLD is in a whitelist, Punycode >otherwise. Arbitrary script mixing permitted (registry policy used to >prevent abuse). > >C (Safari): Unicode if the script is in a whitelist (which by default >does not include Cyrillic or Greek), Punycode otherwise. Not sure about >script mixing. > > >Firefox has historically resisted adopting a Type A policy because we >consider it seriously detrimental to IDN adoption and use. It seems to >me that IDN can never be reliable for site owners, and therefore will >not succceed, if a significant proportion of the world's browsers adopt >Type A or Type C policies. This is because site owners can never know >what proportion of their visitors will see gobbledegook in the URL bar >rather than their nice domain name. Perhaps for sites whose visitors are >all guaranteed to be from a particular country or language group, with >properly-configured browsers and OSes which know that they speak a >certain language or use a certain script, it might work - but I suggest >that's a small subset of all sites. Many people in non-English-speaking >countries still use English OSes and English browsers, with default >settings. > >Type C is particularly bad - Russian and Greek IDNs are broken by >default, but even if you persuade your users to turn it on, they can >then be mixed-script spoofed. You get to choose between functionality >and security. > >By contrast, with a Type B policy, if your IDN domain works in one copy >of Firefox, it works in them all. If everyone had Type B policies, there >would be no risk of a properly-registered domain coming up as gibberish. > >It has been suggested that Firefox switch to a Type A policy. As it is, >the mix of policies means that the goal of universal acceptability is >not being met anyway. Firefox switching to Type A would also not meet >that goal by itself, but one could argue that there's a bit more >consistency to browser behaviour. > >I would be interested in the opinion of people on this list as to: > >- whether my analysis seems reasonable; >- whether they prefer type A, B or C; and >- whether they see any particular policy as more damaging to IDN > adoption than another. > >Has anyone lobbied one browser manufacturer or another to change their >policy? Is there another option that is not currently in use which would >be better? > >(Note that "no restrictions" is not an option, given what happened in >2005 with payp-cyrillic-a-l.com, and I would rather not derail this >debate by rehearsing those arguments again.) > >Gerv >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From jmabdp@gmail.com Fri Dec 9 16:19:50 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9F121F893C for ; Fri, 9 Dec 2011 16:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBYlTV1UY6Oj for ; Fri, 9 Dec 2011 16:19:49 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8238021F8922 for ; Fri, 9 Dec 2011 16:19:49 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so5131865wgb.13 for ; Fri, 09 Dec 2011 16:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=InG8Hhmz3NoIBFRsj+4u5g8CcTWetX9D8hj+ZAMBnKI=; b=Bge1XcpEERQ8tfRmFATeJp5QyMdfbtxDJewjwMbD0Kn86+GYTxg/YnqoFpN+UdKiRz u9mEbdau3nMgSNAWtZUM/V7c0DwRlSQnLTXdb359IS5AmuIVALcODbuWoQXb8gkbgsh3 1AwW+XTvWluccppemZ0g6ndB1Jpu0d2xix52s= MIME-Version: 1.0 Received: by 10.227.197.10 with SMTP id ei10mr8357676wbb.11.1323476388714; Fri, 09 Dec 2011 16:19:48 -0800 (PST) Received: by 10.227.59.142 with HTTP; Fri, 9 Dec 2011 16:19:48 -0800 (PST) In-Reply-To: References: <4EE1ED1D.5000604@mozilla.org> <4C9094D3FC87807BD2212B69@PST.JCK.COM> <7A4B4DE3-5714-4DCF-9BFF-E68826F89AEF@imc.org> Date: Sat, 10 Dec 2011 01:19:48 +0100 Message-ID: From: jean-michel bernier de portzamparc To: IDNA update work Content-Type: multipart/alternative; boundary=0015174c1a9204992f04b3b1dc8c Cc: iucg@ietf.org Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 10 Dec 2011 00:19:50 -0000 --0015174c1a9204992f04b3b1dc8c Content-Type: text/plain; charset=ISO-8859-1 I am afraid this debate is among people who read ASCII characters, believe that Registries have IDNA2003 policies when IDNA2008 default should be OK for all and is the rule for 3rd level DNs, confuse the TCP/IP international network with the Internet, and think that ICANN and GAC have something to do with the digital ecosystem technology. There is only one thing which is demanded by users : WITISWISISWIS and no application interference. Otherwise it means that every application and each application version will result in its own internet. Now, if browsers manufacturers want to support additional optional service pluggins with A,B,C,.... Y,Z strategies this is very nice of them: they write an RFC describing their protocosl and make their complete support optional. 1. Browsers MUST support any IDN made of any IDNA2008 permitted character, whatever the TLD, etc. etc. 2. Right clicking on an URL should allow users to see its punycode equivalent. PORTZAMPARC --0015174c1a9204992f04b3b1dc8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am afraid this debate is among people who read ASCII characters, believe = that Registries have IDNA2003 policies when IDNA2008 default should be OK f= or all and is the rule for 3rd level DNs, confuse the TCP/IP international = network with the Internet, and think that ICANN and GAC have something to d= o with the digital ecosystem technology.

There is only one thing which is demanded by users : WITISWISISWIS and = no application interference. Otherwise it means that every application and = each application version will result in its own internet.

Now, if b= rowsers manufacturers want to support additional optional service pluggins = with A,B,C,.... Y,Z strategies this is very nice of them: they write an RFC= describing their protocosl and make their complete support optional.

1. Browsers MUST support any IDN made of any IDNA2008 permitted charact= er, whatever the TLD, etc. etc.
2. Right clicking on an URL should allow= users to see its punycode equivalent.

PORTZAMPARC


--0015174c1a9204992f04b3b1dc8c-- From jfc@morfin.org Sat Dec 10 17:56:54 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4319C21F8B37; Sat, 10 Dec 2011 17:56:54 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char C3 hex): To: ...n@jck.com>,\n "Martin J. D\303\274rst" ) id 1RZYef-0004Hj-Ki; Sat, 10 Dec 2011 17:56:42 -0800 Message-Id: <7.0.1.0.2.20111210173009.07e46648@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 11 Dec 2011 03:06:16 +0100 To: John C Klensin , "Martin J. Dürst" , Gervase Markham ,Patrik Fältström , Cary Karp From: "J-F C. Morfin" In-Reply-To: <68B2EC7EF2AE4C429FCDE6E7@PST.JCK.COM> References: <4EE1ED1D.5000604@mozilla.org> <4EE355DF.2080705@it.aoyama.ac.jp> <68B2EC7EF2AE4C429FCDE6E7@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 - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: "iab@iab.org IAB" , idna-update@alvestrand.no, iucg@ietf.org, IESG Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 11 Dec 2011 01:56:54 -0000 >At 17:35 10/12/2011, Patrik Fältström wrote: >Let me emphasize that what John writes here is extremely important. >If you have the slightest opinion of what "confusing" implies, and >what implications approval of "too similar" TLDs might have, >specifically cross scripts, you should let ICANN know. >Now. >I do explicitly also sign this email as the chair of SSAC. That is >not a mistake. >Patrik Fältström >Chair ICANN Security and Stability Committee >At 17:48 10/12/2011, Cary Karp wrote: >The advisory group for ICANN's Variant Issues Project will be holding >its wrap-up meeting in Marina del Rey on Monday and Tuesday The issues >report it is focusing on will finalized in short order thereafter. At >least three of the people on the idna-update list will be in MdR so >anything said on it can also be channeled into the VIP discussion. > >The "now" that paf mentions really is NOW. >/Cary At 16:28 10/12/2011, John C Klensin wrote: >As to how realistic that assumption is, you might consider: > >(1) ICANN's Board apparently (minutes have not yet been posted) >passed a resolution on Thursday exempting IDN variations on .EU >from review for visual spoofing and other forms of >confusability. Dear John, ICANN has nothing to do with the Internet *technology* that the IETF is meant to positively influence (RFC 3935) and that Gervase has questions about on behalf of Firefox. The IAB has. ICANN claims benefits from a limited set of TLDs in class IN, outside of private networks, outside of IUsers interests, and outside of non-Internet digital technologies that want to use/already use the digital naming system and its root names (e.g.: .gsm, the Chinese TLDs and keywords, etc.). The area of use of browsers (and probable forked browsers, if open source ones become IUsers-foreign) is much larger. IMHO, the last thing we need, hence my slowdown for more than one year, is an inadvertent browser war, or Internet use confusion, over IDNA. This is why, as IUsers, we certainly are interested in presentation-layer-related-services being offered by browser manufacturers, as long as they are RFC documented and we can turn them up/down at our own will. The way I understand the problem is that the ball has been in your IAB field for more than one year after my appeal and the IESG/IAB have clarified that my area of concerns did affect, but did not belong to, the IETF scope. The IAB was (this is how I understood its road map) to decide how IDN/IDNA SHOULD be used in the Internet technology context. We did not move on this because I had hoped that we could maintain the IDNA2008 consensus and permit the IAB to move faster in not interfering. However, it turns out that I was wrong because the blocking reality questioned by you, me, Lisa, etc. remains: the IDNA2003/stringprep application-to-application architectural scheme does not scale to IDNA2008. We all have also known for years that this issue is to be addressed prior to January 12, 2012. The only viable architectural solution that I can figure out, but I could also be totally wrong, is subsidiarity at the IUI (intelligent use interface) on a fringe to fringe basis. The implications on many other diversity related items should have been discussed, over the course of the last two years, if some interests (IAB, IETF, ICANN, IGF, GAC, Unicode, Google, etc.) wanted to keep the transition under joint control. Since nothing has been discussed and, therefore, prepared and tested, we are heading towards an entirely new internet (IDv6 addressing, shared virtual unique root file, IDNgTLDs shambles, IANA revamp, etc.) without any idea of the way we want to manage it together, or even if we want to manage it together. If the IAB wants to document its IAB chosen architecture for this new internet, it has exactly one month left to be clear about a framework. Then, practical experimentation will have to start prior to the first ICANN IDNgTLD being officially accepted. Otherwise, it will not be innovation towards a better internet for all. It will be a long-term costly competition (global fight) between an obsolete use, a commercial+ use and an emerging efficient use of the Internet. I am going to document an IUse position that is to be I_Ded on January 10 if the IAB does not commit beforehand to a position that IUsers can consensually support. I have no objection to discussing my memo while I am preparing it (on the iucg@ietf.org mailing list: as you know, I cannot discuss it on the ietf@ietf.org mailing list). However, please let seriously discuss only network architecture and stop cosmetic layer violation confusions. At 02:02 11/12/2011, Paul Hoffman wrote: >[the response to the users] needs to come from a stable, trusted body. >I question whether such a body who is willing to make a table exists. Until now I thought that such a competent body was the IAB. This "really NOW" I will know if I was right. Best jfc From jmabdp@gmail.com Sat Dec 10 18:31:33 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5598421F8B37; Sat, 10 Dec 2011 18:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rarG80z70gyU; Sat, 10 Dec 2011 18:31:32 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7703521F8B23; Sat, 10 Dec 2011 18:31:31 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so6549937wgb.13 for ; Sat, 10 Dec 2011 18:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E3Iu0nGI4ztSp1QEJ2QHXgr2ig384Ldqzfxrx2BS4B4=; b=gcC9g+Mrgfym8A/24iYDi83IA4+99eLlEK8vqAfYslifDRyr8Mh/KkJKJu+WhHnQJA hKgPsujpSu0EZpywsxnFmNbAqGtGZBtgiRvR11dDPlVmZeDfhzKgS+/L9ys55KvcCsWw G4AEySEI+4tOLBd+1KtIkJSGcx9JkYADoEIsk= MIME-Version: 1.0 Received: by 10.216.135.218 with SMTP id u68mr1507992wei.69.1323570688955; Sat, 10 Dec 2011 18:31:28 -0800 (PST) Received: by 10.227.59.142 with HTTP; Sat, 10 Dec 2011 18:31:28 -0800 (PST) In-Reply-To: <7.0.1.0.2.20111210173009.07e46648@jefsey.com> References: <4EE1ED1D.5000604@mozilla.org> <4EE355DF.2080705@it.aoyama.ac.jp> <68B2EC7EF2AE4C429FCDE6E7@PST.JCK.COM> <7.0.1.0.2.20111210173009.07e46648@jefsey.com> Date: Sun, 11 Dec 2011 03:31:28 +0100 Message-ID: From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=0016e6dd8cf8c0155704b3c7d0de X-Mailman-Approved-At: Sat, 10 Dec 2011 19:06:49 -0800 Cc: Gervase Markham , IETF , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "iab@iab.org IAB" , John C Klensin , IESG , Cary Karp , idna-update@alvestrand.no, =?UTF-8?B?TWFydGluIEouIETEgsS9cnN0?= Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 11 Dec 2011 02:31:33 -0000 --0016e6dd8cf8c0155704b3c7d0de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I just put this mail on line at http://iucg.org/wiki/IAB!_NOW! This initiate the IUsers Group work on the discussed I_D. Portzamparc 2011/12/11 J-F C. Morfin > > At 17:35 10/12/2011, Patrik F=E4ltstr=F6m wrote: >> Let me emphasize that what John writes here is extremely important. If >> you have the slightest opinion of what "confusing" implies, and what >> implications approval of "too similar" TLDs might have, specifically cro= ss >> scripts, you should let ICANN know. >> Now. >> I do explicitly also sign this email as the chair of SSAC. That is not a >> mistake. >> Patrik F=E4ltstr=F6m >> Chair ICANN Security and Stability Committee >> > > At 17:48 10/12/2011, Cary Karp wrote: >> The advisory group for ICANN's Variant Issues Project will be holding >> its wrap-up meeting in Marina del Rey on Monday and Tuesday The issues >> report it is focusing on will finalized in short order thereafter. At >> least three of the people on the idna-update list will be in MdR so >> anything said on it can also be channeled into the VIP discussion. >> >> The "now" that paf mentions really is NOW. >> /Cary >> > > At 16:28 10/12/2011, John C Klensin wrote: > >> As to how realistic that assumption is, you might consider: >> >> (1) ICANN's Board apparently (minutes have not yet been posted) >> passed a resolution on Thursday exempting IDN variations on .EU >> from review for visual spoofing and other forms of >> confusability. >> > > Dear John, > > ICANN has nothing to do with the Internet *technology* that the IETF > is meant to positively influence (RFC 3935) and that Gervase has > questions about on behalf of Firefox. > > The IAB has. > > ICANN claims benefits from a limited set of TLDs in class IN, outside > of private networks, outside of IUsers interests, and outside of > non-Internet digital technologies that want to use/already use the > digital naming system and its root names (e.g.: .gsm, the Chinese TLDs > and keywords, etc.). The area of use of browsers (and probable forked > browsers, if open source ones become IUsers-foreign) is much larger. > > IMHO, the last thing we need, hence my slowdown for more than one > year, is an inadvertent browser war, or Internet use confusion, over > IDNA. This is why, as IUsers, we certainly are interested in > presentation-layer-related-**services being offered by browser > manufacturers, as long as they are RFC documented and we can turn them > up/down at our own will. > > The way I understand the problem is that the ball has been in your IAB > field for more than one year after my appeal and the IESG/IAB have > clarified that my area of concerns did affect, but did not belong to, > the IETF scope. The IAB was (this is how I understood its road map) to > decide how IDN/IDNA SHOULD be used in the Internet technology context. > We did not move on this because I had hoped that we could maintain the > IDNA2008 consensus and permit the IAB to move faster in not > interfering. However, it turns out that I was wrong because the > blocking reality questioned by you, me, Lisa, etc. remains: the > IDNA2003/stringprep application-to-application architectural scheme > does not scale to IDNA2008. > > We all have also known for years that this issue is to be addressed > prior to January 12, 2012. > > The only viable architectural solution that I can figure out, but I > could also be totally wrong, is subsidiarity at the IUI (intelligent > use interface) on a fringe to fringe basis. The implications on many > other diversity related items should have been discussed, over the > course of the last two years, if some interests (IAB, IETF, ICANN, > IGF, GAC, Unicode, Google, etc.) wanted to keep the transition under > joint control. Since nothing has been discussed and, therefore, > prepared and tested, we are heading towards an entirely new internet > (IDv6 addressing, shared virtual unique root file, IDNgTLDs shambles, > IANA revamp, etc.) without any idea of the way we want to manage it > together, or even if we want to manage it together. > > If the IAB wants to document its IAB chosen architecture for this new > internet, it has exactly one month left to be clear about a framework. > Then, practical experimentation will have to start prior to the first > ICANN IDNgTLD being officially accepted. Otherwise, it will not be > innovation towards a better internet for all. It will be a long-term > costly competition (global fight) between an obsolete use, a > commercial+ use and an emerging efficient use of the Internet. > > I am going to document an IUse position that is to be I_Ded on January > 10 if the IAB does not commit beforehand to a position that IUsers can > consensually support. I have no objection to discussing my memo while > I am preparing it (on the iucg@ietf.org mailing list: as you know, I > cannot discuss it on the ietf@ietf.org mailing list). > > However, please let seriously discuss only network architecture and > stop cosmetic layer violation confusions. > > At 02:02 11/12/2011, Paul Hoffman wrote: > >> [the response to the users] needs to come from a stable, trusted body. >> >> I question whether such a body who is willing to make a table exists. >> > > Until now I thought that such a competent body was the IAB. > > This "really NOW" I will know if I was right. > > Best > > jfc > > > ______________________________**_________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/**listinfo/iucg > --0016e6dd8cf8c0155704b3c7d0de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I just put this mail on line at h= ttp://iucg.org/wiki/IAB!_NOW!
This initiate the IUsers Group work on= the discussed I_D.

Portzamparc

20= 11/12/11 J-F C. Morfin <jfc@morfin.org>

At 17:35 10/12/2011, Patrik F=E4ltstr=F6m wrote:
Let me emphasize that what John writes here is extremely important. If you = have the slightest opinion of what "confusing" implies, and what = implications approval of "too similar" TLDs might have, specifica= lly cross scripts, you should let ICANN know.
Now.
I do explicitly also sign this email as the chair of SSAC. That is not a mi= stake.
Patrik F=E4ltstr=F6m
Chair ICANN Security and Stability Committee

At 17:48 10/12/2011, Cary Karp wrote:
The advisory group for ICANN's Variant Issues Project will be holding its wrap-up meeting in Marina del Rey on Monday and Tuesday The issues
report it is focusing on will finalized in short order thereafter. At
least three of the people on the idna-update list will be in MdR so
anything said on it can also be channeled into the VIP discussion.

The "now" that paf mentions really is NOW.
/Cary

At 16:28 10/12/2011, John C Klensin wrote:
As to how realistic that assumption is, you might consider:

(1) ICANN's Board apparently (minutes have not yet been posted)
passed a resolution on Thursday exempting IDN variations on .EU
from review for visual spoofing and other forms of
confusability.

Dear John,

ICANN has nothing to do with the Internet *technology* that the IETF
is meant to positively influence (RFC 3935) and that Gervase has
questions about on behalf of Firefox.

The IAB has.

ICANN claims benefits from a limited set of TLDs in class IN, outside
of private networks, outside of IUsers interests, and outside of
non-Internet digital technologies that want to use/already use the
digital naming system and its root names (e.g.: .gsm, the Chinese TLDs
and keywords, etc.). The area of use of browsers (and probable forked
browsers, if open source ones become IUsers-foreign) is much larger.

IMHO, the last thing we need, hence my slowdown for more than one
year, is an inadvertent browser war, or Internet use confusion, over
IDNA. This is why, as IUsers, we certainly are interested in
presentation-layer-related-services being offered by browser
manufacturers, as long as they are RFC documented and we can turn them
up/down at our own will.

The way I understand the problem is that the ball has been in your IAB
field for more than one year after my appeal and the IESG/IAB have
clarified that my area of concerns did affect, but did not belong to,
the IETF scope. The IAB was (this is how I understood its road map) to
decide how IDN/IDNA SHOULD be used in the Internet technology context.
We did not move on this because I had hoped that we could maintain the
IDNA2008 consensus and permit the IAB to move faster in not
interfering. However, it turns out that I was wrong because the
blocking reality questioned by you, me, Lisa, etc. remains: the
IDNA2003/stringprep application-to-application architectural scheme
does not scale to IDNA2008.

We all have also known for years that this issue is to be addressed
prior to January 12, 2012.

The only viable architectural solution that I can figure out, but I
could also be totally wrong, is subsidiarity at the IUI (intelligent
use interface) on a fringe to fringe basis. The implications on many
other diversity related items should have been discussed, over the
course of the last two years, if some interests (IAB, IETF, ICANN,
IGF, GAC, Unicode, Google, etc.) wanted to keep the transition under
joint control. Since nothing has been discussed and, therefore,
prepared and tested, we are heading towards an entirely new internet
(IDv6 addressing, shared virtual unique root file, IDNgTLDs shambles,
IANA revamp, etc.) without any idea of the way we want to manage it
together, or even if we want to manage it together.

If the IAB wants to document its IAB chosen architecture for this new
internet, it has exactly one month left to be clear about a framework.
Then, practical experimentation will have to start prior to the first
ICANN IDNgTLD being officially accepted. Otherwise, it will not be
innovation towards a better internet for all. It will be a long-term
costly competition (global fight) between an obsolete use, a
commercial+ use and an emerging efficient use of the Internet.

I am going to document an IUse position that is to be I_Ded on January
10 if the IAB does not commit beforehand to a position that IUsers can
consensually support. I have no objection to discussing my memo while
I am preparing it (on the iucg@ietf.org mailing list: as you know, I
cannot discuss it on the ietf@ietf.org mailing list).

However, please let seriously discuss only network architecture and
stop cosmetic layer violation confusions.

At 02:02 11/12/2011, Paul Hoffman wrote:
[the response to the users] needs to come from a stable, trusted body.

I question whether such a body who is willing to make a table exists.

Until now I thought that such a competent body was the IAB.

This "really NOW" I will know if I was right.

Best

jfc


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

--0016e6dd8cf8c0155704b3c7d0de-- From jfc@morfin.org Sun Dec 11 09:11:12 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644AA21F84D8; Sun, 11 Dec 2011 09:11:12 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJjRmVpOXgIo; Sun, 11 Dec 2011 09:11:12 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3071C21F84D7; Sun, 11 Dec 2011 09:11:07 -0800 (PST) Received: from 45.188-227-89.dsl.completel.net ([89.227.188.45]:54784 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RZmvO-0002H6-3B; Sun, 11 Dec 2011 09:10:54 -0800 Message-Id: <7.0.1.0.2.20111211160710.06d665f0@morfin.org> Message-Id: <7.0.1.0.2.20111210173009.07e46648@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 11 Dec 2011 18:20:37 +0100 To: iucg@ietf.org From: "J-F C. Morfin" 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 - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: "iab@iab.org IAB" , idna-update@alvestrand.no, IESG Subject: [iucg] Internet+ X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 11 Dec 2011 17:11:12 -0000 Further to my yesterday mail: 1. I have added the inputs of Gervase to the http://iucg.org/wiki/IAB!_NOW! entry of JMB de Potzamparc, so it may serve as a current reference. 2. I have added the IDNA2010 (how to interface IDNA2008 from the user side) review in the page http://iucg.org/wiki/IDNA2010_Common_Objectives 3. I have initiated the working wiki I_D page. The abstract is as follows: en: This framing memorandum discusses the high-level architecture of an intelligent use of the whole digital ecosystem (WDE) and how the emerging community of IUtilisateurs explores it from a smart interfacing with the Internet layers. fr: Cette note de cadrage traite de l'architecture de haut niveau de l'utilisation intelligente de l'ensemble de l'écosystème numérique (EEN) et de comment la communauté émergente des IUtilisateurs l'explore à partir d'un interfaçage élégant avec les couches Internet. Tentative table of contents coming. Comments welcome. jfc PS: I suggest you to have a look to http://duolingo.com. May be someone could come with a script/orthotypographic variant :-) From jfc@morfin.org Sun Dec 11 17:18:21 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2C21F845A for ; Sun, 11 Dec 2011 17:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=1.399, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiaW9dnhxouj for ; Sun, 11 Dec 2011 17:18:20 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 70C1721F844F for ; Sun, 11 Dec 2011 17:18:20 -0800 (PST) Received: from 45.188-227-89.dsl.completel.net ([89.227.188.45]:58771 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RZuX3-0007lz-Is; Sun, 11 Dec 2011 17:18:18 -0800 Message-Id: <7.0.1.0.2.20111212021936.06a7eee0@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Dec 2011 02:28:03 +0100 To: jean-michel bernier de portzamparc ,iucg@ietf.org From: "J-F C. Morfin" In-Reply-To: References: <7.0.1.0.2.20111211160710.06d665f0@morfin.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_282706743==.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 - morfin.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [iucg] Internet+ X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 12 Dec 2011 01:18:21 -0000 --=====================_282706743==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 01:49 12/12/2011, jean-michel bernier de portzamparc wrote: >In English: IUsers! Désolé ! >I suggest that you do not embark into too much explanations about >hows and whys, but restrict the I_D to a simple description of a >smart use architectural framework after detailing the targeted >support capacity. Some sort of core executive summary document, we >can then support by detailed annexed memos. This certainly is my intent. Actually it would be great if the table of contents of this ID could be a stable menu for the various IUTF documentation zones of the Internet+. I am not sure, however, that the I_D should be strictly oriented towards the Internet support/use. The approach should be "people centered", so technicaly cybship oriented, over a local, remote or distributed IUI. Then technologies should not be over considered: proprity to use and services. Let first see how the draft comes. Motivations are 7 billions IUsers, trillons of IDv6 addresses, 22,500 lingustic entities, 192 countries, etc. jfc >Also, I would suggest that at this time the I_D only documents the >IUI relation with TCP/IP and the Internet DNS. Wider support could >be introduced progressively after experimental validation. > >Portzamparc > >2011/12/11 J-F C. Morfin <jfc@morfin.org> >Further to my yesterday mail: >1. I have added the inputs of Gervase to the >http://iucg.org/wiki/IAB!_NOW! entry >of JMB de Potzamparc, so it may serve as a current reference. >2. I have added the IDNA2010 (how to interface IDNA2008 from the >user side) review in the page >http://iucg.org/wiki/IDNA2010_Common_Objectives >3. I have initiated the working wiki I_D page. The abstract is as follows: > >en: >This framing memorandum discusses the high-level architecture of an >intelligent use of the whole digital ecosystem (WDE) and how the >emerging community of IUtilisateurs explores it from a smart >interfacing with the Internet layers. > >fr: >Cette note de cadrage traite de l'architecture de haut niveau de >l'utilisation intelligente de l'ensemble de l'écosystème numérique >(EEN) et de comment la communauté émergente des IUtilisateurs >l'explore à partir d'un interfaçage élégant avec les couches Internet. > >Tentative table of contents coming. > >Comments welcome. >jfc > >PS: I suggest you to have a look to >http://duolingo.com. May be someone could come >with a script/orthotypographic variant :-) > >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update > --=====================_282706743==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 01:49 12/12/2011, jean-michel bernier de portzamparc wrote:
In English: IUsers!

Désolé !

I suggest that you do not embark into too much explanations about hows and whys, but restrict the I_D to a simple description of a smart use architectural framework after detailing the targeted support capacity. Some sort of core executive summary document, we can then support by detailed annexed memos.

This certainly is my intent. Actually it would be great if the table of contents of this ID could be a stable menu for the various IUTF documentation zones of the Internet+. I am not sure, however, that the I_D should be strictly oriented towards the Internet support/use. The approach should be "people centered", so technicaly cybship oriented, over a local, remote or distributed IUI. Then technologies should not be over considered: proprity to use and services.

Let first see how the draft comes. Motivations are 7 billions IUsers, trillons of IDv6 addresses, 22,500 lingustic entities, 192 countries, etc.

jfc



Also, I would suggest that at this time the I_D only documents the IUI relation with TCP/IP and the Internet DNS. Wider support could be introduced progressively after experimental validation.

Portzamparc

2011/12/11 J-F C. Morfin <jfc@morfin.org>
Further to my yesterday mail:
1. I have added the inputs of Gervase to the http://iucg.org/wiki/IAB!_NOW ! entry of JMB de Potzamparc, so it may serve as a current reference.
2. I have added the IDNA2010 (how to interface IDNA2008 from the user side) review in the page http://iucg.org/wiki/IDNA2010_Common_Objectives
3. I have initiated the working wiki I_D page. The abstract is as follows:

en:
This framing memorandum discusses the high-level architecture of an intelligent use of the whole digital ecosystem (WDE) and how the emerging community of IUtilisateurs explores it from a smart interfacing with the Internet layers.

fr:
Cette note de cadrage traite de l'architecture de haut niveau de l'utilisation intelligente de l'ensemble de l'écosystème numérique (EEN) et de comment la communauté émergente des IUtilisateurs l'explore à partir d'un interfaçage élégant avec les couches Internet.

Tentative table of contents coming.

Comments welcome.
jfc

PS: I suggest you to have a look to http://duolingo.com. May be someone could come with a script/orthotypographic variant :-)

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

--=====================_282706743==.ALT-- From jefsey@jefsey.com Mon Dec 12 19:08:05 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3450E1F0C3F for ; Mon, 12 Dec 2011 19:08:05 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char FC hex): To: ...t@google.com>,Martin J. D\374rst ; Mon, 12 Dec 2011 19:08:04 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8621F8513 for ; Mon, 12 Dec 2011 19:08:04 -0800 (PST) Received: from 45.188-227-89.dsl.completel.net ([89.227.188.45]:50789 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RaIif-0003Fa-8y; Mon, 12 Dec 2011 19:07:54 -0800 Message-Id: <7.0.1.0.2.20111212112441.0c534060@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 13 Dec 2011 04:17:42 +0100 To: Vint Cerf ,Martin J. Dürst From: JFC Morfin In-Reply-To: References: <4EE1ED1D.5000604@mozilla.org> <7A869EAD-2F27-4CA0-A35E-88B83A98C330@imc.org> <96CF61C4-8716-41BB-90A1-094C2040CE8B@frobbit.se> <20111211192002.GA46845@shinkuro.com> <933CB3D09DBB692797E80DA1@192.168.1.128> <4EE5A53E.3060402@it.aoyama.ac.jp> 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: Cc: John C Klensin , Andrew Sullivan <10ajs@anvilwalrusden.com>, idna-update@alvestrand.no, iucg@ietf.org Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 13 Dec 2011 03:08:05 -0000 I am responding to Vint and Martin in the same mail because the response proceeds from the same idea. Gervase is outside of the IETF scope: why and hence what is the border of that scope and its implications. IESG and IAB have clearly explained that the points discussed by my 2010 appeals were outside of their scope. This is why the BoF that they proposed for me to engage was inappropriate. This is also why I relied on the IAB roadmap for them to sort out their own definition of the upper-border of their area. I needed before I would engage in the documentation of the scope of the communication stratum above, what I call the semiotic and the semantic layers of the Intersem extending the OSI communication model to intercomprehension. At 08:38 12/12/2011, Vint Cerf wrote: >as ugly as it might be, I wonder whether showing both UNICODE and >PUNYCODE expressions would be useful? By itself, this might not reveal >a spoof unless one had bookmarked domain names against which to >compare, of course. If the viewer does not have an appropriate >font/script, of course, then only the PUNYCODE is displayable to any >useful effect. Again, one would need reference points to detect a >spoof. Vint, In "IUser" the "I" stands for many things: IETF, International, Intelligent, Intertechnology, Internet+, etc. and "lead" (as in "lead user"), but *not* for the Internet as such (and absolutely not for ICANN), because it may not be the only infrastructural system (infrasystem) being used to support their relational space. Gervase's concerns are "located" outside the Internet, at a layer where human brains (people) and end-applications (process) belong and relate through his smart window (browser). His context is, therefore, the bridge of the person's "cybship" (i.e. the personal digital continuity that he/she builds and governs, where he/she is authoritative in the way that he/she uses it and interconnects it to establish and maintain his/her relations. - At the hardware stratum, the cybship will be made of clouds, servers, PCs, laptops, tablets, mobiles, telemates, appliances, nanoimplants, browthers, etc. with ultimately at the core and in central remote control. his/her own neurons. - At the software stratum, everything may be either binary or localized. This is the IETF stratum. - At the brainware stratum, English may not be the language, may not be understood and may not be even readable. This means that one has to accept that ASCII may not belong to personal environments and that punycode strings may be as foreign to users as ASCII domain names. This is "above the IETF stratum", IAB/IESG said it is research. As a consequence, how the IETF stratum is to better support that "above" is IETF research. This is why we have to scale from "internationalization", as in Mark Davis' "globalization", (i.e. quoting localized non-English texts into International English), to "multilingualisation", i.e. to use Mark's terms, in localizing internationalization. Multilingualisation then has to be understood as the cybernetics of the linguistic diversity, where English is to be accepted as one of the 22,500 technically strictly equal linguistic entities and Latin charset as one of 100 technically strictly equal charsets. English and ASCII may be absent from the user's device. What Gervase asks for is how his smart windows should display this multilingualisation as far as IDNs are involved. OSI wise, the response is with the Internet multilingual layer number seven service, not with the internationalized internet, which is a way to name a part of the Internet number six presentation layer. IDNA2008 documents the Internet layer six and the subsidiary support of its corresponding level seven services on the user side. At 08:10 12/12/2011, Martin J. Dürst wrote: >I very much think it is correct. From their very timid start with >IDNs, ICANN has a strong and confusing tendency to cast issues in >terms of "language" even if they are script issues. That has >influenced the surroundings, too. Martin, We (IETF) have shared that confusion, e.g. the way we initially approached langtags, and the fuss that I had to create to obtain a non destructive langtag RFC set. I acknowledge that there was an effort to progressively teach the IETF people (not externally) that the language layer was not appropriate. This led to John Klensin's (quite briefly at first) conclusion that scripting was the upper concern of the IETF and that languages were outside of the IETF scope. This was a great technical clarification progress. However, this did not free the IETF from Unicode. To the contrary, it gave the illusion to the IETF that its technical upper border was the same as the Unicode one (so Unicode and IETF could be bound together). This is incorrect on at least three points that both IUse and ICANN had to live with: a. Unicode version changes that might result from cultural change or deeper Unicode knowledge. b. Mapping, an issue that IDNA2008 was set to get rid of and achieved, but that left unanswered issues and as a result some Unicode legitimate objections. c. Lack of orthotypographical (scripting syntax) considerations. The solutions: 1. Patrik came up with a solution to (a). It seems to be stable enough. 2. Paul and Pete came up with a perspective that permitted a consensus on (b). However only described by way of an example, the introduced general solution is subsidiarity: persons do locally what they authoritatively want as long as their fringe to fringe Internet+ solution respects the end to end Internet requirements. This calls for an IUI to support a fringe2fringe IUse of the Internet, i.e. an Internet+ architecture. Limited/initial phase IUI examples are: o the Google+ architecture (that we implemented in the Tymnet technology as the "menuserver" 25 years ago). o browsers in the HTTP area. Since there are five major browser manufacturers, Gervase requests quidance for one of them, and if possible concertation for them all. 3. The solution to (c) is more complex. It is approached by ICANN as "variant support". It calls for metadata to be previously known or for them to be transmitted in parallel. The paradigmatic (typical example) need is the support of the "majuscule" metadata. This clearly shows the different responsibility grades between the Unicode, IETF, and IUse areas. o if I am correct, Unicode wished to remove the capacity for its codes to escape to metadata. I think this is correct, and clearly identifies their character oriented plane, where Unicode/ISO 10646 are free to correlate with other encodings. o the IETF refused to consider orthotypography. I first opposed that disinterest but I must acknowledge that if this disinterest leaves only one solution, it seems architecturally the best one: to include that respective support as a transparently added feature of punycode. What I call punyplus. Punycode/Punyplus is, therefore, within the IETF scope. This clearly shows that it is not a matter for applications and browsers. The same, anti-phishing and logo/symbol support are not IETF or Unicode issues but rather IUse issues, through possibly an anti-phishing algorithm on top of Unicode. At 07:54 12/12/2011, Martin J. Dürst wrote: >Yes indeed. The browser vendors overreacted on issues such as >script-mixing, stuff that the user isn't able to read, and so on, >because overreacting was easier than a more careful reaction, and they >were able to say that they did something. I am afraid that they do not overreact, but rather react to a lack of the IETF, which was the reason for my appeals. The IDNA RFC set should have included an IAB disclaimer (as the one they spelled out in their response) warning that, IDNA2008 made the IETF/Internet community trespass its own top border, that RFC 5895 was a cross border involvement (RFC 5895), and how/where to discuss the cross and over border issues. >But they didn't do much for in-script attacks, because that's much >more difficult. (Not that I'm advocating a browser that shows >MlCR0S0FT.com with punycode.) Correct, but this is not "they" as in "browser vendors" (actually "manufacturers") but as in IUsers. Therefore, this is my fault because I am advocating the IUTF (Intelligent Use Task Force) to emerge and take over responsibility. Russ Housley carried the IETF role correctly in creating the iucg@ietf.org mailing list, allowing the emerging IUse community to liaise with the IETF. However, it has low traffic, not only because Jefsey the Troll is facilitating it, because it is young, but also because: o the IUse working methods, purpose, deliverables/confusables, and people dedication are not to be the same as the IETF, in the same way as ITU methods are not those of the IETF. o and mostly because we still have to discover them (and this is really a very deep discovery process if we want to reach consistency with world simplicity (RFC 3439) and human noetics (semantic intercomprehension process. The only thing I know is that the emerging IUTF will be a place for browser manufacturers and other W3C web applications plane interests, but, by far, not only for them. This is because they are "only" involved in a part of the HTTP protocol fall outs. The Internet is about TCP/IP: there are other technologies, and people (as the ultimate target) are interested (cf. above) in semantic intercomprehension. As an SDO, we are interested in facilitating that intercomprehension through relational digital tools. The point here is to understand how to better facilitate it through the IETF environment stratum (this is actually "making the Internet work better") in cooperation or not with the fringe to fringe IUI layers. We see the need confirmed by what we did not specify and what Gervase requests. We acknowledged its structural existence through the RFC 5895. However, o we have not yet accepted its implications on the IDNA and the whole Internet architecture. o therefore, we did not work and complete yet a list of its requirements from an Internet point of view (IAB roadmap). o and as a result, we did not motivate ICANN and others to seriously consider all the resulting consequences; This is why I stated that I will try to complete an IUI Internet conformant framework description before: o ICANN economically and politically settles the technical confusion. o in being paid to accept studying requests of IDNgTLDs that it has absolutely no technical capacity, legal right and, therefore, political legitimacy to discuss and contract. Most will certainly dispute my description but my hope is that this will engage the debate that Lisa Dussault wanted, but which was not in our charter. My targetsare: o the completion of the first post-IDNA2008 phase (what I called IDNA2010, i.e. how to use IDNA2008 on the user side) that we need to achieve before o engaging in the second phase (what I called IDNA2012 - I was optimistic! - i.e. the way we adapt the Internet stratum to fully support IDNA2010 [punyplus, IANA, PRECIS, RFC 3935bis, langtags, net centricity documentation, externets, IP/ID/GRIDv6 consequences, general lessons on Internet+ architecture, etc.]) o while the IUTF (starting through the iucg@ietf.org liaison) will consider the resulting needs and opportunities (ML-DNS, anti-phishing algorithm, cybship operance, semiotic implications, distributed root and IANA, etc.) (NB. I know that I use terms that are new for some: they will be explained in the iucg-internet-plus I_D). jfc From jfc@morfin.org Mon Dec 12 19:51:43 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EBF21F8AA9 for ; Mon, 12 Dec 2011 19:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.051 X-Spam-Level: * X-Spam-Status: No, score=1.051 tagged_above=-999 required=5 tests=[AWL=-1.549, BAYES_80=2, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCaplFnztLtX for ; Mon, 12 Dec 2011 19:51:43 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 20BBC21F8AA8 for ; Mon, 12 Dec 2011 19:51:43 -0800 (PST) Received: from 45.188-227-89.dsl.completel.net ([89.227.188.45]:51382 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RaJP3-0006ys-Rd; Mon, 12 Dec 2011 19:51:42 -0800 Message-Id: <7.0.1.0.2.20111213043059.06488898@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 13 Dec 2011 05:01:31 +0100 To: iucg@ietf.org From: "J-F C. Morfin" 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 - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: "idna-update@alvestrand.no work" , "ca@linguasphere.info" Subject: [iucg] JOSDNs X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 13 Dec 2011 03:51:43 -0000 http://www.ted.com/talks/bobby_mcferrin_hacks_your_brain_with_music.html This scientific funny sequence shows the way semiotics works and how it differs from computers programming, and A,B,C methods. Everyone in the room follows this guy, without a single word being uttered or text being entered/displayed. However, any kid on earth can use this kind of communication and language to easily learn how connect its favorite site. Please remember that the real browser of the future is most probably Kinect+TV screen, and that JOSDNs (jabbed, oral, snapped domain names) are therefore already being supported. jfc From jmabdp@gmail.com Tue Dec 13 03:25:50 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E4021F88AB for ; Tue, 13 Dec 2011 03:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPl+Jw07vCnL for ; Tue, 13 Dec 2011 03:25:50 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id CB0C421F889A for ; Tue, 13 Dec 2011 03:25:49 -0800 (PST) Received: by wgbds13 with SMTP id ds13so10242356wgb.1 for ; Tue, 13 Dec 2011 03:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wZAg7HReqvJiZcjsmW94/1ewfTE2GxZlBhyzzCkiCtY=; b=o9ClEKXPHEZMCfQnwO20L3zUXfcLfHeCySuTZiM+z94EeqdoioZc5ezgSyeQPmctlW sh0AAEZAp0/8kAAmNgpe+lof/lIESp1mnsitxh26Ett7nKSutcphQ1t9d7lubTU4najf LEhLhimXEjDhLdQxalzujrsY2g/nR7hQesf0E= MIME-Version: 1.0 Received: by 10.180.90.6 with SMTP id bs6mr25264652wib.63.1323775548943; Tue, 13 Dec 2011 03:25:48 -0800 (PST) Received: by 10.227.59.142 with HTTP; Tue, 13 Dec 2011 03:25:48 -0800 (PST) In-Reply-To: <4EE72C6E.50901@mozilla.org> References: <4EE1ED1D.5000604@mozilla.org> <7A869EAD-2F27-4CA0-A35E-88B83A98C330@imc.org> <96CF61C4-8716-41BB-90A1-094C2040CE8B@frobbit.se> <20111211192002.GA46845@shinkuro.com> <933CB3D09DBB692797E80DA1@192.168.1.128> <4EE5A53E.3060402@it.aoyama.ac.jp> <4EE5EDD5.7040503@mozilla.org> <4EE726A2.9060302@it.aoyama.ac.jp> <4EE72C6E.50901@mozilla.org> Date: Tue, 13 Dec 2011 12:25:48 +0100 Message-ID: From: jean-michel bernier de portzamparc To: Gervase Markham Content-Type: multipart/alternative; boundary=f46d043be1985b6efc04b3f783d7 Cc: idna-update@alvestrand.no, =?ISO-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= , John C Klensin , iucg@ietf.org, Andrew Sullivan Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 13 Dec 2011 11:25:50 -0000 --f46d043be1985b6efc04b3f783d7 Content-Type: text/plain; charset=ISO-8859-1 2011/12/13 Gervase Markham > > We are certainly open to proposals D, E, F and beyond. (Although due to > the way Mozilla works, I can't promise an implementation timescale!) > Users only expect every browser to do its browser job and to possibly provide a choice among the 0, A, B, C, ... X, Y, Z protection technically and commercially competitive options. Please remember that ICANN and IETF are to foster competition in these areas in the best public interest. Disregarding the 0 protection option is therefore a marketing choice. My opinion is that it will lead many, if not most to use another browser offering that option. Portzamparc --f46d043be1985b6efc04b3f783d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/12/13 Gervase Markham <gerv@mozilla.org>

We are certainly open to proposals D, E, F and beyond. (Although due = to
the way Mozilla works, I can't promise an implementation timescale!)

Users only expect every browser to d= o its browser job and to possibly provide a choice among the 0, A, B, C, ..= . X, Y, Z protection technically and commercially competitive options. Ple= ase remember that ICANN and IETF are to foster competition in these areas i= n the best public interest.

Disregarding the 0 protection option is therefore= a marketing choice. My opinion is that it will lead many, if not most to u= se another browser offering that option.

Portzampa= rc
--f46d043be1985b6efc04b3f783d7-- From jefsey@jefsey.com Tue Dec 13 16:46:18 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DC31F0C50 for ; Tue, 13 Dec 2011 16:46:18 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E4 hex): To: Patrik F\344ltstr\366m ; Tue, 13 Dec 2011 16:46:18 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4966C1F0C4C for ; Tue, 13 Dec 2011 16:46:18 -0800 (PST) Received: from 45.188-227-89.dsl.completel.net ([89.227.188.45]:56726 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Racz6-0005xS-KF; Tue, 13 Dec 2011 16:46:13 -0800 Message-Id: <7.0.1.0.2.20111213111407.06488db8@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 14 Dec 2011 01:56:05 +0100 To: Patrik Fältström ,Tina Dam From: JFC Morfin In-Reply-To: <1808ACFA-D089-4B79-81DC-6ECB2E8330C2@frobbit.se> References: <4EE1ED1D.5000604@mozilla.org> <7A869EAD-2F27-4CA0-A35E-88B83A98C330@imc.org> <96CF61C4-8716-41BB-90A1-094C2040CE8B@frobbit.se> <4EE6E028.2050501@it.aoyama.ac.jp> <1808ACFA-D089-4B79-81DC-6ECB2E8330C2@frobbit.se> 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: Cc: "Martin J. Dürst" , idna-update@alvestrand.no, iucg@ietf.org Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 14 Dec 2011 00:46:18 -0000 At 07:44 13/12/2011, Patrik Fältström wrote: >ICANN only police the TLD, no other levels in the domain name tree. Uncorrect. ICANN only try to police the minority of NTIA root TLD managers who contracted with them. IETF is for everyone who use TCP/IP. Anyway, all this debate looks like the IETF people being reasonable but trying evading responsibility by hiding behind ICANN? Let clarify: Vint attempted to transfer responsbility of the post-IDNA2008 work to ICANN. However: - ICANN has not taken the bait. - Lisa's architectural questions belong to the IETF scope and have to be addressed first. - ICANN, as everyone else, has no capacity to speak on behalf of all the Internet Users. Gervase was correct in soughting opinions. No one has legitimate authority nor practical capacity to decide for the whole existing and future internet community. The only thing which can be done is for some to document what they suggest (IAB), what they think (this thread), or what they intend to do or already did. Pragmatically, since IAB did not wish to provide guidance and opinions are divided, what will actually forge the future are those who specify, develop, test and deploy. They are authoritative for the community of those adhering to their postulates or locked in their "+" services. This is traditionally called in IETF jargon a market decision. It should traditionnally be made under IETF influence (RFC 3935) for the Internet to work better. However, this thread shows that a RFC 3935bis is first needed to document what "work better" means today. This is what browser manufacturers, as many others, try to be told, in order to build a "better internet" window in the http web application context. jfc From jfc@morfin.org Mon Dec 19 06:18:46 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8FA1F0C47 for ; Mon, 19 Dec 2011 06:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTKF6nTkC5zN for ; Mon, 19 Dec 2011 06:18:45 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 674471F0C43 for ; Mon, 19 Dec 2011 06:18:45 -0800 (PST) Received: from 147.111-227-89.dsl.completel.net ([89.227.111.147]:53842 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Rce34-00077L-R0; Mon, 19 Dec 2011 06:18:39 -0800 Message-Id: <7.0.1.0.2.20111219131810.0b49f710@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 19 Dec 2011 15:16:06 +0100 To: Gervase Markham ,Raed Al-Fayez From: "J-F C. Morfin" In-Reply-To: <4EEF1505.7070306@mozilla.org> References: <4EE1ED1D.5000604@mozilla.org> <4EEF1505.7070306@mozilla.org> 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 - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: "idna-update@alvestrand.no" , iucg@ietf.org Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 19 Dec 2011 14:18:46 -0000 At 11:42 19/12/2011, Gervase Markham wrote: >Hi Raed, >Thank you for your input. > >I would say that the vendor you quote is using sloppy language and it's >not actually about 'prioritizing English', but your point about >first-class citizenship is a good one. No one is prioritizing English. English IS, by mutual convenience, the Internet language (cf. RFC 3935). This is why the IETF solution is "internationalization" and not "multilingualization". Internationalization is a component of "globalization" together with "localization" and "langtags" and is embodied in CLDR tools. Internationlization is to make the medium (here the Internet) language neutral. For that it uses an International English and ASCII programming to quote Unicoded strings independently from the actual language these strings correspond to (identfied by the langtag), including English. These quotes are of two forms: the real text, i.e. a batch of code points, or an URL that permit an option indirect access. For good consustency (RFC 1958) the quotes should use the same script displaying context (UTF-8). IDNA2008 has organized this to properly work through: - an Internet technology core, - and a subsidiary support of languages at the periphery. In this architecture it happens that the Internet architectural core happens to currently work in ASCII, but it could work the same in any other charset, including binary.(what may be the evolution of the Internet 2.0 architecture). IDNA2008 however has left two unaddressed issues. 1. to be broadly explained as being an example of the way the end to end Internet architecture actually (RFC 1958) supports diversity, any diversity. This support is at the intelligent fringe to fringe layer set which includes the presentation layer. The difficulty is that OSI was wrong: the OSI model in uncomplete and the layer pile must dissociate Network and Subsidiary Network Use layers. I appealed against the lack of a IAB/IESG disclaimer which would have prevented the current debate. The response I obtained clearly indicated that this issue did not belong to the IETF scope, but that IETF wanted to detail its own needs in this area. This is why I delayed as much as I could the description of the fringe to fringe IUI framework. However, the technically illegitimate ICANN opening to gTLD registration calls for it to be published before January 10. 2. fringe to fringe calls for metadata exchanges: IDNA2008 has not considered the need to support orthotypography (i.e. script use variations depending on the meaning). Basically what you say about second-zone languages also applies to real life English which actually needs more than the ASCII charset, and obviously to French as I reported it to the IESG. The management of the fringe to fringe metadata intercommunications is more complex than the data intercommunications. It calls for a dedicated channel that has to be transparent to the existing core technology and common usage. What Gervase asks for is to be told how this is to work. >If all registries were are responsible as yours, there would hardly be a >need for browser restrictions on IDN display at all (perhaps just a >blacklist of homographs for "." and "/", and that should have been >achieved by IDNA2008 anyway). This "registries being responsible" is an wrong interference where we technicians are judging use, instead of supporting it properly. The principle of the Internet is that technology is to best support the user needs and the IETF is to influence those who design, use and manage the Internet for it to work better. The problem are (1) that no one ever explained what working "better" means and (2) that some of us want to unilaterally constrain uses along with their own understanding of that "better" means, moreover in areas where things have not been fully defined. > > IDNs should not be treated as second-class citizens on the Internet. > >I entirely agree. This is why we went for option B - once a registry has >a responsible policy, their IDNs are treated as first-class citizens >everywhere (at least, in Firefox). No additional configuration required. This means that you decide who is a second-zone Registry and treat their registrants as third-zone netizens. Then the question unfortunately comes: "Who made you king to decide this?" >Unfortunately, IDNs are still not treated as first-class citizens. So >the question is: how do we get from where we are now to a situation >where they are treated that way? This is easy as far as you are concerned. - you treat them as your user application layer is to treat them: as unique-class Internet Domain Name citizens. - you demand those who are to take care of the difficulties you identify to address them properly. They are the IAB and the emerging IUTF (on the iucg@ietf.org) where this mailing thread belongs since the WG/IDNAbis is closed, its RFC set is published, and the remaining points are on the IDNA2008 use side. Cheers. jfc From jefsey@jefsey.com Wed Dec 21 07:30:35 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668CE21F893C for ; Wed, 21 Dec 2011 07:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.092 X-Spam-Level: X-Spam-Status: No, score=-100.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2uHh8lTOyKQ for ; Wed, 21 Dec 2011 07:30:34 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9521F88A0 for ; Wed, 21 Dec 2011 07:30:34 -0800 (PST) Received: from 147.111-227-89.dsl.completel.net ([89.227.111.147]:64680 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RdO7l-0002P4-Rv; Wed, 21 Dec 2011 07:30:34 -0800 Message-Id: <7.0.1.0.2.20111221155216.06458cd0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 21 Dec 2011 15:53:26 +0100 To: Jari Arkko From: JFC Morfin In-Reply-To: <4EF1CB61.4040500@piuha.net> References: <4EF1CB61.4040500@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: iucg@ietf.org Subject: Re: [iucg] cross-area work at the IETF X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 21 Dec 2011 15:30:35 -0000 At 13:04 21/12/2011, Jari Arkko wrote: >http://tools.ietf.org/html/draft-arkko-iesg-crossarea-00 I created an IUWW on this Draft: http://iucg.org/wiki/User_Area which is of fundamental interest to us. jfc From jfc@morfin.org Wed Dec 21 07:30:41 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BDC21F8A57 for ; Wed, 21 Dec 2011 07:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQbhDG9kLNzF for ; Wed, 21 Dec 2011 07:30:40 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2A721F893C for ; Wed, 21 Dec 2011 07:30:40 -0800 (PST) Received: from 147.111-227-89.dsl.completel.net ([89.227.111.147]:64679 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RdO7m-0002P3-Hr; Wed, 21 Dec 2011 07:30:35 -0800 Message-Id: <7.0.1.0.2.20111221150027.064588f8@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 21 Dec 2011 16:29:39 +0100 To: Gervase Markham , "Abdulrahman I. ALGhadir" From: "J-F C. Morfin" In-Reply-To: <4EF1BBC8.8070601@mozilla.org> References: <4EE1ED1D.5000604@mozilla.org> <4EEF1505.7070306@mozilla.org> <4EF1BBC8.8070601@mozilla.org> 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 - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: "idna-update@alvestrand.no" , iucg@ietf.org Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 21 Dec 2011 15:30:41 -0000 At 11:58 21/12/2011, Gervase Markham wrote: >As I understand it, these sites are merely records of policy; no >restrictions are imposed. So if .newtld decided to register with IANA to >say "we accept every character", then the tables would duly record that >fact, despite there being a big potential problem. > >So, unless I have missed something, such lists are of no help in this >situation. Gervase, please let stay within the RFC framework. The DNS is built to accept every byte. IDNA2008 accept RFC 5892 UTF-8 characters. Internet DNS practice favors ASCII only. This is the universal policy by default. Every zone manager may restrict its registrations policy and universally publish it (TLDs) or not (other zone managers). Your request is to know when a domain name entered by a user conforms or not with this registration policy, so you may practice your own policy to be defined. 1. there is as yet no protocol for TLD to disseminate that information between them and application designers. 2. You may engage into a BoF to show that such a protocol is necessary for the Internet to work better and propose an IETF WG Charter. 3. personnally I think that such a protocol belongs to the whole digital ecosystem area and is to be discussed and possibly standardised outside of the sole IETF. Its discussions calls for the preliminary emergence of its requirement out of experimentation. Such an Internet+ community experimentation has been engaged through the files documented by Abdulrahman, ICANN work on variants, and works engaged within the IUse community within the so called "IDNA2012" framework (the so called IDNA2010 being the issues on the user side). jfc From jfc@morfin.org Sat Dec 24 17:38:05 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6A721F848E for ; Sat, 24 Dec 2011 17:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFw+OinEUaDB for ; Sat, 24 Dec 2011 17:38:04 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id B32B421F8488 for ; Sat, 24 Dec 2011 17:38:04 -0800 (PST) Received: from 194.141-227-89.dsl.completel.net ([89.227.141.194]:51006 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Red2C-0001Hv-8U; Sat, 24 Dec 2011 17:37:56 -0800 Message-Id: <7.0.1.0.2.20111225021457.05d29bd0@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 25 Dec 2011 02:37:15 +0100 To: "Abdulrahman I. ALGhadir" , Gervase Markham From: "J-F C. Morfin" In-Reply-To: References: <4EE1ED1D.5000604@mozilla.org> <4EEF1505.7070306@mozilla.org> <4EF1BBC8.8070601@mozilla.org> 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 - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: "idna-update@alvestrand.no" , iucg@ietf.org Subject: Re: [iucg] Browser IDN display policy: opinions sought X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 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, 25 Dec 2011 01:38:05 -0000 At 06:47 24/12/2011, Abdulrahman I. ALGhadir wrote: >I guess you have missed something. >The second link was broken I didn't copy it correctly and I think >that you haven't check it, have you? > >http://www.icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm > >When you want to register an IDN you should define the script and >the language which your label will follow. > >http://www.icann.org/en/topics/idn/fast-track/idn-cctld-implementation-plan-15dec11-en.pdf >(check 3.2) >http://www.icann.org/en/topics/new-gtlds/rfp-clean-19sep11-en.pdf >(check 1.3.1) > >As you see it is part from ICANN application process and it is a >must and I think this will help us in having a solid resource which >can provide us with needed information? Dear Abdulrahman, the only documents that should be considered by Gervase: - MUST be RFCs (i.e. RFC 5890-5895) in particular RFC 5895 which gives him an example. - SHOULD be IANA files. - MAY be ICANN files as examples of what a money centric network community may want to do (NB culturally or people centric network community or coporate private networks might want to do differently). Best jfc