From jefsey@jefsey.com Fri Mar 2 05:13:11 2012 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 AA65D21F8B0C for ; Fri, 2 Mar 2012 05:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.512 X-Spam-Level: X-Spam-Status: No, score=-100.512 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_50=0.001, 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 QI8hK-7RBB1y for ; Fri, 2 Mar 2012 05:13:11 -0800 (PST) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0E54921F8B0A for ; Fri, 2 Mar 2012 05:13:11 -0800 (PST) Received: from 122.133-227-89.dsl.completel.net ([89.227.133.122]:57029 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S3SIH-00082k-6M; Fri, 02 Mar 2012 05:13:09 -0800 Message-Id: <7.0.1.0.2.20120302135849.0582e1a0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 02 Mar 2012 14:14:59 +0100 To: "iucg@ietf.org" ,Kim Davies From: JFC Morfin In-Reply-To: <0B41E11A-8F03-4491-84F6-B1E84383038D@icann.org> References: <0B41E11A-8F03-4491-84F6-B1E84383038D@icann.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: "vip@icann.org" , Kim Davies Subject: [iucg] [vip] Draft on IDN Tables in XML 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, 02 Mar 2012 13:13:11 -0000 http://iucg.org/wiki/IUWW_Draft-Davis-IDNTables There is a proposition of Draft by Kim Davies (ICANN) for IDN Tables in XML format. The discussion is reproduced on the talk page. This work seems interesting and could be used as a root model to extend for "rootlocale" files in the MDRS documenting the relational space of an Internet TLD. There is however two missing metadata: - the encoding scheme (unless we accept Unicode as a default value) - the CLASS (unless we accept the ICANN/NTIA CLASS "IN" as a defaulf value) jfc From naela.sarras@icann.org Wed Feb 22 17:49:43 2012 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 9BF6011E8073 for ; Wed, 22 Feb 2012 17:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 YIdNq3Z6CyRN for ; Wed, 22 Feb 2012 17:49:42 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 626F711E8072 for ; Wed, 22 Feb 2012 17:49:42 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 22 Feb 2012 17:49:41 -0800 From: Naela Sarras To: "J-F C. Morfin" , "vip@icann.org" Date: Wed, 22 Feb 2012 17:49:33 -0800 Thread-Topic: [vip] Final Integrated Issues Report and Project Plan for Next Steps Now Posted Thread-Index: AczxzWjcu15mY8lbSOyT4VmpwCZOdg== Message-ID: In-Reply-To: <7.0.1.0.2.20120222175827.0622bb70@jefsey.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB6ADACB2A06Cnaelasarrasicannorg_" MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 03 Mar 2012 14:51:47 -0800 Cc: "idna-update@alvestrand.no work" , "iucg@ietf.org" Subject: Re: [iucg] [vip] Final Integrated Issues Report and Project Plan for Next Steps Now Posted 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: Thu, 23 Feb 2012 01:49:43 -0000 --_000_CB6ADACB2A06Cnaelasarrasicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear JFC, The proposed project plan is the document currently open for public comment= . You can review the proposed plan and submit any comments via the link pro= vided: http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb1= 2-en.htm Best regards, Naela Sarras ICANN From: "J-F C. Morfin" > Date: Wed, 22 Feb 2012 09:18:52 -0800 To: Naela Sarras >, "= vip@icann.org" > Cc: "idna-update@alvestrand.no work" >, "iucg@ietf.org" > Subject: Re: [vip] Final Integrated Issues Report and Project Plan for Next= Steps Now Posted At 22:55 21/02/2012, Naela Sarras wrote: Dear Colleagues, The final Integrated Issues Report has been posted. In addition, the draft= VIP Project Plan for the next steps has been posted for public comment. http://www.icann.org/en/announcements/announcement-20feb12-en.htm http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb1= 2-en.htm Both documents will be discussed at the IDN Variant Issues Project Session = during the ICANN Costa Rica Meeting, 11-16 March 2012. Best regards, Naela Sarras ICANN Dear Naella, is this list still active for disscussion over the Very Impossible Project = (VIP) issue? If yes, what I hope, are new venues allowed in the debate (like Internet ex= tended architectural frameworks able to support variants off the shelves)? Thank you jfc --_000_CB6ADACB2A06Cnaelasarrasicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear JFC,

The proposed project plan is the document = currently open for public comment. You can review the proposed plan and sub= mit any comments via the link provided:
<= div>
Naela Sarras
ICANN

From: "J-F C. Morfin" <jfc@morfin.org>
Date: Wed, 22 Feb 2012 09:18:52 -0800
To: Naela Sarras <naela.sarras@icann.org>, "vip@icann.org" <vip@icann.org= >
Cc: "idna-update@alvestrand.no work" <idna-update@alvestrand.no>, "iucg@ietf.org" <iucg@ietf.org>
Subject:= Re: [vip] Final Integrated Issues Report and Project Plan for Nex= t Steps Now Posted

At 22:55 21/02/2012, Naela Sarras wrote:
Dear Colleagues,

The final Integrated Issues Report has been posted.  In addition, the draft VIP Project Plan for the next steps has been posted for public comment.

http://www.icann.org/en/announcements/announcement-20feb12-en.htm
http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb1= 2-en.htm

Both documents will be discussed= at the IDN Variant Issues Project Session during the ICANN Costa Rica Meeting, 11-16 March 2012.

Best regards,

Naela Sarras
ICANN

Dear Naella,

is this list still active for disscussion over the Very Impossible Project (VIP) issue?
If yes, what I hope, are new venues allowed in the debate (like Internet extended architectural frameworks able to support variants off the shelves)?

Thank you
jfc
 --_000_CB6ADACB2A06Cnaelasarrasicannorg_-- From jefsey@jefsey.com Mon Mar 5 18:49:11 2012 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 7C76F21F8504 for ; Mon, 5 Mar 2012 18:49:11 -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 E9 hex): Cc: ...e.info>,iutf@iutf.org,\n G\351rard Lang-Marco[...] X-Spam-Flag: NO X-Spam-Score: -102.021 X-Spam-Level: X-Spam-Status: No, score=-102.021 tagged_above=-999 required=5 tests=[AWL=1.089, BAYES_05=-1.11, GB_I_LETTER=-2, 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 t9ysvITG6GSz for ; Mon, 5 Mar 2012 18:49:10 -0800 (PST) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9D98121F8501 for ; Mon, 5 Mar 2012 18:49:10 -0800 (PST) Received: from 181.219-227-89.dsl.completel.net ([89.227.219.181]:57051 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S4kSQ-00008X-9v; Mon, 05 Mar 2012 18:48:58 -0800 Message-Id: <7.0.1.0.2.20120306030522.0b270998@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 06 Mar 2012 03:52:03 +0100 To: "Dillon, Chris" , Dmitry Belyavsky From: JFC Morfin In-Reply-To: References: <0B41E11A-8F03-4491-84F6-B1E84383038D@icann.org> <7.0.1.0.2.20120302135849.0582e1a0@jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: Gérard Lang-Marconnet , iutf@iutf.org, "iucg@ietf.org" , "ca@linguasphere.info" Subject: Re: [iucg] [vip] Draft on IDN Tables in XML 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, 06 Mar 2012 02:49:11 -0000 At 13:22 05/03/2012, Dillon, Chris wrote: >Dear colleagues, > >I have been reading this correspondence with Chinese in mind and >would like to raise some questions. > >This is a case where there are two major forms of a script >(Simplified Chinese used, for example in mainland China and >Singapore) and Traditional Chinese, used elsewhere. Many characters >are the same everywhere but a subset of characters have been >abbreviated in the case of Simplified Chinese. > >There is an additional complication in the form of a small number of >characters that are only used e.g. in Hong Kong (for Cantonese) or >Singapore. What would be the best way to include those? > >In the RFC3743-style tables at >http://www.iana.org/domains/idn-tables/ typically Simplified Chinese >Preferred Variants and Traditional Chinese Preferred Variants have >their own columns. > >http://tools.ietf.org/html/rfc5646 gives the following example tags >for Chinese; which should be standard for Chinese in this XML-based system? At 20:29 05/03/2012, Dmitry Belyavsky wrote: >Greetings! > >What about "one-direction" variants? For example, Russian letter £ >can be replaced with Å and often is, but the letter Å can not be >replaced with £. > >Thank you! Chris and Dmitry, I answer this privately not to raise unnecessary controversy. It is natural that ICANN works for their own business community and they make it plain when asked. As lead Internet Users (http://iutf.org and our liaison to the IETF http://iucg.org/wiki), we have the same and more needs: 1. a visual confusion algorithm against homography based on bitmaps (anti-phishing) 2. complete variant coverage, i.e. visual, combinational (several code points), orthotypographic (syntaxic [one way/two ways] correspondence and majuscules in a considered *language*), and cultural (semantic synonymies) 3. for every CLASS. There are 65,536 classes http://www.iana.org/assignments/dns-parameters; ICANN is only concerned with CLASS 1 "IN". 4. for the entire WDNS (the "whole digital name system" of the whole digital ecosystem (WDE), further and beyond the sole Internet). We, therefore, need two tables: - UNIGRAPH, which is the table that you refer to, in a graphic bitmap format that permits computational comparisons. - UNISIGN, which is a table that will document all the signs being used in the WDNS syntax. 1. We have parts of these tables, 2. However, we were unable to find a single complete Unicode table, including every code point and its description. 2. There exist different bitmap tables. Do we understand correctly that there is a Chinese official publication that documents the Han and Han bitmap sets? Our target is to publish the table that you are looking for, with bitmaps, degree of confusability, ISO 3166 related specifics, ISO 639/Linguasphere cross relations, IDNA2008 level, and ISO 10646 definitions. And then to work on a multi-degree of confusability algorithm. However, this part is of a complete review of the Internet Use architecture that calls for new collaborative working structures. I am documenting: - that cooperation: http://www.ietf.org/internet-drafts/draft-iucg-iutf-tasks-01.txt - the architectural framework : http://www.ietf.org/internet-drafts/draft-iucg-internet-plus-09.txt - and preparing the reset of our working alliance with MAAYA and Linguasphere on the matter. In this process, we will reactivate the UNIGRAPH and UNISIGN sites as FLOSS MDRS (WDE's continuation of the IANA). Let us know if you are interested, and we will keep you posted. Best jfc From jefsey@jefsey.com Tue Mar 6 11:16:48 2012 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 0984721E8096 for ; Tue, 6 Mar 2012 11:16:48 -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 E9 hex): Cc: ....org" ,\n G\351rard Lang-Marco[...] X-Spam-Flag: NO X-Spam-Score: -101.556 X-Spam-Level: X-Spam-Status: No, score=-101.556 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 ylVjS034amlh for ; Tue, 6 Mar 2012 11:16:44 -0800 (PST) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5352A21E808F for ; Tue, 6 Mar 2012 11:16:44 -0800 (PST) Received: from 181.219-227-89.dsl.completel.net ([89.227.219.181]:52809 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S4zsA-0004yL-6X; Tue, 06 Mar 2012 11:16:35 -0800 Message-Id: <7.0.1.0.2.20120306184248.0b271000@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 06 Mar 2012 20:19:40 +0100 To: "Dillon, Chris" , Dmitry Belyavsky From: JFC Morfin In-Reply-To: References: <0B41E11A-8F03-4491-84F6-B1E84383038D@icann.org> <7.0.1.0.2.20120302135849.0582e1a0@jefsey.com> <7.0.1.0.2.20120306030522.0b270998@jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: Gérard Lang-Marconnet , "iutf@iutf.org" , "iucg@ietf.org" , "ca@linguasphere.info" Subject: Re: [iucg] [vip] Draft on IDN Tables in XML 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, 06 Mar 2012 19:16:48 -0000 Chris, thank you for your response. Comments embedded in the text. At 12:12 06/03/2012, Dillon, Chris wrote: >However, I would like to pick up a couple of points at this stage. >1. I feel that the visual confusion algorithm will need to go beyond >bitmaps. For example, in Chinese and especially in Arabic, there are >characters which differ by only one dot but are regarded as being >without visual confusion by the communities. The ideal algorithm >would be programmable to take into account this sort of thing that >would be missed by an entirely bitmap-based approach. Actually, I am afraid there is no other basis than bitmaps. This is to do with the way the "HSS/NSP" (Homo Sapiens Sapiens/Natural Semantic Processor) works internally. The reason why is that for every other sense than vision, the brain takes time elements into account when it evaluates things, except in vision where it may not. This means that pattern (like in a flash) recognition is to be used, not sequence recognition (several chained patterns in sequence, vectors, history of the writing movement, etc.). At the same time, this should not be a blocking problem. Because when Chinese and Arabs differentiate characters, their brains just do that. We are not at this stage yet, but I suppose that homographic confusion is related to fuzziness, and fuzziness may blur details to the point that a small point would disappear. One may imagine multiple programmatic responses: 1. there is a matter of density of the bitmap. How many bits in a dot, how many bits is the fuzziness threshold. 2. there is a matter of fount. The purpose is not for the bitmap to be beautiful, but to be not confusable, and sortable by the algorithm: the dot in the bitmap must be thick (width in bits) enough. 3. there is a matter of algorithmic conception: for example taking into account shape recognition to be more precise in cases one knows a confusion might result from the algorithm itself. 4. there is a matter of scientific approach in terms of pattern recognition, i.e. proceeding mathematically, informatically, or like a human brain (which only uses a very tiny part of the data it gets, but has learned to use it well: it does this not to be confused by the "noise", i.e. what we want ourselves, so there must be some common interest strategies to tackle the issue). There MUST absolutely be no false homographic confusion. This algorithm should be used to register CLASS 0 digital names, to make sure that in any other CLASS there is no confusing labels. It is likely that if this target is accepted by TLD registries the algorithm will be used for passports, banking purposes, secure access, etc. and become an ISO standard. So, many people will most probably work on it. My personal target is just to bootstrap the concept, create a fuss over it between ICANN and Google+ as part of the Internet+ stratum architecture - for it to be noticed, and properly worked on by Governments and International Organizations as part of the resolution of all the changes the identification of the Internet+ architectural framework introduces in the whole digital ecosystem use (I did not invent it, I just try to document it, the way it already is in the Internet architecture, before it results in a real mess). However, I fully agree with you: I do not think this will be achieved in one day, but one has to start. This means trying, testing different ways to check false confusions. Gain experience. Today the only standard we have is ISO 10646, that is influenced by Unicode. It is great for typographer (i.e. people interested in the printer's side) not for orthotypographer (i.e. people considering the reader's side). We do not want to change it: we want to use it better. >2. Semantic synonymies. I am familiar with what the VIP Greek Case >Study wrote in this area, but would be interested in finding out >more about the case for semantic synonymies. Incidentally, there is >also a paper by Jack Halpern which mentions possible Chinese cases >(The pitfalls of Chinese to Chinese conversion). Do you have an URL? I found: http://www.cjk.org/cjk/joa/synclir.htm. 1) I add another kind of synonymy as being "polynymy", i.e. cross-language strict pragmatic synonymy. 2) As a remark, I am personally interested in the networked computer assisted facilitation pragmatic aspects, and how to support specific needs by subsidiarity. This means that I am eager of the details, not to address them directly, but to make sure that the final general concepts of the architecture will permit to address them seamlessly at their proper place, when they are needed, without breaking the holistic equilibrium (Universe harmony). The "Mecalanguage, Telecoms, Internet, Internet+, Intersem" architectural sequence MUST be elegant if to be efficient. This IETF "MUST" results from the few existing (but truly inspired) architectural RFCs. They have defined this elegance so far as multilayered (RFC 1121), plug to plug robust (RFC 761), end to end adaptative (RFC 1958), over all simple (RFC 3439) and fringe to fringe subsidiary (IDNA2008). The two most challenging ones are the mecalanguage (how to produce an utterance) and the Intersem (how to obtain intercomprehension) strata. This is mostly terra incognita. At this stage we are actually discussing the Internet+ stratum, (how to make the content of that utterance interintelligible). What ITU and IETF have covered is "how to reliably transport the utterance" (Internet datagram) and "how to efficiently transmit the bytes of these datagrams". And ICANN has introduced an unstable way of making money with it :-) >3. One of the members of the Chinese Case Study, Professor Joe Zhang >of Unihan Digital Technology Co. presented me with a copy of >"Zhongrihan changyong hanzi duibi fenxi" ISBN 978-7-100-06595-5 >which is a comparative list of characters used in Chinese, Japanese >and Korean. He was the chief editor. It includes Unicode code >points, but not bitmaps. I shall e-mail him and ask him if he knows >whether a list with bitmaps exists. Thank you. Best jfc >Regards, > >Chris. >== >Research Associate in Linguistic Computing, Dept of Information >Studies, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int >31599) ucl.ac.uk/dis/people/chrisdillon > >Chris and Dmitry, > >I answer this privately not to raise unnecessary controversy. It is >natural that ICANN works for their own business community and they >make it plain when asked. As lead Internet Users (http://iutf.org >and our liaison to the IETF http://iucg.org/wiki), we have the same >and more needs: > >1. a visual confusion algorithm against homography based on bitmaps >(anti-phishing) >2. complete variant coverage, i.e. visual, combinational (several >code points), orthotypographic (syntaxic [one way/two ways] >correspondence and majuscules in a considered *language*), and >cultural (semantic synonymies) 3. for every CLASS. There are 65,536 >classes >http://www.iana.org/assignments/dns-parameters; >ICANN is only concerned with CLASS 1 "IN". >4. for the entire WDNS (the "whole digital name system" of the whole >digital ecosystem (WDE), further and beyond the sole Internet). > >We, therefore, need two tables: > >- UNIGRAPH, which is the table that you refer to, in a graphic >bitmap format that permits computational comparisons. >- UNISIGN, which is a table that will document all the signs being >used in the WDNS syntax. > >1. We have parts of these tables, >2. However, we were unable to find a single complete Unicode table, >including every code point and its description. >2. There exist different bitmap tables. Do we understand correctly >that there is a Chinese official publication that documents the Han >and Han bitmap sets? > >Our target is to publish the table that you are looking for, with >bitmaps, degree of confusability, ISO 3166 related specifics, ISO >639/Linguasphere cross relations, IDNA2008 level, and ISO 10646 >definitions. And then to work on a multi-degree of confusability algorithm. > >However, this part is of a complete review of the Internet Use >architecture that calls for new collaborative working structures. I >am documenting: > >- that >cooperation: >http://www.ietf.org/internet-drafts/draft-iucg-iutf-tasks-01.txt >- the architectural framework : >http://www.ietf.org/internet-drafts/draft-iucg-internet-plus-09.txt >- and preparing the reset of our working alliance with MAAYA and >Linguasphere on the matter. > >In this process, we will reactivate the UNIGRAPH and UNISIGN sites >as FLOSS MDRS (WDE's continuation of the IANA). > >Let us know if you are interested, and we will keep you posted. >Best >jfc From jfc@morfin.org Wed Mar 7 05:38:50 2012 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 EC09821F860E for ; Wed, 7 Mar 2012 05:38:50 -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 ; Wed, 7 Mar 2012 05:38:48 -0800 (PST) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id CE2A121F8792 for ; Wed, 7 Mar 2012 05:38:48 -0800 (PST) Received: from 79.50-227-89.dsl.completel.net ([89.227.50.79]:50939 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S5H4X-0002Hd-Ft; Wed, 07 Mar 2012 05:38:30 -0800 Message-Id: <7.0.1.0.2.20120307140750.060a8e48@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 07 Mar 2012 14:21:17 +0100 To: Patrik Fältström ,JFC Morfin From: "J-F C. Morfin" In-Reply-To: References: <6A6EDDA2-280D-40ED-9FBF-683780D457A8@icann.org> <7.0.1.0.2.20120307023132.0d6298c8@jefsey.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: "vip@icann.org" , "Dillon, Chris" , "idna-update@alvestrand.no" , "iucg@ietf.org" , Kim Davies Subject: Re: [iucg] [vip] Draft on IDN Tables in XML 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, 07 Mar 2012 13:38:51 -0000 Kim, Patrick, this is what I wanted to underline: a graphical standard cannot be dependent on the external dispaly tool. ISO standards are depending on your wallet size. IETF standards want to be independent from the printer harware. Nothing in protocols forces me to use an UTF-8 keyboard or printer (as long as punycode is supported somewhere down the line, in the IDNA case). What is looked for is a fool printer proof solution. To my knowledge only raster bitmaps can provide this to the printer and to the brain ? Hence the need of a complete Unicode raster table. Best jfc At 08:10 07/03/2012, Patrik Fältström wrote: >On 7 mar 2012, at 02:32, JFC Morfin wrote: > > > At 01:56 07/03/2012, Kim Davies wrote: > >> Ä™ [U+0101] LATIN SMALL LETTER A WITH MACRON > >> Ä" [U+0113] LATIN SMALL LETTER E WITH MACRON > >> Ä« [U+012B] LATIN SMALL LETTER I WITH MACRON > >> ÅŸ [U+014D] LATIN SMALL LETTER O WITH MACRON > >> Å« [U+016B] LATIN SMALL LETTER U WITH MACRON > >> > >> kim > > > > Seems there is a problem with the display. > >Yes, problem with the display, but it was a correctly encoded email message: > >Content-Type: text/plain; charset="utf-8" >Content-Transfer-Encoding: base64 > > Patrik > >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From paf@frobbit.se Wed Mar 7 06:19:17 2012 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 D148C21F880D for ; Wed, 7 Mar 2012 06:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 PZhdX6kGla5D for ; Wed, 7 Mar 2012 06:19:17 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2621F880B for ; Wed, 7 Mar 2012 06:19:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 24CCE133FFFE3; Wed, 7 Mar 2012 15:19:15 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJNS1wET53a5; Wed, 7 Mar 2012 15:19:15 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id ED5A8133FFFDC; Wed, 7 Mar 2012 15:19:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <7.0.1.0.2.20120307140750.060a8e48@morfin.org> Date: Wed, 7 Mar 2012 15:19:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3551AE01-6D85-468D-A614-510A9E91AFC4@frobbit.se> References: <6A6EDDA2-280D-40ED-9FBF-683780D457A8@icann.org> <7.0.1.0.2.20120307023132.0d6298c8@jefsey.com> <7.0.1.0.2.20120307140750.060a8e48@morfin.org> To: J-F C. Morfin X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Wed, 07 Mar 2012 07:55:01 -0800 Cc: Kim Davies , "Dillon, Chris" , "idna-update@alvestrand.no" , "iucg@ietf.org" , "vip@icann.org" Subject: Re: [iucg] [vip] Draft on IDN Tables in XML 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, 07 Mar 2012 14:19:17 -0000 On 7 mar 2012, at 14:21, J-F C. Morfin wrote: > Nothing in protocols forces me to use an UTF-8 keyboard or printer (as = long as punycode is supported somewhere down the line, in the IDNA = case). As the email from Kim was explicitly tagged with information that it was = in charset UTF-8 it is possible for you, and up to you and your tools to = do the best of the situation. Patrik From jefsey@jefsey.com Wed Mar 7 08:24:25 2012 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 72C0521F860D for ; Wed, 7 Mar 2012 08:24:25 -0800 (PST) X-Quarantine-ID: <5TXa1J1wTzcD> 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 ; Wed, 7 Mar 2012 08:24:25 -0800 (PST) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 09FF321F84A1 for ; Wed, 7 Mar 2012 08:24:25 -0800 (PST) Received: from 79.50-227-89.dsl.completel.net ([89.227.50.79]:52125 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S5Jeo-0004tZ-5V; Wed, 07 Mar 2012 08:24:06 -0800 Message-Id: <7.0.1.0.2.20120307163303.060a9220@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 07 Mar 2012 17:27:22 +0100 To: Patrik Fältström ,J-F C. Morfin From: JFC Morfin In-Reply-To: <3551AE01-6D85-468D-A614-510A9E91AFC4@frobbit.se> References: <6A6EDDA2-280D-40ED-9FBF-683780D457A8@icann.org> <7.0.1.0.2.20120307023132.0d6298c8@jefsey.com> <7.0.1.0.2.20120307140750.060a8e48@morfin.org> <3551AE01-6D85-468D-A614-510A9E91AFC4@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: iutf@iutf.org, Kim Davies , "Dillon, Chris" , "idna-update@alvestrand.no" , "iucg@ietf.org" , "vip@icann.org" Subject: Re: [iucg] [vip] Draft on IDN Tables in XML 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, 07 Mar 2012 16:24:25 -0000 At 15:19 07/03/2012, Patrik Fältström wrote: >On 7 mar 2012, at 14:21, J-F C. Morfin wrote: > > Nothing in protocols forces me to use an UTF-8 keyboard or > printer (as long as punycode is supported somewhere down the line, > in the IDNA case). >As the email from Kim was explicitly tagged with information that it >was in charset UTF-8 it is possible for you, and up to you and your >tools to do the best of the situation. I might, but this would have three errors from Kim which are most common among us, but which affect users: 1. Architectural layer violation: to call for the implication of my "tool", i.e. application. Same error as the IDNA architecture itself which involves non-network (non end to end) applications. 2. Logical: Chris asks for a Unicode graphical table. Kim responds: you do not need one *if* you have one. 3. basic: if Kim answers us it is for his response to go through, not to force us to use/buy his tools. I only shown the response did not go through. Now if I tag this mail as "fr-latn-fr" ce sera à toi de ton côté de te débrouiller pour tirer le meilleur parti de la situation. All this is not to make a point, but to illustrate the problem we have at hand. What I actually received were variants. Billions of people at one time or another may receive variants. Actually an A-label is a variant of its U-label. And each application can use its own character set. So, either UTF-8 becomes the sole standard charset of the Internet or we need to find a solution that does not implies a layer violation. It can be architectural (network end to end) or procedural (network use fringe to fringe) but it MUST be 100% secure and 100% independent from the applications core because we know that this is a security breach: there is no application to application or computer core to core protocol. Yet, with variants we must support psy to psy human protocols named natural languages which come with their own orthotypography. I know I am boring, but I am sorry, we work for Homo Sapiens Sapiens people, not for Homo Abilis ones. jfc From ajs@anvilwalrusden.com Wed Mar 7 08:39:35 2012 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 AA93321E80A2 for ; Wed, 7 Mar 2012 08:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 Czqe+TdjyZhi for ; Wed, 7 Mar 2012 08:39:35 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 27C6E21E80A0 for ; Wed, 7 Mar 2012 08:39:35 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 455111ECB41D; Wed, 7 Mar 2012 16:39:34 +0000 (UTC) Date: Wed, 7 Mar 2012 11:39:32 -0500 From: Andrew Sullivan To: JFC Morfin Message-ID: <20120307163932.GJ79276@mail.yitter.info> References: <0B41E11A-8F03-4491-84F6-B1E84383038D@icann.org> <7.0.1.0.2.20120302135849.0582e1a0@jefsey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20120302135849.0582e1a0@jefsey.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "vip@icann.org" , "iucg@ietf.org" , Kim Davies Subject: Re: [iucg] [vip] Draft on IDN Tables in XML 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, 07 Mar 2012 16:39:35 -0000 On Fri, Mar 02, 2012 at 02:14:59PM +0100, JFC Morfin wrote: > - the encoding scheme (unless we accept Unicode as a default value) You had another alternative? IDNA uses Unicode. Adding an alternative encoding is just begging for trouble. > - the CLASS (unless we accept the ICANN/NTIA CLASS "IN" as a defaulf value) Why does this need to be classed? I can see a reason to add it: maybe a future CLASS would not need any ACE. But thought experiments, proposals, and experience with other protocols so far suggest that it would be easier to create DNSng than it would be to add a new widely-supported CLASS to the DNS. We can't even get new RRTYPEs widely supported in the DNS. A -- Andrew Sullivan ajs@anvilwalrusden.com From paf@frobbit.se Wed Mar 7 09:01:57 2012 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 DE82B21F8631 for ; Wed, 7 Mar 2012 09:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 9JM8DugwFmFg for ; Wed, 7 Mar 2012 09:01:57 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 2625721F861C for ; Wed, 7 Mar 2012 09:01:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 84F2213404AC9; Wed, 7 Mar 2012 18:01:55 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pdlW7+gxEcq; Wed, 7 Mar 2012 18:01:55 +0100 (CET) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 5CBC313404AC2; Wed, 7 Mar 2012 18:01:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120307163932.GJ79276@mail.yitter.info> Date: Wed, 7 Mar 2012 18:01:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56ADE58C-52F5-49CC-A7EE-0227A67A9971@frobbit.se> References: <0B41E11A-8F03-4491-84F6-B1E84383038D@icann.org> <7.0.1.0.2.20120302135849.0582e1a0@jefsey.com> <20120307163932.GJ79276@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: "vip@icann.org" , "iucg@ietf.org" Subject: Re: [iucg] [vip] Draft on IDN Tables in XML 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, 07 Mar 2012 17:01:58 -0000 On 7 mar 2012, at 17:39, Andrew Sullivan wrote: > On Fri, Mar 02, 2012 at 02:14:59PM +0100, JFC Morfin wrote: >> - the encoding scheme (unless we accept Unicode as a default value) >=20 > You had another alternative? IDNA uses Unicode. Adding an > alternative encoding is just begging for trouble. "utf-8" as mentioned in the email header is not the name of an encoding. = It is a charset as registered with IANA. Patrik From jfc@morfin.org Wed Mar 7 14:50:43 2012 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 5981B11E808F for ; Wed, 7 Mar 2012 14:50:43 -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.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_05=-1.11] 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 MX3erFbxTCoU for ; Wed, 7 Mar 2012 14:50:42 -0800 (PST) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id D969F11E8074 for ; Wed, 7 Mar 2012 14:50:42 -0800 (PST) Received: from 79.50-227-89.dsl.completel.net ([89.227.50.79]:49923 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S5Pgu-0007n9-Fe; Wed, 07 Mar 2012 14:50:41 -0800 Message-Id: <7.0.1.0.2.20120307235321.05cce2f8@morfin.org> Message-Id: <7.0.1.0.2.20120307142308.060a8f90@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 07 Mar 2012 23:54:09 +0100 To: "vip@icann.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: "iucg@ietf.org" , iutf@iutf.org Subject: Re: [iucg] Draft on IDN Tables in XML 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, 07 Mar 2012 22:50:43 -0000 At 08:23 07/03/2012, James Mitchell wrote: >Mixing these concepts is potentially dangerous as one registry may treat >variants as bundles and another as first-class domain names. I believe >there is great value in the IDN table describing what characters are >equivalent. This will allow consumers of the table, when given two names, >to determine whether or not they are actually part of the same bundle or >potentially separate names with potentially separate registrants. Anything >else that represents rulesets for valid names or activate-able variants >should be avoided. James, you are right. But this is the basic problem of using Unicode. Unicode documents character sets in typesetters (typography) and not visual character sets in human contexts (orthotypography). There are two solutions to this. 1) to get rid of Unicode. Unlikely. 2) to use an Man/Unicode conversion algorithm and to use the living Man (who in addition may evoluate) as a reference instead of the machine's history (which is also updated). IDN tables are a limited temporary patch to such an algorithm. We come back to the RFC 4647 issues ..."what is a language". As long as this XXe century cross-discipline question is not addressed we will never know for sure that a cyrilic o in an .au domain name and in an Australian gTLD are treated the same. jfc From jefsey@jefsey.com Thu Mar 8 04:42:29 2012 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 A4B7221F867D for ; Thu, 8 Mar 2012 04:42:29 -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 ; Thu, 8 Mar 2012 04:42:29 -0800 (PST) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3D25721F8664 for ; Thu, 8 Mar 2012 04:42:29 -0800 (PST) Received: from 79.50-227-89.dsl.completel.net ([89.227.50.79]:50914 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S5cfY-0001od-W0; Thu, 08 Mar 2012 04:42:09 -0800 Message-Id: <7.0.1.0.2.20120308012601.05cce440@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 08 Mar 2012 13:45:38 +0100 To: Patrik Fältström , Andrew Sullivan From: JFC Morfin In-Reply-To: <56ADE58C-52F5-49CC-A7EE-0227A67A9971@frobbit.se> References: <0B41E11A-8F03-4491-84F6-B1E84383038D@icann.org> <7.0.1.0.2.20120302135849.0582e1a0@jefsey.com> <20120307163932.GJ79276@mail.yitter.info> <56ADE58C-52F5-49CC-A7EE-0227A67A9971@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: "vip@icann.org" , "iucg@ietf.org" , iutf@iutf.org Subject: Re: [iucg] [vip] Draft on IDN Tables in XML 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: Thu, 08 Mar 2012 12:42:29 -0000 At 18:01 07/03/2012, Patrik Fältström wrote: >"utf-8" as mentioned in the email header is not the name of an >encoding. It is a charset as registered with IANA. This only means that a layer violation is registered with the IANA. OSI did worse things. Patrick, let be candid. The Internet did not support the presentation layer. The presentation layer is necessary to support linguistic issues. So, it was actually implemented by IDNA2008 through fringe to fringe (RFC 1958) subsidiarity, but this is still fuzzy and for information (RFC 5895), hence my appeals to get an IESG/IAB position. We got the response: interesting but not the IETF 's cup of tea. What I do agree because it concerns every digital technology, not only the sole Internet. This is why VIP, Precis, happiana, etc. have to try to find ways to deal with the Internet "half-presentation-layer" in many places. This is not easy if we do not acknowledge once for all that our pile of patches to circumvent the missing presentation layer is not correct Internet architecture. Now, one cannot change the Internet architecture, even to make it consistent, in one day. This is why my position is do our best with the old-patches while accepting they are patches, and build the correct framework aside. It will not replace, nor conflict with patches, only make them obsolete because it only be "the" Internet consistent architecture. IDNA2008 gave us the concept we can reproduce (once IAB has endorsed it, once experimentation has proven it [my bet]). This example is to forget about IDNinApplication and to go for an ML-DNS IDNApplication. This is Google+ on the bigdata host side. And Internet+ on our IUser sides. Best From c.dillon@ucl.ac.uk Thu Mar 8 04:30:34 2012 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 8425621F858D for ; Thu, 8 Mar 2012 04:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_21=0.6, 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 KpRBdfS9sjSq for ; Thu, 8 Mar 2012 04:30:32 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id A3EE221F8634 for ; Thu, 8 Mar 2012 04:30:31 -0800 (PST) Received: from mail67-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Mar 2012 12:30:30 +0000 Received: from mail67-am1 (localhost [127.0.0.1]) by mail67-am1-R.bigfish.com (Postfix) with ESMTP id 78E07220492; Thu, 8 Mar 2012 12:30:30 +0000 (UTC) X-SpamScore: -40 X-BigFish: PS-40(zzbb2dI13dbM542M1432N98dKzz1202hzz1033IL6d524h8275dhz2dh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.55.9.135; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0104HT030.eurprd01.prod.exchangelabs.com; RD:none; EFVD:NLI Received: from mail67-am1 (localhost.localdomain [127.0.0.1]) by mail67-am1 (MessageSwitch) id 1331209828403810_31294; Thu, 8 Mar 2012 12:30:28 +0000 (UTC) Received: from AM1EHSMHS019.bigfish.com (unknown [10.3.201.226]) by mail67-am1.bigfish.com (Postfix) with ESMTP id 5D77340068; Thu, 8 Mar 2012 12:30:28 +0000 (UTC) Received: from DB3PRD0104HT030.eurprd01.prod.exchangelabs.com (157.55.9.135) by AM1EHSMHS019.bigfish.com (10.3.206.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Mar 2012 12:30:26 +0000 Received: from DB3PRD0104MB139.eurprd01.prod.exchangelabs.com ([169.254.2.2]) by DB3PRD0104HT030.eurprd01.prod.exchangelabs.com ([10.4.156.63]) with mapi id 14.15.0045.000; Thu, 8 Mar 2012 12:30:26 +0000 From: "Dillon, Chris" To: JFC Morfin Thread-Topic: [vip] Draft on IDN Tables in XML Thread-Index: AQHM+0O8WirHIttVo0ylhixrt7mDfpZdFSmQgACPufSAArKtoA== Date: Thu, 8 Mar 2012 12:30:25 +0000 Message-ID: References: <0B41E11A-8F03-4491-84F6-B1E84383038D@icann.org> <7.0.1.0.2.20120302135849.0582e1a0@jefsey.com> <7.0.1.0.2.20120306030522.0b270998@jefsey.com> <7.0.1.0.2.20120306184248.0b271000@jefsey.com> In-Reply-To: <7.0.1.0.2.20120306184248.0b271000@jefsey.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.40.29.46] x-ucllive-sclrule: HASRUN Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ucl.ac.uk X-Mailman-Approved-At: Thu, 08 Mar 2012 08:26:14 -0800 Cc: G?rard Lang-Marconnet , "iutf@iutf.org" , "Zhang Joe \(joe.zhang@unihan.com.cn\)" , Dmitry Belyavsky , "ca@linguasphere.info" , "iucg@ietf.org" Subject: Re: [iucg] [vip] Draft on IDN Tables in XML 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: Thu, 08 Mar 2012 12:32:02 -0000 Dear JFC, Thank you for a thought-provoking e-mail. I think we are in fact saying a similar thing in different ways about bitma= ps. I regard bitmaps as being one possible starting point (input) but agree= with "This means that pattern (like in a flash) recognition is to be used, not s= equence recognition (several chained patterns in sequence, vectors, history= of the writing movement, etc.)." although pattern recognition could be partly based on several chained patte= rns in sequence. As you write further down: "3. there is a matter of algorithmic conception: for example taking into ac= count shape recognition to be more precise in cases one knows a confusion m= ight result from the algorithm itself." This is what I meant by the use of the word "programmable" in the context o= f an algorithm. And: "4. there is a matter of scientific approach in terms of pattern recognitio= n, i.e. proceeding mathematically, informatically, or like a human brain (w= hich only uses a very tiny part of the data it gets, but has learned to use= it well: it does this not to be confused by the "noise", i.e. what we want= ourselves, so there must be some common interest strategies to tackle the = issue)." The aim is certainly for an algorithm to act "like a human brain"; where th= e brain in question may be processing any language. Another aim is to minim= ise the gap between results an algorithm produces and the intuitions of nat= ive speakers. "fuzziness may blur details to the point that a small point would disappear= " This is especially a problem with complex Chinese characters at small font = sizes. "there is a matter of font. The purpose is not for the bitmap to be beautif= ul, but to be not confusable, and sortable by the algorithm: the dot in the= bitmap must be thick (width in bits) enough." A key area is the browser address bar. It is easy to find out about the enc= odings used for text in HTML documents. However, the fonts used in the addr= ess bar in different browsers on different platforms in different languages= present a major challenge. "It is likely that if this target is accepted by TLD registries the algorit= hm will be used for passports, banking purposes, secure access, etc. and be= come an ISO standard." I am not confident that there has not been progress in one of these sectors= . Moreover, it sounds that even if there has been progress, they may not be= too willing to share it. This is my way of asking the question "does anyon= e know more about this area?". Is it possible to borrow what has been done = elsewhere, quite possibly adding to it, or does it really need to be done f= rom scratch? It would be good to put resources discovered (sometimes with g= reat difficulty from numerous organisations) and/or created in an area wher= e it may be adopted for other uses. The Pitfalls and Complexities of Chinese to Chinese Conversion is indeed at= : http://www.cjk.org/cjk/c2c/c2cbasis.htm It includes words which are typically different when Simplified Chinese and= Traditional Chinese are used. Professor Joe Zhang e-mail'd that companies such as Apple and Microsoft use= d to use bitmap fonts but now generally use True Type. Kai-style bitmaps at= high resolution are available, but only individually, at www.unihan.com.cn= /CoolHanzi . I have copied him into this correspondence. I would be interested in being part of current or future DIGs in this area.= It involves a horribly complex matrix of criteria. Perhaps we can draw som= e comfort from machine translation which has made huge progress in a simila= rly inhospitable environment. Regards, Chris. =3D=3D Research Associate in Linguistic Computing, Dept of Information Studies, UC= L, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) ucl.ac.uk/dis= /people/chrisdillon -----Original Message----- From: JFC Morfin [mailto:jefsey@jefsey.com]=20 Sent: 06 March 2012 19:20 To: Dillon, Chris; Dmitry Belyavsky Cc: iucg@ietf.org; ca@linguasphere.info; iutf@iutf.org; G?rard Lang-Marconn= et Subject: RE: [vip] Draft on IDN Tables in XML Chris, thank you for your response. Comments embedded in the text. At 12:12 06/03/2012, Dillon, Chris wrote: >However, I would like to pick up a couple of points at this stage. >1. I feel that the visual confusion algorithm will need to go beyond=20 >bitmaps. For example, in Chinese and especially in Arabic, there are=20 >characters which differ by only one dot but are regarded as being=20 >without visual confusion by the communities. The ideal algorithm would=20 >be programmable to take into account this sort of thing that would be=20 >missed by an entirely bitmap-based approach. Actually, I am afraid there is no other basis than bitmaps. This is to do w= ith the way the "HSS/NSP" (Homo Sapiens Sapiens/Natural Semantic Processor)= works internally. The reason why is that for every other sense than vision= , the brain takes time elements into account when it evaluates things, exce= pt in vision where it may not.=20 This means that pattern (like in a flash) recognition is to be used, not se= quence recognition (several chained patterns in sequence, vectors, history = of the writing movement, etc.). At the same time, this should not be a blocking problem. Because when Chine= se and Arabs differentiate characters, their brains just do that. We are no= t at this stage yet, but I suppose that homographic confusion is related to= fuzziness, and fuzziness may blur details to the point that a small point = would disappear. One may imagine multiple programmatic responses: 1. there is a matter of density of the bitmap. How many bits in a dot, how = many bits is the fuzziness threshold. 2. there is a matter of fount. The purpose is not for the bitmap to be beau= tiful, but to be not confusable, and sortable by the algorithm: the dot in the bitmap must be thick (width in bits) enough. 3. there is a matter of algorithmic conception: for example taking into acc= ount shape recognition to be more precise in cases one knows a confusion mi= ght result from the algorithm itself. 4. there is a matter of scientific approach in terms of pattern recognition= , i.e. proceeding mathematically, informatically, or like a human brain (wh= ich only uses a very tiny part of the data it gets, but has learned to use = it well: it does this not to be confused by the "noise", i.e. what we want = ourselves, so there must be some common interest strategies to tackle the i= ssue). There MUST absolutely be no false homographic confusion. This algorithm sho= uld be used to register CLASS 0 digital names, to make sure that in any oth= er CLASS there is no confusing labels. It is likely that if this target is = accepted by TLD registries the algorithm will be used for passports, bankin= g purposes, secure access, etc. and become an ISO standard. So, many people= will most probably work on it. My personal target is just to bootstrap the= concept, create a fuss over it between ICANN and Google+ as part of the In= ternet+ stratum architecture - for it to be noticed, and properly worked on= by Governments and International Organizations as part of the resolution o= f all the changes the identification of the=20 Internet+ architectural framework introduces in the whole digital ecosystem use (I did not invent it, I just try to document it, the way it a= lready is in the Internet architecture, before it results in a real mess). However, I fully agree with you: I do not think this will be achieved in on= e day, but one has to start. This means trying, testing different ways to c= heck false confusions. Gain experience. Today the only standard we have is ISO 10646, that is influenced by Unicode= . It is great for typographer (i.e. people interested in the printer's side= ) not for orthotypographer (i.e. people considering the reader's side). We = do not want to change it: we want to use it better. >2. Semantic synonymies. I am familiar with what the VIP Greek Case=20 >Study wrote in this area, but would be interested in finding out more=20 >about the case for semantic synonymies. Incidentally, there is also a=20 >paper by Jack Halpern which mentions possible Chinese cases (The=20 >pitfalls of Chinese to Chinese conversion). Do you have an URL? I found: http://www.cjk.org/cjk/joa/synclir.htm. 1) I add another kind of synonymy as being "polynymy", i.e.=20 cross-language strict pragmatic synonymy. 2) As a remark, I am personally interested in the networked computer assist= ed facilitation pragmatic aspects, and how to support specific needs by sub= sidiarity. This means that I am eager of the details, not to address them d= irectly, but to make sure that the final general concepts of the architectu= re will permit to address them seamlessly at their proper place, when they = are needed, without breaking the holistic equilibrium (Universe harmony). The "Mecalanguage, Telecoms, Internet, Internet+, Intersem"=20 architectural sequence MUST be elegant if to be efficient. This IETF "MUST"= results from the few existing (but truly inspired) architectural RFCs. The= y have defined this elegance so far as multilayered (RFC 1121), plug to plu= g robust (RFC 761), end to end adaptative (RFC 1958), over all simple (RFC = 3439) and fringe to fringe subsidiary (IDNA2008). The two most challenging ones are the mecalanguage (how to produce an utterance) and the Intersem (how to obtain intercomprehension) strata. This= is mostly terra incognita. At this stage we are actually discussing the In= ternet+ stratum, (how to make the content of that utterance interintelligib= le). What ITU and IETF have covered is "how to reliably transport the utterance"= (Internet datagram) and "how to efficiently transmit the bytes of these da= tagrams". And ICANN has introduced an unstable way of making money with it = :-) >3. One of the members of the Chinese Case Study, Professor Joe Zhang of=20 >Unihan Digital Technology Co. presented me with a copy of "Zhongrihan=20 >changyong hanzi duibi fenxi" ISBN 978-7-100-06595-5 which is a=20 >comparative list of characters used in Chinese, Japanese and Korean. He=20 >was the chief editor. It includes Unicode code points, but not bitmaps.=20 >I shall e-mail him and ask him if he knows whether a list with bitmaps=20 >exists. Thank you. Best jfc >Regards, > >Chris. >=3D=3D >Research Associate in Linguistic Computing, Dept of Information=20 >Studies, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int >31599) ucl.ac.uk/dis/people/chrisdillon > >Chris and Dmitry, > >I answer this privately not to raise unnecessary controversy. It is=20 >natural that ICANN works for their own business community and they make=20 >it plain when asked. As lead Internet Users (http://iutf.org and our=20 >liaison to the IETF http://iucg.org/wiki), we have the same and more=20 >needs: > >1. a visual confusion algorithm against homography based on bitmaps >(anti-phishing) >2. complete variant coverage, i.e. visual, combinational (several code=20 >points), orthotypographic (syntaxic [one way/two ways] correspondence=20 >and majuscules in a considered *language*), and cultural (semantic=20 >synonymies) 3. for every CLASS. There are 65,536 classes=20 >http://www.iana.org/ass >ignments/dns-parameters; ICANN is only concerned with CLASS 1 "IN". >4. for the entire WDNS (the "whole digital name system" of the whole=20 >digital ecosystem (WDE), further and beyond the sole Internet). > >We, therefore, need two tables: > >- UNIGRAPH, which is the table that you refer to, in a graphic bitmap=20 >format that permits computational comparisons. >- UNISIGN, which is a table that will document all the signs being used=20 >in the WDNS syntax. > >1. We have parts of these tables, >2. However, we were unable to find a single complete Unicode table,=20 >including every code point and its description. >2. There exist different bitmap tables. Do we understand correctly that=20 >there is a Chinese official publication that documents the Han and Han=20 >bitmap sets? > >Our target is to publish the table that you are looking for, with=20 >bitmaps, degree of confusability, ISO 3166 related specifics, ISO=20 >639/Linguasphere cross relations, IDNA2008 level, and ISO 10646=20 >definitions. And then to work on a multi-degree of confusability algorithm= . > >However, this part is of a complete review of the Internet Use=20 >architecture that calls for new collaborative working structures. I am=20 >documenting: > >- that >cooperation: >http: >//www.ietf.org/internet-drafts/draft-iucg-iutf-tasks-01.txt >- the architectural framework : >ht >tp://www.ietf.org/internet-drafts/draft-iucg-internet-plus-09.txt >- and preparing the reset of our working alliance with MAAYA and=20 >Linguasphere on the matter. > >In this process, we will reactivate the UNIGRAPH and UNISIGN sites as=20 >FLOSS MDRS (WDE's continuation of the IANA). > >Let us know if you are interested, and we will keep you posted. >Best >jfc From jefsey@jefsey.com Mon Mar 12 10:27:35 2012 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 2A4CC21F8908 for ; Mon, 12 Mar 2012 10:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.685 X-Spam-Level: X-Spam-Status: No, score=-99.685 tagged_above=-999 required=5 tests=[AWL=-1.646, BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 jHY3emPzokEm for ; Mon, 12 Mar 2012 10:27:34 -0700 (PDT) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE8121F8907 for ; Mon, 12 Mar 2012 10:27:34 -0700 (PDT) Received: from 132.143-227-89.dsl.completel.net ([89.227.143.132]:51514 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S791i-0005lJ-Uv; Mon, 12 Mar 2012 10:27:19 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Mar 2012 18:30:51 +0100 To: Gervase Markham ,"J-F C. Morfin" From: JFC Morfin In-Reply-To: <4F5E2167.8060401@mozilla.org> References: <0AF28033-6ADC-4C8C-8A9B-F3891F05AF29@icann.org> <20120312030344.4532F39E107@eikenes.alvestrand.no> <4F5E2167.8060401@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: Message-Id: <20120312172734.6BE8121F8907@ietfa.amsl.com> Cc: Shawn Steele , iutf@iutf.org, Kim Davies , "idna-update@alvestrand.no" , James Mitchell , "iucg@ietf.org" , "vip@icann.org" Subject: Re: [iucg] Draft on IDN Tables in XML 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 Mar 2012 17:27:35 -0000 At 17:16 12/03/2012, Gervase Markham wrote: >On 12/03/12 03:07, J-F C. Morfin wrote: >>At 03:13 12/03/2012, Shawn Steele wrote: >>>What kinds of applications are expected to consume this data? What's >>>the target? >> >>The browsers want to use them. To validate the IDNs. This is why we need >>to get them synced. > >Shawn, representing Microsoft, asked this question, which I presume >suggests that Microsoft isn't sure what this data is for. I, >representing Mozilla, echo his question. >Which browser makers have asked for this data? Lead users. As you do not want to listen and talk to them, some grassroots people have decided the safest was to reconsider the whole user architecture, back to the IUI and ML-DNS. They probably are not on the same wave lengths as both of you? Don't ask me. My personnal focus here is only the IUI and ML-DNS architectural, documentation and safe testing framework; and to try to keep some liaison with the Internet stratum. This is juste because the "Internet+" stratum is necessary multiservice menu synergy and access, to multilinguistic support, and to my interest in the Intersem. I therefore only listen to the requests and investigate how the IUI could address them when the project matches my interest. I will know better once my I_Ds are finalized, a PLUS software architecture adopted, and some first prototyping achieved. Then IUI "slots" (smart local operating tasks) from projects will be experimented. Only by then we will know which projects have actually gone through and what they bring. You know FLOSS, it may take some time before all that preparatory process stabilizes. However, I have good hopes to see the things running in my old age. jfc From Shawn.Steele@microsoft.com Mon Mar 12 11:28:38 2012 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 83AB921F891C for ; Mon, 12 Mar 2012 11:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 0Lg3RsUFq0QJ for ; Mon, 12 Mar 2012 11:28:36 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id C716D21F8914 for ; Mon, 12 Mar 2012 11:28:36 -0700 (PDT) Received: from mail138-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 12 Mar 2012 18:28:35 +0000 Received: from mail138-tx2 (localhost [127.0.0.1]) by mail138-tx2-R.bigfish.com (Postfix) with ESMTP id DB696480358; Mon, 12 Mar 2012 18:28:35 +0000 (UTC) X-SpamScore: -36 X-BigFish: VS-36(zzbb2dI9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail138-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail138-tx2 (localhost.localdomain [127.0.0.1]) by mail138-tx2 (MessageSwitch) id 133157691480096_28793; Mon, 12 Mar 2012 18:28:34 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.240]) by mail138-tx2.bigfish.com (Postfix) with ESMTP id 0C9EF3E0094; Mon, 12 Mar 2012 18:28:34 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 12 Mar 2012 18:28:32 +0000 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.30]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Mon, 12 Mar 2012 18:28:16 +0000 From: Shawn Steele To: JFC Morfin , Gervase Markham , "J-F C. Morfin" Thread-Topic: Draft on IDN Tables in XML Thread-Index: AQHM//001Yu8XCUKSFa1bpD/NZtV0ZZm1weAgAAUu4CAAA6J8A== Date: Mon, 12 Mar 2012 18:28:16 +0000 Message-ID: References: <0AF28033-6ADC-4C8C-8A9B-F3891F05AF29@icann.org> <20120312030344.4532F39E107@eikenes.alvestrand.no> <4F5E2167.8060401@mozilla.org> <20120312172734.473C639E149@eikenes.alvestrand.no> In-Reply-To: <20120312172734.473C639E149@eikenes.alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Mon, 12 Mar 2012 18:58:30 -0700 Cc: "iutf@iutf.org" , Kim Davies , "idna-update@alvestrand.no" , James Mitchell , "iucg@ietf.org" , "vip@icann.org" Subject: Re: [iucg] Draft on IDN Tables in XML 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 Mar 2012 18:28:38 -0000 I don't see a relationship between the proposed XML behavior and JFC's idea= s. Nor am I interested in JFC's ML stuff, sorry. -Shawn -----Original Message----- From: idna-update-bounces@alvestrand.no [mailto:idna-update-bounces@alvestr= and.no] On Behalf Of JFC Morfin Sent: Monday, March 12, 2012 10:31 AM To: Gervase Markham; J-F C. Morfin Cc: Shawn Steele; iutf@iutf.org; Kim Davies; idna-update@alvestrand.no; Jam= es Mitchell; iucg@ietf.org; vip@icann.org Subject: Re: Draft on IDN Tables in XML At 17:16 12/03/2012, Gervase Markham wrote: >On 12/03/12 03:07, J-F C. Morfin wrote: >>At 03:13 12/03/2012, Shawn Steele wrote: >>>What kinds of applications are expected to consume this data? What's=20 >>>the target? >> >>The browsers want to use them. To validate the IDNs. This is why we=20 >>need to get them synced. > >Shawn, representing Microsoft, asked this question, which I presume=20 >suggests that Microsoft isn't sure what this data is for. I,=20 >representing Mozilla, echo his question. >Which browser makers have asked for this data? Lead users. As you do not want to listen and talk to them, some grassroots = people have decided the safest was to reconsider the whole user architectur= e, back to the IUI and ML-DNS. They probably are not on the same wave leng= ths as both of you? Don't ask me. My personnal focus here is only the IUI and ML-DNS architectural, documenta= tion and safe testing framework; and to try to keep some liaison with the I= nternet stratum. This is juste because the "Internet+" stratum is necessary= multiservice menu synergy and access, to multilinguistic support, and to m= y interest in the Intersem. I therefore only listen to the requests and investigate how the IUI could a= ddress them when the project matches my interest. I will know better once m= y I_Ds are finalized, a PLUS software architecture adopted, and some first = prototyping achieved. Then IUI "slots" (smart local operating tasks) from p= rojects will be experimented. Only by then we will know which projects have= actually gone through and what they bring. You know FLOSS, it may take som= e time before all that preparatory process stabilizes. However, I have good= hopes to see the things running in my old age. jfc =20 _______________________________________________ Idna-update mailing list Idna-update@alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update From jefsey@jefsey.com Mon Mar 12 19:04:10 2012 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 0C49121F891C for ; Mon, 12 Mar 2012 19:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.882 X-Spam-Level: X-Spam-Status: No, score=-100.882 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 MepzldFUzFJ1 for ; Mon, 12 Mar 2012 19:04:09 -0700 (PDT) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9918421F891B for ; Mon, 12 Mar 2012 19:04:09 -0700 (PDT) Received: from 132.143-227-89.dsl.completel.net ([89.227.143.132]:52993 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S7H5e-0007Kw-6M; Mon, 12 Mar 2012 19:03:54 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Mar 2012 03:07:27 +0100 To: Shawn Steele , Gervase Markham ,"J-F C. Morfin" From: JFC Morfin In-Reply-To: References: <0AF28033-6ADC-4C8C-8A9B-F3891F05AF29@icann.org> <20120312030344.4532F39E107@eikenes.alvestrand.no> <4F5E2167.8060401@mozilla.org> <20120312172734.473C639E149@eikenes.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20120313020409.9918421F891B@ietfa.amsl.com> Cc: "iutf@iutf.org" , Kim Davies , "idna-update@alvestrand.no" , James Mitchell , "iucg@ietf.org" , "vip@icann.org" Subject: Re: [iucg] Draft on IDN Tables in XML 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 Mar 2012 02:04:10 -0000 At 19:28 12/03/2012, Shawn Steele wrote: >I don't see a relationship between the proposed XML behavior and >JFC's ideas. Nor am I interested in JFC's ML stuff, sorry. Noted. jfc From jefsey@jefsey.com Wed Mar 14 11:12:16 2012 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 3D26121E8027; Wed, 14 Mar 2012 11:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.918 X-Spam-Level: X-Spam-Status: No, score=-100.918 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_20=-0.74, 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 j6HnNY-xxdws; Wed, 14 Mar 2012 11:12:15 -0700 (PDT) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4D75321E8024; Wed, 14 Mar 2012 11:12:15 -0700 (PDT) Received: from 132.143-227-89.dsl.completel.net ([89.227.143.132]:59854 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1S7sgD-00012k-C3; Wed, 14 Mar 2012 11:12:10 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Mar 2012 19:15:39 +0100 To: Mark Nottingham ,Graham Klyne From: JFC Morfin In-Reply-To: <8BC7A58C-5633-48A0-892B-DA22434ACFCE@mnot.net> <4F5F02E2.3040901@ninebynine.org> References: <4F5B2E58.7070008@ninebynine.org> <8BC7A58C-5633-48A0-892B-DA22434ACFCE@mnot.net> <4F5B2E58.7070008@ninebynine.org> <8BC7A58C-5633-48A0-892B-DA22434ACFCE@mnot.net> <4F5F02E2.3040901@ninebynine.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: Message-Id: <20120314181215.4D75321E8024@ietfa.amsl.com> Cc: "iutf@iutf.org" , happiana@ietf.org, "iucg@ietf.org" Subject: Re: [iucg] [happiana] draft 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 Mar 2012 18:12:16 -0000 At 05:04 13/03/2012, Mark Nottingham wrote: >One of the issues that I don't talk about here (yet) is variance >between processes; if each process is slightly (or greatly) >different, it's harder for people to apply whatever knowledge they get. >In other words, while it may be gratifying for us as document >authors to come up with convoluted, "perfect" processes that are >"just right" for our situation, I suspect we're not doing the people >who actually use the registries any favours... > > [[Flesh out some. IANA: Is this a practical proposition? I'm > anticipating that something like a wiki or linked blog might be > used for this. E.g. if each entry in a registry is a blog post > with its own comments stream?]] >I agree, but wasn't sure whether this draft was an appropriate >place; i.e., is this a consideration when establishing a registry, >or is it an IANA operational consideration? At 09:18 13/03/2012, Graham Klyne wrote: >Agreed. Maybe having a small set of examples or patterns to follow >might reduce spurious diversity? >In suggesting this, I was thinking of allowing some of the benefits >of the wiki-as-registry model to apply. I feel these two points: "variant between processes" (and the importance of the difference), and "wiki-as-registry" are of the essence when considering technology use (vs. protocol definition). If I refer to IDNA2008, it introduced a non-defined fringe to fringe process (production of the A-labels) as a being end to end trustable. RFC 5895 says that this is "unusual". I deduce from this the acceptance of the principle of subsidiarity in the Internet architecture to externally (and powerfully) support the missing presentation layer. Even, if this is not the case: documentation of U-label mapping and variances has to be done somewhere if it is to work and we are to trust it. ICANN/VIP discusses that issue and is quite unclear about its need and how and with who to do that. Through the saga of the RFC 4646 I learned the size of the linguistic tables, its possible political use, and I opposed the lack of any DDDS solution for their synchronization with billions of end-users. This made them a permanent DoS on the Internet. On the Internet use side (IUCG) we wish to support and document this. However, the size, synchronization, multilinguization (description of all the languages), polylinguization (in all the languages), for each Presentation and DNS CLASS, plus the explanation of how to handle the natural variance of the support, that Mark notes, of the Variants (as per the ICANN understanding - no pun intended) makes a huge opendata system and maintenance task we will have to partly assist with automation, that we cannot multiply with documentation and examples links. Just too big if centralized. The wiki-as-registry model in a cloud of ressources from DNS Registries, would be a very attractive model. It would be interesting if we could make it converge with IANA and DDDS and support its access in different serialization formats. I was thinking of an IDv6 (identified interface ID) addressable wiki-as-registry-cell-server accessible through a lang-tag-like based domain name with a DNS local sub-nameserver. The whole issue would be metadata polynym formating (polynym: cross-language "strict" synonyms, considering the variance between processes noted by Mark, within the limits of process differences, cf. Jon Postel Principle of Robustness and RFC 3439 Principle of Simplicity). I would be interested by your comments/suggestions. jfc From jefsey@jefsey.com Fri Mar 23 05:08:38 2012 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 293A321F84F8; Fri, 23 Mar 2012 05:08:38 -0700 (PDT) X-Quarantine-ID: <7CYRv1CUgyVO> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char C3 hex): To: ...adobe.com>,\n "Martin J. D\303\274rst" ) id 1SB3I4-0007dO-TK; Fri, 23 Mar 2012 05:08:21 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 Mar 2012 13:12:18 +0100 To: Larry Masinter , "Martin J. Dürst" , Graham Klyne From: JFC Morfin In-Reply-To: References: <4F5B2E58.7070008@ninebynine.org> <8BC7A58C-5633-48A0-892B-DA22434ACFCE@mnot.net> <4F5F02E2.3040901@ninebynine.org> <4F605102.3050709@it.aoyama.ac.jp> <4F6060CB.7090304@ninebynine.org> <4F606D64.7050004@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 - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20120323120833.BC90921F84D3@ietfa.amsl.com> Cc: "happiana@ietf.org" , "iucg@ietf.org" Subject: Re: [iucg] [happiana] draft 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, 23 Mar 2012 12:08:38 -0000 At 06:13 22/03/2012, Larry Masinter wrote: >An important function of a registry is its persistence guarantee... >that over time, registered values won't get forgotten, and the >update policy where registered values can evolve. >That is, every registry carries a policy of how updates are made, >based on the requirements of the contexts in which registered values are used. >The purpose of any "process" around registration management is to >insure that policies are followed, without adding unneeded overhead. Larry, convergence on the registry issue is necessary in the Internet environment, it is mandatory in the Internet+ framework I work on (http://www.ietf.org/id/draft-iucg-internet-plus-09.txt) and of the essence for the Intersem (semiotic Internet) facilitation auxilliary intelligence tools for intercomprehension which is the ultimate target. The JTC1/SG32/WG2 work is a central source of ideas but this complex work should be "internetized". I perused your two texts. They offer an interesting point of view and a framework to work on a convergence between the IETF end to end, the IUCG/IUTF (http://www.ietf.org/id/draft-iucg-iutf-tasks-01.txt) fringe to fringe, and W3C web to web strata. The emerging IUse community (http://iucg.org/wiki/IUse_community) works in informally using wikis (http://iucg.org/wiki/IUWW) and mails (iucg@ietf.org non-WG mailing list of which I am the facilitator). Since your texts are editor's property and not covered by IETF copyrights, I would need your authorization to use them for an IUse Wiki Work (IUWW) you will get the outputs or access. Thank you. jfc From jefsey@jefsey.com Fri Mar 23 11:02:13 2012 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 8D07621F865C for ; Fri, 23 Mar 2012 11:02:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E0 hex): Subject: ...MFr] copier-coller faits \340 pa rtir de\n W[...] X-Spam-Flag: NO X-Spam-Score: -98.588 X-Spam-Level: X-Spam-Status: No, score=-98.588 tagged_above=-999 required=5 tests=[AWL=-2.475, BAYES_80=2, MIME_8BIT_HEADER=0.3, SUBJECT_NEEDS_ENCODING=0.001, SUBJ_ILLEGAL_CHARS=1.586, 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 ani-6eUWa8My for ; Fri, 23 Mar 2012 11:02:08 -0700 (PDT) Received: from m169.montage2.altserver.com (m169.montage2.altserver.com [72.34.52.169]) by ietfa.amsl.com (Postfix) with ESMTP id 13EA721F861A for ; Fri, 23 Mar 2012 11:02:08 -0700 (PDT) Received: from 213.210-227-89.dsl.completel.net ([89.227.210.213]:58387 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1SB8oN-0006ZB-4k; Fri, 23 Mar 2012 11:02:03 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 Mar 2012 19:06:01 +0100 To: discussions@lists.wikimedia.fr From: JFC Morfin Subject: Re: [Discussions WMFr] copier-coller faits à pa rtir de Wikipédia In-Reply-To: References: <4F6B788E.8040200@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20120323180208.13EA721F861A@ietfa.amsl.com> Cc: "iucg@ietf.org" 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, 23 Mar 2012 18:02:13 -0000 At 15:44 23/03/2012, Aude Mugnier wrote: >Je suis désolée, je n'ai pas tout lu mais je suis globalement >d'accord avec les objections de Laurent, Léa et Benoît. J'en rajoute >une : cette discussion concerne le développement de Wikipédia et >devrait peut être se passer là-bas et non sur cette liste. Aude, cette discussion relève d'une suggestion fondamentale à l'Internet amenée par un utilisateur pilote. Elle tombe très exactement dans le créneau des suggestions que l'on peut attendre des chapitres Wikimedia en tant qu'utilisateurs (à travers une application leader) de l'internet. C'est pour de telles idées (au passage susceptible de légalement sauver Wikipedia dans le contexte du Cybersecurity Act, qui finira bien d'une manière ou d'une autre à être voté) et les réponses apportées durant ce débat, que j'ai rejoint la WMFr. Elle exprime à sa manière une préoccupation transversale à toute l'architecture Internet/IUI/W3C actuelle et à leurs approches sémantiques. Nous travaillons à un cadre architectural dans le contexte de l'IUCG et je travaille à la préparation d'une solution prototype qui pourrait être basée sur sa résolution (DistriRegiWiki) et permettre de supporter la taille et le besoin de grands wikis multipositions (la page peut présenter des visions différentes selon les opinions du lecteur - pour une connaissance libre et sans frontières. Vous pourrez trouver la page racine de ce travail sous: http://iucg.org/wiki/Quotation_Cortege. Plusieurs WG IETF et W3C sont concernés par ce type de demande. J'ai pris contact avec deux ou trois d'entre eux pour faire le point sur leur état de pensée actuel (beaucoup de choses changent peu à peu dans la vision architecturale de l'internet après les options acceptées pour le support de la diversité linguistique). Je tiendrai cette liste au courant, la R&D et la standardisation ne vont pas très vite. Il faut compter des années. Mais il faut aussi commencer. Merci à Rémi. S'il y en a qui veulent contribuer : tous les textes sont en anglais, à l'IUCG les débats peuvent être en français, mais les Drafts doivent être en anglais. Le travail le plus fastidieux sera la compilation d'un état des lieux (protocoles, expériences anciennes, etc.) l'IETF ayant publié 6500 RFC, mais aucune synthèse, ni mise à jour. Un document remplace des bouts d'un autre. Cordialement jfc