From nobody Thu Jan 8 05:19:44 2015 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5511A1EEB; Thu, 8 Jan 2015 05:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vVad02JE_zD; Thu, 8 Jan 2015 05:19:36 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92E41A1A58; Thu, 8 Jan 2015 05:19:36 -0800 (PST) Received: from 223.57.14.81.rev.sfr.net ([81.14.57.223]:10595 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Y9Czu-0001JK-EG; Thu, 08 Jan 2015 05:19:35 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Jan 2015 14:19:24 +0100 To: Marc Blanchet , "Ianaplan@Ietf. Org" , "Leslie Daigle (TCE)" From: JFC Morfin In-Reply-To: <53675CAE-BB02-41EF-9E4B-04EA0E047FF2@viagenie.ca> References: <53675CAE-BB02-41EF-9E4B-04EA0E047FF2@viagenie.ca> 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 - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] numbers community plan X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 13:19:41 -0000 At 00:26 08/01/2015, Marc Blanchet wrote: >happy new year! >Following up the note John Curran sent to this list >(http://www.ietf.org/mail-archive/web/ianaplan/current/msg01482.html) > with the pointer to the draft numbers community plan >(https://www.nro.net/news/first-draft-proposal-of-the-internet-number-community-for-the-iana-stewardship-coordination-group), >are there any issues that we believe the IAB should consider >flagging and discussing? For the purposes of this WG's discussion, >the focus should be scoped to issues that might affect the IETF >protocol parameter registries, not general opinions on the numbers >proposal [1]. Dear Marc and Leslie, I wish a Happy New Year to the two splitting strata: catenet and internet. I have tried for years to jointly accommodate their parallel evolution under the IETF. The life of this WG has led me to crash create the IUWG.net to stay in line with RFC 6852 ***and*** independent from the BCP 78 Internet license. The Catenet, i.e. the people's global common substructure of the different RFC 6852 "global communities"' technologies, calls for an OpenUse approach that is to be explored, determined, and documented. I identify two needs. 1. for the IETF family to publicly acknowledge that the situation that some of them have described through the RFC 6852 is not a multistakeholder situation led by the I*core but rather a permissionless innovation omnistakeholder configuration. This means that the I*core must identify itself as a global community among other Catenet user global communities. This calls for at least two things: - ISOC to state it in one way or another (and this is where an appeal seems necessary) - and a single interfacing IETF technology window to be given to the world, which I think is to be "http://iana.arpa". 2. The people's Catenet multitechnology support capacity is to be discussed and documented, i.e. the way each CPU/OS/fringe/edge communicates is to be supported by the various end to end technologies, including the Internet ones (IPv4/v6), Rosettanet, NDN, SDNs, Ethernet, Libre's interplus, etc. Today, the IETF, IAB, IEEE, ISOC, W3C, and others have jointly but still incompletely accepted this situation. ICANN has not: they want to use their CLASS "IN" control, IP address influence, and their US jurisdiction to control the Catenet. Jari is probably right in not necessarily wishing to publish the Ianaplan document as an RFC. That plan is about the way the IETF wants the IAOC to negotiate the ICANN http://iana.arpa accountability framework. I disapprove of the text in part but I have no reason to appeal the decision of asking it. In such a case, I will document a Catenet oriented openuse I_D including the ICANN/ICP-3 rules and the proposition of a joint WG on a multitechnology oriented IANA protocol. If it is published by the RFC Editor, the situation will be clarified and I could adhere to OpenStand. If it is not, then a formal appeal to IESG/IAB/ISOC will be necessary, but it will be on simpler/clearer grounds for everyone. Best, jfc From nobody Fri Jan 9 05:29:32 2015 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B491A87A0; Fri, 9 Jan 2015 05:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R42nAt1tMTG; Fri, 9 Jan 2015 05:29:25 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34D51A879D; Fri, 9 Jan 2015 05:29:24 -0800 (PST) Received: from 223.57.14.81.rev.sfr.net ([81.14.57.223]:22263 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Y9Zcx-0000pr-7G; Fri, 09 Jan 2015 05:29:23 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 Jan 2015 14:29:13 +0100 To: Eliot Lear ,"ianaplan@ietf.org" From: Jefsey In-Reply-To: <54AE9663.4010706@cisco.com> References: <54AE9663.4010706@cisco.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 - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: gene@iuwg.net, "iucg@ietf.org" , iab , iesg@ietf.org Subject: Re: [iucg] [Ianaplan] Taking a step toward the IANA Transition X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 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 Jan 2015 13:29:26 -0000 At 15:38 08/01/2015, Eliot Lear wrote: >Jari and I have put together a short blog on where we are. This working >group in particular should be pleased with its work. > >http://www.ietf.org/blog/2015/01/taking-a-step-towards-iana-transition/ > >Eliot Jari and Eliot, I do not understand. Is the draft to be published as an RFC, yes or no? This is not immaterial: since if it is to be published I only have until March 6, 2015 to file an appeal, of which the matter is now clarified by the eventual IESG choice of a US leadership on the IETF technology that you made official yesterday. Lynn St-Amour is rightly pleased. Many are most probably not. You fully understand that the sentence "When ready, they will submit the final proposal to the NTIA. The NTIA must then consider and approve the proposal", being co-signed by the IETF Chair, is of a purely political nature and cannot have anything to do with any technical norm concerning my and people's personal Catenet properties. Therefore, there was a global IETF. http://www.ietf.org/blog/2015/01/taking-a-step-towards-iana-transition/ changed that: you have now formally published that it forked to a USIETF. One of the IETF core values was to responsibly decide on an "omnistakeholder" rough consensus basis. If the NTIA is now to first approve its propositions, why not China, Russia, Germany, UK, France, etc.? And/or Google, Apple, Xerox, NSA, etc.? There can only be one single authoritative internet technical sovereignty: http://iana.arpa. It owns this sovereignty because: - there must be a "Respectful cooperation between standards organizations, whereby each respects the autonomy, integrity, processes, and intellectual property rules of the others" (RFC 6852). - "Standards processes are transparent and opportunities exist to appeal decisions", - Users and people may uniquely identify it and freely adhere to it, thereby forming the Internet global community. The RFC 2026 Internet standards process has not thus far required anyone to "submit the final proposal to the NTIA, for the NTIA to consider and approve", unless the NTIA is the new IAB's name as the "Network Technical Independent Authority". Perhaps I am wrong: this was probably before, when "Standards activities [were] not exclusively dominated by any particular person, company, [] interest group [or nation]" (cf. RFC 6852). I appealed RFC 6852 because it did not clarify who its ultimate referent was. We now know that it is the USG. I beg to disagree, however, because nations, like the internet, form neither a hierarchical nor a decentralized but rather a distributed network. You crossed the border between technology and policy, between what is to be technically and what some may want to be: thi way you unfortunately but definitely put the IETF technology in jeopardy and politically fragmented the internet after RFC 6852 tried to patch its technical fragmentation risks. I frankly doubt this is what Lawrence E. Strickling wanted the world to perceive. Sorry. jfc From nobody Fri Jan 9 07:33:56 2015 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184881A6EFE; Fri, 9 Jan 2015 07:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkmJccWK50Tm; Fri, 9 Jan 2015 07:33:48 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0221A01C6; Fri, 9 Jan 2015 07:33:48 -0800 (PST) Received: from 223.57.14.81.rev.sfr.net ([81.14.57.223]:23351 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Y9bZK-0001tv-Sl; Fri, 09 Jan 2015 07:33:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 Jan 2015 16:33:36 +0100 To: Eliot Lear ,"ianaplan@ietf.org" From: Jefsey In-Reply-To: <54AFDF0B.3070702@cisco.com> References: <54AE9663.4010706@cisco.com> <201501091329.t09DTP5b029007@rcdn-core-7.cisco.com> <54AFDF0B.3070702@cisco.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 - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: gene@iuwg.net, "iucg@ietf.org" , iab , iesg@ietf.org Subject: Re: [iucg] [Ianaplan] Taking a step toward the IANA Transition X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 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 Jan 2015 15:33:50 -0000 At 15:00 09/01/2015, Eliot Lear wrote: >The IESG has taken its decision, and the document stands approved. It >will be published as an RFC. Thank you, for all your clarifications. 1) The report of Jari was confusing. > fully understand that the sentence "When ready, they will submit > > the final proposal to the NTIA. The NTIA must then consider and > > approve the proposal", being co-signed by the IETF Chair, is of a > > purely political nature and cannot have anything to do with any > > technical norm concerning my and people's personal Catenet properties. > >If you are referring to the blog, of course it is not normative to our >processes, but informative to the community. 2) Absolutely. This was the missing information which motivated my initial appeal. This is now formally clarified. Everyone is now able to best decide for themselves and for their users. >herefore, there was a global IETF. > > > http://www.ietf.org/blog/2015/01/taking-a-step-towards-iana-transition/ changed > > that: you have now formally published that it forked to a USIETF. > >I don't know who the USIETF is, but this organization is known as the IETF. 3) Loud and clear: - you do not know (yet) who is USIETF-leader (Jari or Lawrence?) - you confirm that this organization is currently known as the IETF. Simpler to call it USIETF as there is AmerICANN allready. Situation seems to be under regular/legal US control. > > One of the IETF core values was to responsibly decide on an > > "omnistakeholder" rough consensus basis. If the NTIA is now to first > > approve its propositions, why not China, Russia, Germany, UK, France, > > etc.? And/or Google, Apple, Xerox, NSA, etc.? > >It was the NTIA who sought information through ICANN. If China or >anyone else cares to ask us a question, we can determine how best to >answer them just as we did in this case. Still confusing: - NTIA informed ICANN they could transfer some CLASS "IN" oversight. - ICANN overdid it, hearing "IANA" instead. - an USIETF RFC frees ICANN from its accountability to IAB/IETF. IESG/IAB/ISOC and NTIA plain language confirmation advisable. No problem. This will be the purpose of my appeal. Alles klar. The user community can now constructively build a stable IETF/ICANN accountability framework in this clarified context. Thank you for that. Best. jfc From nobody Sat Jan 24 18:50:55 2015 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661521A1DE1; Sat, 24 Jan 2015 18:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.931 X-Spam-Level: * X-Spam-Status: No, score=1.931 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZUD9kPX_h6O; Sat, 24 Jan 2015 18:50:51 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C231A1A90; Sat, 24 Jan 2015 18:50:50 -0800 (PST) Received: from 213.218.130.77.rev.sfr.net ([77.130.218.213]:63492 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1YFDHj-0000n5-Gz; Sat, 24 Jan 2015 18:50:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jan 2015 03:50:39 +0100 To: Vint Cerf ,Martin J. =?iso-8859-1?Q?D=C3=BCrst?= From: JFC Morfin In-Reply-To: References: <133d6a2ef20b3ab18f0fcd211c78cae5.squirrel@www.ccil.org> <20150121213124.GV2350@localhost> <54C06741.9020509@ix.netcom.com> <54C210E8.9000608@it.aoyama.ac.jp> 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 - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: Asmus Freytag , "idna-update@alvestrand.no" , "iucg@ietf.org" , John C Klensin , gene@iuwg.net, The IESG Subject: Re: [iucg] [Json] Json and U+08A1 and related cases X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 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 Jan 2015 02:50:52 -0000 At 15:44 24/01/2015, Vint Cerf wrote: >I do wonder whether it is worth considering an attempt to create a >new set of properties of UNICODED characters that are of specific >use to the DNS. The IDNA 2008 work tried to use properties of >characters developed for purposes other than the DNS and the fit is >not always perfect. We are discussing a three steps multi-layer digital name system (ML-DNS) to be used by multiple applications and network technologies on the.catenet: 1. I enter a string A in my local querry system which punycodes it into string B so it may be used by the next step. (RFC 4895) 2. The string B is entered in the Domain Name Service of the concerned CLASS to get an IP address. 3. the string B is restored as A' in the destination system. The target is that A'=A. For your information. As part of the ICP-3 conformant IUser community testing for the Catenet we want to experiment the following multi-ledger/multi-echnology approach (ML-DNS):: 1. for the CLASS "IN" ledger of registries of ICANN/NTIA/Verisign: the step 1/step 3 back and forth conversion algorithm is: - either " A=B/B=A when A and B are restricted to the ASCII list". - or punycode otherwise. 2. for the private CLASS "FL" (Free/Libre) ledger of registries by DNSLIB: the step 1/step 3 back and forth conversion algorithm is: - either " A=B/B=A when A and B are restricted to the ASCII list". - or punycode applied to the UNISIGN semiotic (Free/Libre) sign set. - or no registration permitted/filtering out otherwise. UNISIGN only includes non-confusable character and non character signs. Confusable characters share a unique common sign-point. The UNISIGN table results from a non-confusability algorithm under financing/work, It should be based upon rastering comparison in an UNISIGN fount of reference. jfc From nobody Sun Jan 25 05:50:25 2015 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E101A1A5B for ; Sun, 25 Jan 2015 05:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEaJPc9O_YpK for ; Sun, 25 Jan 2015 05:50:06 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747871A1A59 for ; Sun, 25 Jan 2015 05:50:06 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YFNZd-0009ZN-Vb; Sun, 25 Jan 2015 08:49:57 -0500 Date: Sun, 25 Jan 2015 08:49:52 -0500 From: John C Klensin To: JFC Morfin Message-ID: <3B87C662BA23FDEFFF3EBAA5@JcK-HP8200.jck.com> References: <133d6a2ef20b3ab18f0fcd211c78cae5.squirrel@www.ccil.org> <20150121213124.GV2350@localhost> <54C06741.9020509@ix.netcom.com> <54C210E8.9000608@it.aoyama.ac.jp> 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-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: gene@iuwg.net, idna-update@alvestrand.no, iucg@ietf.org Subject: [iucg] Alternate coding environments (was: Re: [Json] Json and U+08A1 and related cases) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 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 Jan 2015 13:50:21 -0000 (address list trimmed to IDNA and IUCG lists, with apologies to the former, but this one seems to need a response) --On Sunday, January 25, 2015 03:50 +0100 JFC Morfin wrote: > We are discussing a three steps multi-layer digital name system > (ML-DNS) to be used by multiple applications and network > technologies on the.catenet: > > 1. I enter a string A in my local querry system which > punycodes it > into string B so it may be used by the next step. (RFC > 4895) > 2. The string B is entered in the Domain Name Service of the > concerned > CLASS to get an IP address. > 3. the string B is restored as A' in the destination system. > > The target is that A'=A. I either don't understand this or don't see why it is either necessary or desirable: If the operation of (1), which I will restate for clarity as conversion of String A to an A-label as specified by IDNA2008, produces a String B that can be found in the public DNS (which means QCLASS=IN for all known Internet applications these days), then the above is either unnecessary or identical to what IDNA2008 requires. Note, in particular, that the dual relationship between A-labels and U-labels guarantees that A==A'. Conversely, if you want String A to be something that cannot be represented directly in the DNS, at least under IDNA rules (or, given some of your observations about Majuscules, etc., perhaps even in Unicode), then it seems to me that you should be doing something that we've discussed on and off for well over a decade, specifically: (i) Look A up in some non-DNS database whose matching algorithms conform to your needs, yielding a string C. One important property of that database should be that actual lookups of name by value (as well as value by name) should be feasible. FWIW, note that such lookups were anticipated by the original DNS design but dropped (and replaced by, e.g., a separate reverse mapping tree for addresses) when they turned out to be incompatible with other aspects of that design. (ii) For maximum interoperability with the rest of the Internet, look up C normally in the DNS, CLASS-IN, yielding addresses of other records important to you. (iii) When and as needed, go back to your database to map C to A (A' if you like but, if there is only one table and it is used for both forward and reverse mappings, the identity relationship is guaranteed). Interestingly, in the model above, there is no need for C to be in the encoding produced by the Punycode algorithm, to use the IDNA "xn--" prefix, or to obey any conventions other than you own. You would actually gain some simplicity and resistance against attacks and the sort of possibly-incorrect matching issues that have been the topic of this thread (and many others over the years) by making C a pseudo-random, all-ASCII, value rather than relying on a trick encoding. The only requirement on C is that it be unique, and there are lots of ways to accomplish that. Also see your Case (2) below. > For your information. > > As part of the ICP-3 conformant IUser community testing for the > Catenet we want to experiment the following > multi-ledger/multi-echnology > approach (ML-DNS):: > > 1. for the CLASS "IN" ledger of registries of > ICANN/NTIA/Verisign: > > the step 1/step 3 back and forth conversion algorithm is: > - either " A=B/B=A when A and B are restricted to the > ASCII list". > - or punycode otherwise. See above. If A and B are both ASCII, those relationships are guaranteed by the basic DNS design modulo case-independent matching and non-preservation of case in a variety of contexts where compression is involved. If you need case preservation in the ASCII range, you either cannot use the DNS or have to use a trick encoding for everything, including all-ASCII labels. Whatever that encoding might be, the Punycode algorithm, which makes some special assumptions about all-ASCII labels, won't be appropriate. > 2. for the private CLASS "FL" (Free/Libre) ledger of > registries by DNSLIB: > > the step 1/step 3 back and forth conversion algorithm is: > - either " A=B/B=A when A and B are restricted to the > ASCII list". > - or punycode applied to the UNISIGN semiotic > (Free/Libre) sign set. > - or no registration permitted/filtering out otherwise. First, note that the Punycode algorithm was designed specifically for the Unicode repertoire and block-layout system. It is an optimization for that system that, in particular, has better (shorter-string) properties than UTF-8 for strings of Unicode code points with particular characteristics, notably when there are short distances among the numerical values of the code points in the label string and many or all of those code points have sufficiently high numeric values to require three-octet encodings. > UNISIGN only includes non-confusable character and non > character > signs. Confusable characters share a unique common sign-point. If you are going to use a repertoire and/or coding system different from Unicode, then the Punycode algorithm is very unlikely to make any sense. If you can use the DNS for your own purposes and encoding, intend to use a separate CLASS, and can control the coding so that it meets your needs, then there are probably no advantages of using anything other than your native coding. Remember that the DNS is perfectly happy with labels consisting of octets with arbitrary values and compares them perfectly and consistently. The difficulties that led to IDNA arise from three things: (a) What now seems like a peculiarity that octets whose values are consistent with letters in the ASCII range are compared case-independently but nothing else is (b) Within CLASS=IN, ASCII is basically assumed for octets in the range 0x00 to 0x7F; for octets outside that range, the character repertoire and encoding are unspecified and those octets are not assumed to be character data at all. For other CLASSes, you could easily specify a CLASS-wide character set and encoding and design that encoding to not trigger any DNS idiosyncrasies. (c) Many applications limit their identifiers and associated DNS labels to ASCII-only. IDNA was designed to avoid having to upgrade all of those applications as a condition for deploying IDNs. Because introducing a new coding system or lookups in a different database or different DNS CLASS requires upgrading all relevant applications anyway, you don't have that constraint. > The UNISIGN table results from a non-confusability algorithm > under > financing/work, It should be based upon rastering comparison > in an UNISIGN fount of reference. Good luck with that and do let us know, ideally in the peer-reviewed literature, how it works out. It may work if you can select (and perhaps design) a single type family and eliminate all others from your enviornment, ideally eliminating all stylistic variations (like italics or bold for many Latin-based type families) within that family as well. That would leave you in a situation in which characters that were confusing in your reference font might not be in more normal ones and vice versa. It would, of course, work even better if you restrict the scripts of interest. Otherwise, for example, the visual (and likely raster and even vector) similarity between U+03BB and U+5165, a resemblance that I think we can be quite confident is entirely coincidental and one where even a few characters of context would likely be adequate to make a distinction, would result in a single code point in your system. I think I've mentioned this to you before, but anyone contemplating automatic confusability detection based on raster or vector properties of printed/written characters should examine the pre-Kurzweil (mid-to-late 1960s) literature in optical character recognition as a starting point in understanding how difficult it is to get from abstractions of characters to character identification. From nobody Thu Jan 29 10:57:53 2015 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4231A1EFE for ; Thu, 29 Jan 2015 10:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.03 X-Spam-Level: **** X-Spam-Status: No, score=4.03 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_BODY_HIGH_NO_MID=3.199, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=0.6, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuxEa4QKKM4I for ; Thu, 29 Jan 2015 10:57:48 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749251A1BED for ; Thu, 29 Jan 2015 10:57:40 -0800 (PST) Received: from 114.214.130.77.rev.sfr.net ([77.130.214.114]:9683 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1YGuHa-0005ee-U1; Thu, 29 Jan 2015 10:57:39 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Jan 2015 19:56:31 +0100 To: John C Klensin ,JFC Morfin From: "J-F C. Morfin" In-Reply-To: <3B87C662BA23FDEFFF3EBAA5@JcK-HP8200.jck.com> References: <133d6a2ef20b3ab18f0fcd211c78cae5.squirrel@www.ccil.org> <20150121213124.GV2350@localhost> <54C06741.9020509@ix.netcom.com> <54C210E8.9000608@it.aoyama.ac.jp> <3B87C662BA23FDEFFF3EBAA5@JcK-HP8200.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 - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: gene@iuwg.net, idna-update@alvestrand.no, iucg@ietf.org Subject: Re: [iucg] Alternate coding environments (was: Re: [Json] Json and U+08A1 and related cases) X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 18:57:51 -0000 Dear John, I am sorry for the dealy in responding to this. Things are changing with some ambitious cooperative project demanding a lot of French/Local involvment. This helps maintaing the health. At 14:49 25/01/2015, John C Klensin wrote: >I either don't understand this or don't see why it is either >necessary or desirable: I understand you do not understand: we do not want to address the same need. Let me digress =========== I want a robust basic response to the "if it looks the same, it is to be the same" need. You want the best DNS system that can use Unicode. Your limit is perfect logic. My limit is reality. This is a common scientific difference between effective (me) and fundamental (you) thinking. Both are correct. The only thing is that yours introduces at least two spaces [rules and data] within the same considerations (so it is often more complex and more demanding). This is why I prefer to split them differently, considering fundamental as architectonics and effective as operationalism. This way I avoid (this is a general consideration of the Universe) to answer initial questions on the reality of the time that Einstein and many others before and further on have made to disapear. In a nutshell, I live in a single universe, rather than discussing a multiverse: this allows me to consider a rough multi-internet in a single universe, rather than a single perfect internet in each universe of a multiverse. I certainly think that networking brings basic metaphores to cosmology, but no need for now :-) Specific of this case =============== The difference is who is the master: the machine (theoretical and logic, in a local context) or the person (practical and "agoric", i.e.in an holistic global context). - UNICODE is a codepoint based system, i.e. the reference is what UNICODE has decided to be a character. - UNISIGN is a semiotic signpoint based system, i.e. what a common reader decides he/she sees/feels. We try to reduce it to UNIGRAPH, i.e. what the machine AND all the readers (statistics) are supposed to accept. Your system makes sure that A -> A-label -> B=A. when there re computers with the same software at both ends. Reality does not insure that A =H= B =H= A if =H= means "equals" by mutiple/different-humans reading. This work story =========== Remember when we started this WG I said I would support its work as long as there would be no MUST on the end to end path, and I would document a middle layer IDNA2008 based ML-DNS solution further on. There was some layer confusion but the RFC 5895 proposition addressed them, permitting a consensus, introducing the subsidiarity principle in order to embed INDA2008 into real-life diversities (except for orthotypography and French Majuscule like issues). IMHO, this was a major advancement in the overall Internet architectural design. But it was permitted by the RFC 5895 unlocking, the IESG did not accept as a part of the WG work; and the French majuscules generic issue was not addressed (we would not face a problem today if it had been). As for IDNA2003, time was necessary to observe the field results of IDNA2008 as an Unicode end to end "IDNS". What I observe (my diagnosis) is that fringe to fringe ML-DNS is necessary and either calls for a non-confusability algorithm or for a Unicode replacement (either a complex one as UNISIGN (the whole semiotic), or more rustic one as UNIGRAPH (only the character sets)). The new context of this debate ======================= Now, your points are made with CLASS="IN" in mind and in a pre-20150108 context (http://www.ietf.org/blog/2015/01/taking-a-step-towards-iana-transition/). Mine's are those of a member of: - an RFC 6852 global - non-NTIA dependent - community - which is in unformal standard technical innovation coopetition with the IETF - which respect the ICP-3 recommendations and only consider CLASS="FL" (Free/Libre), [for the time being as a private CLASS]. So, I am not anymore discussing IETF considerations for a global standard to be documented by http://iana.arpa. IETF leaders decided they did not want to assume this responsibility. I am just contributing on behalf of a young and loose Libre Community WG about what we consider in an multioperable context (shared ISP switchers - compatibility with our own UNINAME need, i.e. for a member directory). >If the operation of (1), which I will restate for clarity as >conversion of String A to an A-label as specified by IDNA2008, >produces a String B that can be found in the public DNS (which >means QCLASS=IN for all known Internet applications these days), >then the above is either unnecessary or identical to what >IDNA2008 requires. Note, in particular, that the dual >relationship between A-labels and U-labels guarantees that A==A'. > >Conversely, if you want String A to be something that cannot be >represented directly in the DNS, at least under IDNA rules (or, >given some of your observations about Majuscules, etc., perhaps >even in Unicode), then it seems to me that you should be doing >something that we've discussed on and off for well over a >decade, specifically: > >(i) Look A up in some non-DNS database whose matching algorithms >conform to your needs, yielding a string C. One important >property of that database should be that actual lookups of name >by value (as well as value by name) should be feasible. FWIW, >note that such lookups were anticipated by the original DNS >design but dropped (and replaced by, e.g., a separate reverse >mapping tree for addresses) when they turned out to be >incompatible with other aspects of that design. If you consider strings we are back to the preceding problem: strings are chains of characters. The difficulty is with the man/machine possible disagreement over characters identification. >(ii) For maximum interoperability with the rest of the Internet, >look up C normally in the DNS, CLASS-IN, yielding addresses of >other records important to you. At this time CLASS-IN would be establishing too much habits. This is testing, and ICP-3 is reasonably clear and prudent. >(iii) When and as needed, go back to your database to map C to A >(A' if you like but, if there is only one table and it is used >for both forward and reverse mappings, the identity relationship >is guaranteed). This is precisely what we do not want. This means that I would need ***three*** separate non-ASCII DNS systems to be maintained in parallel! >Interestingly, in the model above, there is no need for C to be >in the encoding produced by the Punycode algorithm, to use the >IDNA "xn--" prefix, or to obey any conventions other than you >own. You would actually gain some simplicity and resistance >against attacks and the sort of possibly-incorrect matching >issues that have been the topic of this thread (and many others >over the years) by making C a pseudo-random, all-ASCII, value >rather than relying on a trick encoding. The only requirement >on C is that it be unique, and there are lots of ways to >accomplish that. Correct. But this is not human oriented anymore. So why not just to use an IPv6 address? >Also see your Case (2) below. > > > For your information. > > > > As part of the ICP-3 conformant IUser community testing for the > > Catenet we want to experiment the following > > multi-ledger/multi-echnology >\X >@L-DNS):: > > > > 1. for the CLASS "IN" ledger of registries of > > ICANN/NTIA/Verisign: >FR7FW7FW2&0k and forth conversion algorithm is: > > - either " A=B/B=A when A and B are restricted to the > > ASCII list". > > - or punycode otherwise. > >See above. If A and B are both ASCII, those relationships are >guaranteed by the basic DNS design modulo case-independent >matching and non-preservation of case in a variety of contexts >where compression is involved. Yes. But remember I want to protect majuscules/other metafancies so I must differentiate them (usual way is upper cases, but orthotypography has others). >If you need case preservation in >the ASCII range, you either cannot use the DNS or have to use a >trick encoding for everything, including all-ASCII labels. Right. Actually I must consider ASCII as possible IDNs (as in Elyse.fr) >Whatever that encoding might be, the Punycode algorithm, which >makes some special assumptions about all-ASCII labels, won't be >appropriate. No. See above. For example I can decide that ^e = E, so Elysee.fr is ^elysee.fr. >܈H]]HLASS "FL" (Free/Libre) ledger of > > registries by DNSLIB: > > > > the step 1/step 3 back and forth conversion algorithm is: >HZ]\OPЏPH[H[\H\tricted to the >TRH\݋"V6FRied to the UNISIGN semiotic > > (Free/Libre) sign set. > - or no registration permitted/filtering out otherwise. > >First, note that the Punycode algorithm was designed >specifically for the Unicode repertoire and block-layout system. >It is an optimization for that system that, in particular, has >better (shorter-string) properties than UTF-8 for strings of >Unicode code points with particular characteristics, notably >when there are short distances among the numerical values of the >code points in the label string and many or all of those code >points have sufficiently high numeric values to require >three-octet encodings. My priority is something that effectively works. If a solution works somewhere RFC 1958 advises to use it elsewere. The idea is to use xu-- domain names where punnycode handles pseudo-Unicode that are coded/uncoded at both fringes. > > UNISIGN only includes non-confusable character and non > > character > > signs. Confusable characters share a unique common sign-point. > >If you are going to use a repertoire and/or coding system >different from Unicode, then the Punycode algorithm is very >unlikely to make any sense. If you can use the DNS for your own >purposes and encoding, intend to use a separate CLASS, Yes. This is the premise. >and can >control the coding so that it meets your needs, then there are >probably no advantages of using anything other than your native >coding. No, because I do not plan replacing, but adding on top. This is a practical issue (at least as long as we are smaller than Google+USG :-)) Remember: we have a need and the need for the solution to be stable. This need is common with Banks, Police, Corporations, etc. We have no problem in transcoding further on to any "INTERNATIONALCODE". Our problem is simply that people do not discriminate at the machine level as Unicode supports it. Unicode is too good for us. >Remember that the DNS is perfectly happy with labels >consisting of octets with arbitrary values and compares them >perfectly and consistently. The difficulties that led to IDNA >arise from three things: >(a) What now seems like a peculiarity >that octets whose values are consistent with letters in the >ASCII range are compared case-independently but nothing else is Yes. We need to support that since you made IDNA reduce upper-cases to lower-cases during the IDNA DNS process. >(b) Within CLASS=IN, ASCII is basically assumed for octets in >the range 0x00 to 0x7F; for octets outside that range, the >character repertoire and encoding are unspecified and those >octets are not assumed to be character data at all. For other >CLASSes, you could easily specify a CLASS-wide character set and >encoding and design that encoding to not trigger any DNS >idiosyncrasies. This is the very basis of the "FL" CLASS. Again, this is ICP-3 recommendation. I do not want to innovate and take risks. Just to get out of the 1986 status-quo, fully respecting the stabilized RFC (including the now completed RFC 6852). This is the new "permissionless innovation" motto. >(c) Many applications limit their identifiers and associated DNS >labels to ASCII-only. IDNA was designed to avoid having to >upgrade all of those applications as a condition for deploying >IDNs. Because introducing a new coding system or lookups in a >different database or different DNS CLASS requires upgrading all >relevant applications anyway, you don't have that constraint. No. It only requires people like Firefox to accept that the users are grown enough and can decide to send to the DNS resolver what they actually entered, and the DNS resolution to be handled at the "IUI" or "MYCANN Plug-in" level, where entries are read and massaged appropriately (this is RFC 5895). > > The UNISIGN table results from a non-confusability algorithm > > under > > financing/work, It should be based upon rastering comparison > > in an UNISIGN fount of reference. > >Good luck with that and do let us know, ideally in the >peer-reviewed literature, how it works out. It may work if you >can select (and perhaps design) a single type family and >eliminate all others from your enviornment, ideally eliminating >all stylistic variations (like italics or bold for many >Latin-based type families) within that family as well. I do not need that. The fount is virtual (i.e. only in establishing the graphic average confusability. Depending on the environments it can be Arial, use, or the law). Please remember it is just deciding that roman o and cyrillic o are a graphic o and giving the receiving end the semiotics metadata to use it (language, script, orthotypography). Why do you think I made sure langtags would not be confusable? >That >would leave you in a situation in which characters that were >confusing in your reference font might not be in more normal >ones and vice versa. It would, of course, work even better if >you restrict the scripts of interest. Otherwise, for example, >the visual (and likely raster and even vector) similarity >between U+03BB and U+5165, a resemblance that I think we can be >quite confident is entirely coincidental and one where even a >few characters of context would likely be adequate to make a >distinction, would result in a single code point in your system. Yes. No phishing. >I think I've mentioned this to you before, but anyone >contemplating automatic confusability detection based on raster >or vector properties of printed/written characters should >examine the pre-Kurzweil (mid-to-late 1960s) literature in >optical character recognition as a starting point in >understanding how difficult it is to get from abstractions of >characters to character identification. There is not automatic confusability detection. There is only a table based transcoding algorithm, between UNICODE and UNIGRAPH in the UNISIGN framework (there are not only character signs). It can be established manually, but it will probably be easier/cheaper and more operationally oriented to prepare it with published/legal existing rasters with the advantage to produce raster printing as well for easy international identifications (ex. Customs, forms, signings, etc.). The point is not to know what Chinese use to confuse but what people from anywhere may confuse in Chinese. What pre/post=Kurzwell may have writen on raster confusability is certainly be of interest. We will leave that to experts. Our need is just to start a Libre momentum and protect the UNISIGN and UNIGRAPH terms so all this does not land into a closed commercial consortium but in a DECLIC approach (development for Catenet Libre, Institutional and Commercial use or whatever better English wording you can find for the French "DEstin au Catenet/Libre Institutionnel Commercial" (DECLIC) license we work on. jfc