From jefsey@jefsey.com Thu Jul 21 18:20:44 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECF821F8A6C; Thu, 21 Jul 2011 18:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-6MsyiQ3XxI; Thu, 21 Jul 2011 18:20:44 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1704B21F8A7A; Thu, 21 Jul 2011 18:20:44 -0700 (PDT) Received: from 135.91-227-89.dsl.completel.net ([89.227.91.135]:52511 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qk4Pz-0000ZF-1e; Thu, 21 Jul 2011 18:20:43 -0700 Message-Id: <7.0.1.0.2.20110722022958.05f6bb18@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 22 Jul 2011 03:14:01 +0200 To: iucg@ietf.org From: JFC Morfin In-Reply-To: <4E274657.3060405@babelmonkeys.de> References: <4E26F4D9.9000405@babelmonkeys.de> <20110720162701.GA97011@stpeter.im> <4E274657.3060405@babelmonkeys.de> 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: precis@ietf.org Subject: Re: [iucg] [precis] draft slides for precis-framework 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, 22 Jul 2011 01:20:44 -0000 Apps-discuss teach internationalization needs to their members. http://www.saint-andre.com/ietf/i18n-intro.pdf Then PRECIS (stringprep) has also its set of slides: http://www.saint-andre.com/ietf/ietf81-precis-framework.pdf These two problems are intricated because they share the same problem: the sustainable use of Unicode. At 23:19 20/07/2011, Florian Zeitz wrote: >For implementers caring about code/executable size that's probably >about the same. > From a specification/standards point of view I see the merit/your point. The problem is that Unicode is still an inadequate asolution to support computer network use by real people. And that majuscules are still not supported what makes the whole considered things "senseless" (I mean semantically lame) for Latin languages, in particular French. I did not see the main point quoted in these slides, which is orthotypography. As long as one considers that the Internet is 7 bits ASCII I am afraid we also do not perceive the problem correctly, what means that we will most probably be unable to explore the right solution, whatever it may be. I know getting rid in part of Unicode and changing our reading of the Internet technology is something hardly conceivable, hence inacceptable. However, this is what we just did with IDNA2008. Because everyone wanted to be free from Unicode versioning and users could not accept Internet internal mapping. We now need multilinguisation, i.e. the coexistence of every language on an equal footing and a physhing-proof universal character system. The best stringprep solution is no stringprep. This is RFC 3439 principle of simplicity. I think Unicode is not RFC 3439 conformant, hence all our problems. Sure we need an IETF temporary patch, but we also need a sustainable long term solution. If we do not consider the later, IMHO we will not build a good enough patch. jfc From jefsey@jefsey.com Thu Jul 21 18:22:58 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F2C21F8922 for ; Thu, 21 Jul 2011 18:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.462 X-Spam-Level: X-Spam-Status: No, score=-100.462 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHLtOMJvpM1A for ; Thu, 21 Jul 2011 18:22:58 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8F021F861A for ; Thu, 21 Jul 2011 18:22:58 -0700 (PDT) Received: from 135.91-227-89.dsl.completel.net ([89.227.91.135]:52546 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qk4S3-00014o-LZ; Thu, 21 Jul 2011 18:22:52 -0700 Message-Id: <7.0.1.0.2.20110722013948.05f6b5f8@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 22 Jul 2011 03:22:14 +0200 To: iucg@ietf.org From: jefsey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: vip@icann.org, "idna-update@alvestrand.no" , aps-discuss@ietf.org Subject: [iucg] Internationalization glossary 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, 22 Jul 2011 01:22:58 -0000 For information I formated Paul Hoffman's and John Klensin Draft and the ICANN VIP initial terminology document in a similar wiki format to help a work towards a joint glossary where we could add ML-DNS, IUI and multilingualisation terms. We need this since IETF, ICANN and IUse communities steers on different tacks and we will need the IUI to support at least the three of them. http://iucg.org/wiki/Wiki_RFC_3536bis http://iucg.org/wiki/ICANN_Variant_Issues_Project_-_Definitions jfc From jothan@gmail.com Thu Jul 21 21:55:44 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365C621F8725 for ; Thu, 21 Jul 2011 21:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmiwNvEoj4mY for ; Thu, 21 Jul 2011 21:55:43 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDEC21F85D9 for ; Thu, 21 Jul 2011 21:55:43 -0700 (PDT) Received: by vws12 with SMTP id 12so1724834vws.31 for ; Thu, 21 Jul 2011 21:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CEZd/vmI+pWyiUhlY1+CUSSUX1kjHuCx0kYXowbH2Jk=; b=KDzp1AnJC/GDtESkwjg8rhGJic6qE+LhT9REtNDmAmmTKlVrgVbFUpC7P3y1TWrRYM hXRe+bURSTgih55VtPkvzV9mPZ49UkJ97viaujLVnyQiqZzYUvSlTonYXP/4/MTZYYLD +KdxokwvtLLVRXyFwYAX69gmTTD0c5EFoJjUw= Received: by 10.52.30.226 with SMTP id v2mr1039855vdh.504.1311310542087; Thu, 21 Jul 2011 21:55:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.185.129 with HTTP; Thu, 21 Jul 2011 21:55:02 -0700 (PDT) In-Reply-To: <7.0.1.0.2.20110722013948.05f6b5f8@jefsey.com> References: <7.0.1.0.2.20110722013948.05f6b5f8@jefsey.com> From: Jothan Frakes Date: Fri, 22 Jul 2011 00:55:02 -0400 Message-ID: To: jefsey Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 22 Jul 2011 03:52:16 -0700 Cc: vip@icann.org, "idna-update@alvestrand.no" , iucg@ietf.org, aps-discuss@ietf.org Subject: Re: [iucg] [vip] Internationalization glossary 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, 22 Jul 2011 04:55:44 -0000 Jefsey- Very nice of you to assemble this, thank you for taking the time to do it. -Jothan Jothan Frakes On Thu, Jul 21, 2011 at 9:22 PM, jefsey wrote: > > For information I formated Paul Hoffman's and John Klensin Draft and the > ICANN VIP initial terminology document in a similar wiki format to help a > work towards a joint glossary where we could add ML-DNS, IUI and > multilingualisation terms. We need this since IETF, ICANN and IUse > communities steers on different tacks and we will need the IUI to support at > least the three of them. > > http://iucg.org/wiki/Wiki_RFC_3536bis > http://iucg.org/wiki/ICANN_Variant_Issues_Project_-_Definitions > > jfc > > From jefsey@jefsey.com Sat Jul 23 09:57:14 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DC921F8556 for ; Sat, 23 Jul 2011 09:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.443 X-Spam-Level: X-Spam-Status: No, score=-100.443 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61tSNuDLEl-S for ; Sat, 23 Jul 2011 09:57:10 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id D6FEA21F8A66 for ; Sat, 23 Jul 2011 09:57:10 -0700 (PDT) Received: from 135.91-227-89.dsl.completel.net ([89.227.91.135]:55799 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QkfVl-0000ip-Jd; Sat, 23 Jul 2011 09:57:10 -0700 Message-Id: <7.0.1.0.2.20110722125423.05f6af90@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 23 Jul 2011 18:57:29 +0200 To: NCSG-NCUC-DISCUSS@LISTSERV.SYR.EDU From: JFC Morfin In-Reply-To: <2726A100CA2E42E4B208682ED3318797@sb.litts.net> References: <4E272216.5050806@seltzer.com> <8FD8E555CD7F4F98B4E5E3C6A1EF712A@sb.litts.net> <4E28DBCC.1030507@gmail.com> <2726A100CA2E42E4B208682ED3318797@sb.litts.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_228665657==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: vip@icann.org, iucg@ietf.org Subject: Re: [iucg] [ncsg-policy] Proposed NCUC Comments on the WHOIS Review Team Discussion Paper X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 16:57:14 -0000 --=====================_228665657==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:17 22/07/2011, Timothe Litt wrote: >Like driving, a network presence, including a domain name, is a >privilege and not an absolute right. Who decided that? Milton has addressed that point. However, Milton reintroduces the point when he states: " Instead we put limits on who can access this database (the police, LEAs) and the uses to which the data can be put." Who is "we". There is a single authority: the zone manager, there is only one law: the national law of the zone manager. There is only one rule to respect: the most stringent sovereign privacy rule, worldwide - otherwise there is not world of right. Now, let me clarify. There is no right or privilege in Internet use, there are facts. Rights and privileges may only concern Internet usages and people's Internet related behaviours and be enforced by governance regalian entities. The Internet is a technical consensus It works the way its programs are written. Programs are written to work. To obtain it, developers consider RFCs in the OSI layers 1 to 7; and listen to the users (the "market") otherwise. This is why the Internet constitution is in the code, not in the ICANN community. ICANN is the leader of one of the communities populating the Internet community, which is actually a community of communities. In the sole naming area, the Internet community has : - one single rule which is the DNS that provide information enough (mail, nameserver, registry, zone manager) to be maintained. - at least seven sub-communities that technology MUST support: 1. ICANN full-rate gTLDs, the vip@icann.org mailing list should discuss the technical requirements. 2. ICANN JAS-rated. There is no indication yet about their possible technical difference with the above. 3. open source gTLDs. 4. government created gTLD, e.g. China. 5. ISO 3166/MA decided ccTLDs. 6. industrial community (GSMA, Google, etc.) to support their own root. Who knows about .gsm? 7. non-Internet limited emergent IUse community and IUI (Intelligent Use Interface) related worked-on technologies. IDNA2008 exemplified how RFCs fully support it. ICANN has documented this situation. That was through its 2001 ICP-3, http://www.icann.org/en/icp/icp-3.htm that states: "In an ever-evolving Internet, ultimately there may be better architectures for getting the job done where the need for a single, authoritative root will not be an issue. But that is not the case today. And the transition to such an architecture, should it emerge, would require community-based approaches. In the interim, responsible experimentation should be encouraged". In 2011, in approving the gTLDs system, ICANN has acknowledged that what was not the case in 2001 is in fact the case today. The single, authoritative root is not a limited file anymore that is disseminated by the root server system. ICANN tends to present it as an open file while IUI sees it as a virtual matrix with millions of dimensions. IUI responds to the WSIS demand for a people centered society and inherits from a community experience that was acquired along the ICP-3 rules ("dot-root" project): everyone runs and creates his/her own needed part of a root that is not limited to names of the sole Internet. This results from a third principle in the Internet architecture (RFC 1958: permanent change; RFC 3439: simplicity) the principle of subsidiarity that IDNA2008 exemplifies. IDNA2008 was a positive surprise. The IDNA2008 positive surprise was that subsidiarity is built-in the Internet architecture from the very begining. There is not a single bit to change. However, what has not been done yet is to document the transition to get rid of the unnecessary added-complexity that has accumulated over the decades and to welcome the permitted innovation. This is the challenge: to simultaneously support and test opposed transitions like ICANN and IUse (and what is in between) without confusing either of them. This is why both of them have engaged in an analysis and documentation efforts and should try to cooperate (e.g. http://idna2010) This is why we need a consensual cooperation. However, this cooperation is to be engaged in a technically and politically confused context due to the complementary charters of IETF and of the UNICODE Consortium, and to the discrepancies between the GAC and the WSIS objectives. 1. Clarification was obtained last year from IESG and IAB through my appeal over the IESG misrepresentation of the importance of IDNA2008. I could summarize it as: the IUI is an interface between the Internet (and alternate network technologies) and the external world. IETF is competent and interested in what belongs to or impacts the Internet but does not want to engage outside of the Internet area. 2. A clarification should be found with UNICODE through the "stringprep" replacement. IDNA2003 used "stringprep" to interface UNICODE to punycode entries. Stringprep is used by other IETF protocols but turns obsolete, since IDNA2008 does not use it anymore, freeing IDNA from Unicode versioning. The IETF (WG/PRECIS) tries to work out a solution. For good reasons that have endangered the IDNA2008 consensus, IUsers have a different vision of Unicode deliverables, and would like to consider starting at a deeper point of simplicity. IDNA2008 has protected IDNA from Unicode versioning. IUsers would like the IUI to protect them from Unicode and to void the need for stringprep in considering a no-phishing network protocol oriented scripting based on the visual aspects of the characters symbols in an unique common fount. This would remove the Unicode consortium from the network multilingualization loop and ease the naming adminance (long-term netkeeping, as opposed to medium-term governance and short-term operance). Two systems are actually of no real technical and operational use in well organized and secure DNS operations: - the root server system that answers 96% of erroneous requests and data everyone already has. - the WHOIS is system that violates the privacy law of most of the countries having one - and is a source for spaming, spoofing, etc. In addition, one system will become local and needs to get reviewed now ICANN has started selling $ 185.000 + expenses what everyone can deploy for free and get used by billions (reasonably within less than five years due to existing RFCs, word of the mouth, testing, new products and services being supported) or Google can deploy in minutes. That system is the ICANN whole technico-legal system itself. This means that the priority is to correctly insert that ICANN system into the foreseeable future development of the world digital ecosystem (WDE). This is to protect stable operations and usage by its customers. This cannot be done by rules or agreements (you cannot negotiate with billions of individuals). It can only be done through: - a stable, secure, simple, innovative technology these individuals will want to use for free as a "Plus" to the Internet they are used to utilize everyday. For many reasons IAB started to document IDNinApplication and xNAMES in the DNS as we consider them today are inadequate. However, a reponse MUST be found. - and support services they will competitively adopt. I doubt the WHOIS is going to be a major part of such services: because it does not propose anything to the advantage of the registrant. Ths WHOIS only was a Jon Postel's tool to manage "his" network with people moving around every academic year. A dinosaur. What actually IDNA2008 says is: here the way for DNS oriented concerns to interface the Internet DNS. The rest is to be entirely reviewed accordingly. Best jfc --=====================_228665657==.ALT Content-Type: text/html; charset="us-ascii" At 12:17 22/07/2011, Timothe Litt wrote:
Like driving, a network presence, including a domain name, is a privilege and not an absolute right.


Who decided that? Milton has addressed that point.
However, Milton reintroduces the point when he states: " Instead we put limits on who can access this database (the police, LEAs) and the uses to which the data can be put." Who is "we". There is a single authority: the zone manager, there is only one law: the national law of the zone manager. There is only one rule to respect: the most stringent sovereign privacy rule, worldwide - otherwise there is not world of right.


Now, let me clarify.
There is no right or privilege in Internet use, there are facts. Rights and privileges may only concern Internet usages and people's Internet related behaviours and be enforced by governance regalian entities.


The Internet is a technical consensus
It works the way its programs are written. Programs are written to work. To obtain it, developers consider RFCs in the OSI layers 1 to 7; and listen to the users (the "market") otherwise. This is why the Internet constitution is in the code, not in the ICANN community. ICANN is the leader of one of the communities populating the Internet community, which is actually a community of communities.


In the sole naming area, the Internet community has :
- one single rule which is the DNS that provide information enough (mail, nameserver, registry, zone manager) to be maintained.
- at least seven sub-communities that technology MUST support:

1. ICANN full-rate gTLDs, the vip@icann.org mailing list should discuss the technical requirements.
2. ICANN JAS-rated. There is no indication yet about their possible technical difference with the above.
3. open source gTLDs.
4. government created gTLD, e.g. China.
5. ISO 3166/MA decided ccTLDs.
6. industrial community (GSMA, Google, etc.) to support their own root. Who knows about .gsm?
7. non-Internet limited emergent IUse community and IUI (Intelligent Use Interface) related worked-on technologies. IDNA2008 exemplified how RFCs fully support it.


ICANN has documented this situation.
That was through its 2001 ICP-3, http://www.icann.org/en/icp/icp-3.htm that states: "In an ever-evolving Internet, ultimately there may be better architectures for getting the job done where the need for a single, authoritative root will not be an issue. But that is not the case today. And the transition to such an architecture, should it emerge, would require community-based approaches. In the interim, responsible experimentation should be encouraged".


In 2011, in approving the gTLDs system,
ICANN has acknowledged that what was not the case in 2001 is in fact the case today. The single, authoritative root is not a limited file anymore that is disseminated by the root server system. ICANN tends to present it as an open file while IUI sees it as a virtual matrix with millions of dimensions. IUI responds to the WSIS demand for a people centered society and inherits from a community experience that was acquired along the ICP-3 rules ("dot-root" project): everyone runs and creates his/her own needed part of a root that is not limited to names of the sole Internet. This results from a third principle in the Internet architecture (RFC 1958: permanent change; RFC 3439: simplicity) the principle of subsidiarity that IDNA2008 exemplifies.


IDNA2008 was a positive surprise.
The IDNA2008 positive surprise was that subsidiarity is built-in the Internet architecture from the very begining. There is not a single bit to change. However, what has not been done yet is to document the transition to get rid of the unnecessary added-complexity that has accumulated over the decades and to welcome the permitted innovation. This is the challenge: to simultaneously support and test opposed transitions like ICANN and IUse (and what is in between) without confusing either of them. This is why both of them have engaged in an analysis and documentation efforts and should try to cooperate (e.g. http://idna2010)


This is why we need a consensual cooperation.
However, this cooperation is to be engaged in a technically and politically confused context due to the complementary charters of IETF and of the UNICODE Consortium, and to the discrepancies between the GAC and the WSIS objectives.

1. Clarification was obtained last year from IESG and IAB through my appeal over the IESG misrepresentation of the importance of IDNA2008. I could summarize it as: the IUI is an interface between the Internet (and alternate network technologies) and the external world. IETF is competent and interested in what belongs to or impacts the Internet but does not want to engage outside of the Internet area.

2. A clarification should be found with UNICODE through the "stringprep" replacement. IDNA2003 used "stringprep" to interface UNICODE to punycode entries. Stringprep is used by other IETF protocols but turns obsolete, since IDNA2008 does not use it anymore, freeing IDNA from Unicode versioning. The IETF (WG/PRECIS) tries to work out a solution. For good reasons that have endangered the IDNA2008 consensus, IUsers have a different vision of Unicode deliverables, and would like to consider starting at a deeper point of simplicity.


IDNA2008 has protected IDNA from Unicode versioning.
IUsers would like the IUI to protect them from Unicode and to void the need for stringprep in considering a no-phishing network protocol oriented scripting based on the visual aspects of the characters symbols in an unique common fount. This would remove the Unicode consortium from the network multilingualization loop and ease the naming adminance (long-term netkeeping, as opposed to medium-term governance and short-term operance).

 
Two systems are actually of no real technical and operational use in well organized and secure DNS operations:
- the root server system that answers 96% of erroneous requests and data everyone already has.
- the WHOIS is system that violates the privacy law of most of the countries having one - and is a source for spaming, spoofing, etc.

In addition, one system will become local and needs to get reviewed now ICANN has started selling $ 185.000 + expenses what everyone can deploy for free and get used by billions (reasonably within less than five years due to existing RFCs, word of the mouth, testing, new products and services being supported) or Google can deploy in minutes.
That system is the ICANN whole technico-legal system itself.

 
This means that the priority is to correctly insert that ICANN system into the foreseeable future development of the world digital ecosystem (WDE).
This is to protect stable operations and usage by its customers. This cannot be done by rules or agreements (you cannot negotiate with billions of individuals). It can only be done through:
- a stable, secure, simple, innovative technology these individuals will want to use for free as a "Plus" to the Internet they are used to utilize everyday. For many reasons IAB started to document IDNinApplication and xNAMES in the DNS as we consider them today are inadequate. However, a reponse MUST be found.
- and support services they will competitively adopt. I doubt the WHOIS is going to be a major part of such services: because it does not propose anything to the advantage of the registrant. Ths WHOIS only was a Jon Postel's tool to manage "his" network with people moving around every academic year. A dinosaur.

What actually IDNA2008 says is: here the way for DNS oriented concerns to interface the Internet DNS. The rest is to be entirely reviewed accordingly.

Best
jfc

--=====================_228665657==.ALT-- From jefsey@jefsey.com Mon Jul 25 14:15:14 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F90721F8A57; Mon, 25 Jul 2011 14:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.595 X-Spam-Level: X-Spam-Status: No, score=-100.595 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU3vN70QYXi7; Mon, 25 Jul 2011 14:15:14 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id E4DCA21F89B8; Mon, 25 Jul 2011 14:15:06 -0700 (PDT) Received: from 135.91-227-89.dsl.completel.net ([89.227.91.135]:62589 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QlSUP-0006GG-TS; Mon, 25 Jul 2011 14:15:02 -0700 Message-Id: <7.0.1.0.2.20110725192800.06a72ea0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 25 Jul 2011 22:59:27 +0200 To: Andrzej Bartosiewicz , Jothan Frakes From: JFC Morfin In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: vip@icann.org, precis@ietf.org, iucg@ietf.org Subject: Re: [iucg] [vip] Educational session on existing variant practices 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, 25 Jul 2011 21:15:14 -0000 At 09:40 25/07/2011, Andrzej Bartosiewicz wrote: >Sure. I will cover that... Dear Andrzeij, I am not sure this introduction covers the IDNA2008 context? We reach the IDNA2008 consensus due to the RFC 5895 draft, that was further on published for information only as it exemplifies one of the many possible ways to address many different real life problems including mapping, variants, etc. Also, you seem to consider variants only in the TLD and domain name context (without indicating the DNS options). However the problem also affects many other Internet protocols. The WG/PRECIS is chartered to help a solution to replace stringprep in these protocols. Don't you think it would be advisable to present all these issues together? This might help a lot? RFC 1958 states: "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." So, whatever the technical solution, is there is one, should be the same. Or do you think the variant/homograph problem should only be addressed as a general digital ecosystem scripting issue outside of the Internet context ? An Unicode extension as a script table able to cleanly support any entry without any risk of variant and homograph problem because it would be a graphcode only based upon the geometric graphic form. This would be really sympathetic to me as I think this is the only solution on the long range and that ccTLDs could easily contribute in sending a copy of every symbol they accept in a given script, based upon a common fount. I suppose people like ABBY could also help? This field is very wide, isn't it? Lot of consideration ahead, I am afraid. jfc From jefsey@jefsey.com Mon Jul 25 17:38:51 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004C121F877F for ; Mon, 25 Jul 2011 17:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.261 X-Spam-Level: X-Spam-Status: No, score=-101.261 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCjw8vgkLEkL for ; Mon, 25 Jul 2011 17:38:50 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 65F1421F877D for ; Mon, 25 Jul 2011 17:38:50 -0700 (PDT) Received: from 135.91-227-89.dsl.completel.net ([89.227.91.135]:63344 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QlVfc-0000QP-DI; Mon, 25 Jul 2011 17:38:49 -0700 Message-Id: <7.0.1.0.2.20110726005758.06a72fe8@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 26 Jul 2011 02:39:14 +0200 To: Andrew Sullivan ,vip@icann.org From: JFC Morfin In-Reply-To: <20110725215540.GA1878@shinkuro.com> References: <20110725215540.GA1878@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: iucg@ietf.org Subject: Re: [iucg] [vip] Types of variants: do we have consensus? 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, 26 Jul 2011 00:38:51 -0000 At 23:57 25/07/2011, Andrew Sullivan wrote: >In the case of the third class -- semantic similarity -- I first of >all deny the premise. Dear Andrew, The point here is to understand what we are talking about, in which context. My understanding, is that ICANN, as a an Internet community sub-community leader, attempts to define terms to be used in the IDN TLDs (let call them once for all ITLDs) areas. This is therefore not in a DNS label context, but in a much larger context, which also includes the IDNA2008 context and the users (every user, even non Internet users) context. In that context there are the IDNA2008 protected DNS context and the IDNA2008 affected Internel protocols contexts that WG/PRECIS is to address. Every point you make is of real interest, but here the processor is _not_ Bind, Atlas, Unbound, etc. the processor is the NSP.HSS, or homo sapiens sapiens natural semantic processor. And the challenge is to write the glossary of an "How to Use them together" that the people need. No one better than the co-author of draft-ietf-precis-problem-statement-00.txt can help people here, but this is not the IETF. This is a part of the users, the people, the governments, etc. community. So, the first thing we need is not to define what a variant may be, but in which broad or limited context do we want to speak about variants. This will necessariy affect the definition we will produce and the rest of the vocabulary we may propose. >I claim that _no_ DNS label has a meaning. I certainly agree with you that DNS labels have no meaning. But ITLDs and IDNs necessarily have a sense. That sense is necessarily related to an orthotypography (a syntax in using its characters). This is that sense that some organizations want to pay hundreds of thousand dollars. A variant is an orthotypography confusion: the user saw the label but envisonned a different sense from the intended/paid one. Whatever the reason. Then we may sort the reasons. Sure, this is a problem since the IETF does not support orthotypography. However, it did not supported the presentation layer either. Look, IDNA2008 is unacceptable because you guys never wanted to consider French majuscules, making many IDNS senseless to French people and therefore their whole construct without real interest. However, we (project.FRA people) permitted the IDNA2008 consensus, because it was the correct building block on the Internet side, and it was up to us to work orthotypography support on the User side. (This actually leads to a full revamp of the Internet Use (IUse) vision, we cannot only introduce and document, but we first have to test, hence to develop). So, either this G/VIP work can be friendly to us, the Internet users, in being innovative and open minded helping all of us to develop the continuation of IDNA2008 in the spirit of RFC 5895, or it wants to be a technical protection of the sole ICANN $ 185.000 IDNgTLDs. Then all of us we have a problem of networking compatibility. That Google+ will address as planned without the competition of a revamped ICANN RSS and of our Internet PLUS' (http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt) or other architectures' $ 0 ITLDs; that the IDNA2008/Internet technology implies, IAB RFC 6055 introduces and anyone can reasonably deploy in reading the Internet RFC in with an holistic approach. >How would one determine this? People decide. >What authority would one depend on? People,an authority many professionnals in many trades (ex. merchandising, advertising, politics, etc.) have learn to deal/relate with. >And how is this to be determined algorithmically? This is not. Or not mathematically, perhaps semantically, but I doubt we have reached that scientific level as yet. However, you may want to consider Chaitin's Matabiology ? >Moreover, given that the tradition in the DNS runs >exactly counter to this -- traditionally, the labels "color" and >"colour" are simply different labels, period -- what justification is >there for including this type of similarity in the work of the teams? For many NSP.HSS color and colour are equivalent. For your x86 they are not. The work we want to achieve here, as Internet Users, is to get that type of similarity supported. If possible in the same way everywhere (i.e. not only in using the Internet, but through out the whole digital ecosystem). This is this simplicty we want, this is this simplicty the Internet MUST be built upon (RFC 3439), this is this simplicity we will necessarily get. If we work on it together we will go faster. This is what Vint Cerf intented when he wanted ICANN to host the post-IDNA2008 work. So, ICANN hosts it. Great it may help : for that the target is to be openess and not constraints, i.e. to be constrained by pre-existing ideas, limitations, habits, etc. >The case of two strings that have the same meaning when treated as >words in some language, however, _does_ have a precedent: we treat >them as different labels. I want to know why that tradition should >be thrown over when we introduce some new code points. 1) because ICANN wishes so and hosts this VIP discussion? 2) because ITLD registrants whish it? 3) because people are not interested in DNS precedents, but in their single personal simplicity convenience ? 4) because not everyone speak English and yet want to say equivalent things? Best ! Thx. jfc From jefsey@jefsey.com Tue Jul 26 01:14:06 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53ED21F8C19; Tue, 26 Jul 2011 01:14:06 -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 E4 hex): To: Patrik F\344ltstr\366m ) id 1Qlcm9-00075R-AP; Tue, 26 Jul 2011 01:14:01 -0700 Message-Id: <7.0.1.0.2.20110726100451.055aac98@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 26 Jul 2011 10:14:32 +0200 To: Patrik Fältström ,vip@icann.org From: JFC Morfin In-Reply-To: <1C0C9977-F934-4E26-BF53-BC06B6BEB64F@frobbit.se> References: <4E2C83EF.1080209@Yonita.com> <4E2D381C.6050100@Yonita.com> <1C0C9977-F934-4E26-BF53-BC06B6BEB64F@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: precis@ietf.org, iucg@ietf.org Subject: Re: [iucg] [vip] Educational session on existing variant practices 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, 26 Jul 2011 08:14:06 -0000 At 09:02 26/07/2011, Patrik Fältström wrote: >On 26 jul 2011, at 08.55, Patrik Fältström wrote: > > > On 25 jul 2011, at 11.32, Andrzej Bartosiewicz wrote: > > > >> I have no problmem with "æ" and "ae" > > > > I do, they are two different things if you are a Swedish speaking. > > > > "æ" and "ä" on the other hand should be treated as the same. > > > > Which is something completely different than "lookalike" of course. > > > > Just to show the confusion. > >Let me add an explanation to the above. > >In English the "æ" is a ligature, and in some more languages. It is >a separate letter and *not* a ligature in the Scandinavian languages >that uses it. > >So whether something is a ligature, and because of that what is "the >same" is context dependent. > > Patrik In such a case, the solution seems to be to use a table where the visual geometric symbol æ can be freely used by people along their own orthotypography of their own language without caring about the ways other languages, cultures, typographies, orthotypographies. Either it is possible to bridge such a graphcode with unicode and we have to do it, or it is not and here is the problem we (VIP, PRECIS, IUCG, ...) have to address. Best jfc From jefsey@jefsey.com Tue Jul 26 03:36:10 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5C121F8A1A for ; Tue, 26 Jul 2011 03:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=1.601, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGXfr-jXYRNm for ; Tue, 26 Jul 2011 03:36:09 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 441D721F8866 for ; Tue, 26 Jul 2011 03:36:09 -0700 (PDT) Received: from 162.187-227-89.dsl.completel.net ([89.227.187.162]:64229 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QlezP-0002td-J0; Tue, 26 Jul 2011 03:35:52 -0700 Message-Id: <7.0.1.0.2.20110726112705.055ab448@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 26 Jul 2011 12:35:52 +0200 To: Daniel Kalchev ,vip@icann.org From: JFC Morfin In-Reply-To: <4E2E7B82.7080706@digsys.bg> References: <4E2C83EF.1080209@Yonita.com> <4E2D381C.6050100@Yonita.com> <1C0C9977-F934-4E26-BF53-BC06B6BEB64F@frobbit.se> <7.0.1.0.2.20110726100451.055aac98@jefsey.com> <4E2E7B82.7080706@digsys.bg> 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: iucg@ietf.org Subject: Re: [iucg] [vip] Educational session on existing variant practices 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, 26 Jul 2011 10:36:10 -0000 Daniel, we obviouly agree. However, this agreement IS _the_ problem we meet, because: 1. it concerns a much more general area than ICANN and the Internet. Actually the entire digital ecosystem. The only place I can imagine it belongs to is a multilingualisation oriented ISO 3166-4. I made called a meeting a few years ago between ISO 3166/MA, ISO/CS (HQ), AFNOR (French standards) who managed ISO/TC46 the ISO 3166/MA belongs to, BSI (British Standards) who managed ISO/TC37 responsible for ISO 639 (names of languages), ICANN (they were two to come to Paris) and me. The point was that the BSI was introducing an ISO 3166-4 NWIP (new work intemproposition) that would have "Anglo-saxonICANNized" the digital ecosystem. As a Something I obviously opposed. It resulted in an international vote concerning this proposition. It was only actively supported by ... UK, Ireland and after the limit date, ANSI (USA) and therefore failed. Since the same persons are still involed who pushed out David Dalby the initiator of ISO 639-6 the needed counterpart of ISO 3166-1 to form a stable 3166-4 document, ISO is probably still not the place for 3166-4. So, I reserved 3166-4.org for the IUCG to host that work. To prepare such a document I introduced the ccTAG concept: http://tools.ietf.org/html/draft-mltf-jfcm-cctags-00. In line with the ISO 3166-1:2006 which introduced the basis for multilinguisation in norms and standards, lead to my IDNA2008 position and consensus, and should lead to the core of the Intersem (Semiotic and semantic Internet) I try to pioneer. 2. Eventually, our agreement will have to technically support in the simplest and broadest way (RFC 3439) a common digital basis for every subsidiary use oriented further development. IMHO, if we do not consider these two points in strict parallel, we will fail. Best jfc At 10:32 26/07/2011, Daniel Kalchev wrote: >On 26.07.11 11:14, JFC Morfin wrote: >>>In English the "æ" is a ligature, and in some more languages. It >>>is a separate letter and *not* a ligature in the Scandinavian >>>languages that uses it. >>> >>>So whether something is a ligature, and because of that what is >>>"the same" is context dependent. >>> >>> Patrik >> >> >>In such a case, the solution seems to be to use a table where the >>visual geometric symbol æ can be freely used by people along their >>own orthotypography of their own language without caring about the >>ways other languages, cultures, typographies, orthotypographies. >>Either it is possible to bridge such a graphcode with unicode and >>we have to do it, or it is not and here is the problem we (VIP, >>PRECIS, IUCG, ...) have to address. > >First, let's agree that we discuss variants not because of computers >(DNS, as such), but because of humans. >It is humans that can declare something to be a variant or not. For >computers and DNS in particular it is all different and computers >and DNS, do not have any problem to resolve here. > >When we consider the way humans read, we need to consider the fact >that humans do not match characters in a (Unicode? ;) table, but >rather interpret what they see and switch context. If the majority >of the text is Cyrillic, as indicated by the presence of unique >Cyrillic-(only/mostly) characters, then the human considers that >text 'Cyrillic' and the letter 'a' is therefore Cyrillic Small >Letter A, and not Latin Small Letter A -- however identical those >might look. Same for Greek and even much easier for the Arabic/Chinese scripts. > >One common argument that pops up in such discussions is that 'most >of the world uses ASCII already' -- but let me remind the saying "It >all looks Greek to me" (or "Graecum est; non legitur"). In the not >so distant future, DNS will not be ASCII-mostly anymore. We need to >base our work on that assumption, or it will be obsolete in just few years. > >Daniel > > From jefsey@jefsey.com Tue Jul 26 16:12:44 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE44021F87C9 for ; Tue, 26 Jul 2011 16:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.483 X-Spam-Level: X-Spam-Status: No, score=-101.483 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w0NM+KpQlzh for ; Tue, 26 Jul 2011 16:12:44 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 62C9321F87C7 for ; Tue, 26 Jul 2011 16:12:44 -0700 (PDT) Received: from 162.187-227-89.dsl.completel.net ([89.227.187.162]:64914 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QlqnV-0004CM-2b; Tue, 26 Jul 2011 16:12:21 -0700 Message-Id: <7.0.1.0.2.20110727002912.055ab6d8@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 27 Jul 2011 01:12:51 +0200 To: Joseph Yee , Giovanni Seppia From: JFC Morfin In-Reply-To: References: <20110725215540.GA1878@shinkuro.com> <000601cc4b1e$57944a60$06bcdf20$@mobiry.com> <20110725233019.GK1878@shinkuro.com> <4E2E73E1.2080901@digsys.bg> <6B046E3B-CBE6-43A5-B4FA-7BFBD7A89240@eurid.eu> 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, iucg@ietf.org Subject: Re: [iucg] [vip] Types of variants: do we have consensus? 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, 26 Jul 2011 23:12:44 -0000 >or swappable in each script? and in each language? and under Unicode? 1. could you please elaborate on what you mean by changeable? 2. I do think our job is to techncally build support to ideas, respond to questions. Not to discuss their pertinence. Best jfc From jmabdp@gmail.com Wed Jul 27 01:39:11 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E6C21F8BD6 for ; Wed, 27 Jul 2011 01:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuWp0kR1BQ3X for ; Wed, 27 Jul 2011 01:39:10 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05CAA21F858D for ; Wed, 27 Jul 2011 01:39:09 -0700 (PDT) Received: by gxk19 with SMTP id 19so1052738gxk.31 for ; Wed, 27 Jul 2011 01:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d6eNRfYkLaenb/JHGO1SuQQh57VXjZRQJf2YvCqTlMM=; b=uYqqHn1GvTVCHHbeyDxb42iaMzMwx/1Jaxx8UR8MGrCajk4kEVb1WA9kQfG9F/KMvR 59P9EwJ9Oc0TEkps7BAtmug2Q5B9te+QH/bi7hilxii6iw2fmp/GuVGF8W6+yu/77kNN i5yQIUyNsBebVy1huO3jk5r9Vg5676uNqDOf8= MIME-Version: 1.0 Received: by 10.236.78.105 with SMTP id f69mr6561459yhe.156.1311755949574; Wed, 27 Jul 2011 01:39:09 -0700 (PDT) Received: by 10.236.108.2 with HTTP; Wed, 27 Jul 2011 01:39:09 -0700 (PDT) In-Reply-To: <7.0.1.0.2.20110727002912.055ab6d8@jefsey.com> References: <20110725215540.GA1878@shinkuro.com> <000601cc4b1e$57944a60$06bcdf20$@mobiry.com> <20110725233019.GK1878@shinkuro.com> <4E2E73E1.2080901@digsys.bg> <6B046E3B-CBE6-43A5-B4FA-7BFBD7A89240@eurid.eu> <7.0.1.0.2.20110727002912.055ab6d8@jefsey.com> Date: Wed, 27 Jul 2011 10:39:09 +0200 Message-ID: From: jean-michel bernier de portzamparc To: internet users contributing group Content-Type: multipart/alternative; boundary=20cf300fae31680b5f04a908fb8b Cc: Joseph Yee , Giovanni Seppia , vip@icann.org Subject: Re: [iucg] [vip] Types of variants: do we have consensus? 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, 27 Jul 2011 08:39:11 -0000 --20cf300fae31680b5f04a908fb8b Content-Type: text/plain; charset=ISO-8859-1 Jefsey, I read your mails and compare them with our discussions. What I feel is that we progressively switch to and from the three forms of comparison, we call semantical (sense) as opposed to mathematical (one character at a time) and physical (same external form). This is a plex. It meshes domain name, variants, phishing, meanings, sounds, feelings, perceptions, etc. This is human communication vs. machine communications. We therefore need to address it as a plex, metasimplify it and find its apex of simplicity. I think that clarifying what "string" means in the three types of comparisons would help a lot. Physical : same frequency Mathematical : same components Semantical : same what? A way to address this point would be to look for another word than "string" that would lead people to identify the differences with a mathematical string in terms of comparison. Also, to decide if their comparison is correspondence, equivalence or coherence. This way we can use the principle of correspondence to check where we are. Portzamparc 2011/7/27 JFC Morfin > > or swappable in each script? and in each language? and under Unicode? >> > > 1. could you please elaborate on what you mean by changeable? > 2. I do think our job is to techncally build support to ideas, respond to > questions. Not to discuss their pertinence. > Best > > jfc > > ______________________________**_________________ > iucg mailing list > iucg@ietf.org > https://www.ietf.org/mailman/**listinfo/iucg > --20cf300fae31680b5f04a908fb8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jefsey,

I read your mails and compare them with our discussions. Wha= t I feel is that we progressively switch to and from the three forms of com= parison,=A0 we call=A0 semantical (sense) as opposed to mathematical (one c= haracter at a time) and physical (same external form).

This is a plex. It meshes domain name, variants, phishing, meanings, so= unds, feelings, perceptions, etc. This is human communication vs. machine c= ommunications. We therefore need to address it as a plex, metasimplify it a= nd find its apex of simplicity. I think that clarifying what "string&q= uot; means in the three types of comparisons would help a lot.

Physical : same frequency
Mathematical : same components
Semantic= al : same what?

A way to address this point would be to look for an= other word than "string" that would lead people to identify the d= ifferences with a mathematical string in terms of comparison. Also, to deci= de if their comparison is correspondence, equivalence or coherence. This wa= y we can use the principle of correspondence to check where we are.

Portzamparc



2011/7/27 JFC Mor= fin <jefsey@jefse= y.com>

or swappable in each script? and in each language? and under Unicode?

1. could you please elaborate on what you mean by changeable?
2. I do think our job is to techncally build support to ideas, respond =A0t= o questions. Not to discuss their pertinence.
Best

jfc

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

--20cf300fae31680b5f04a908fb8b-- From jefsey@jefsey.com Thu Jul 28 22:26:49 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD40621F87AF; Thu, 28 Jul 2011 22:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.723 X-Spam-Level: X-Spam-Status: No, score=-101.723 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8fjJTcG06Ot; Thu, 28 Jul 2011 22:26:48 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 41D6B21F8794; Thu, 28 Jul 2011 22:26:48 -0700 (PDT) Received: from 162.187-227-89.dsl.completel.net ([89.227.187.162]:54410 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qmfav-0002r6-6o; Thu, 28 Jul 2011 22:26:46 -0700 Message-Id: <7.0.1.0.2.20110727122404.06a73278@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 29 Jul 2011 07:27:27 +0200 To: internet users contributing group From: JFC Morfin In-Reply-To: References: <20110725215540.GA1878@shinkuro.com> <000601cc4b1e$57944a60$06bcdf20$@mobiry.com> <20110725233019.GK1878@shinkuro.com> <4E2E73E1.2080901@digsys.bg> <6B046E3B-CBE6-43A5-B4FA-7BFBD7A89240@eurid.eu> <7.0.1.0.2.20110727002912.055ab6d8@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: Joseph Yee , Giovanni Seppia , precis@ietf.org, "idna-update@alvestrand.no work" , vip@icann.org Subject: [iucg] Internet User review: IDNA2008 follow-up at IETF/PRECIS and ICANN/VIP 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, 29 Jul 2011 05:26:49 -0000 Jean-Michel, I agree with you. However, things are not that simple. Andrew Sullivan asked for an algorithm and he is right: machines and systems need algorithms. What you emphasize is that in our cases (Variants, Stringprep replacement, IDNA support on the user side, extended services naming, IUsers' expectations, etc.) the algorithmic nature is just as precise as the mathematical algorithm that Andrew expects, but it obeys an entirely different logic because it also involves a brain to brain level. We have the tool (fringe to fringe as permitted by IDNA2008 and exemplified in RFC 5895) to support it but we first have to understand and document this logic. Therefore, we first need to get everyone who shares this burden to accept that their approach is to be shared with others and to understand that their logic and the logic of the others will help, but that the final logic cannot be a common logic. It is a new logic to we have to explore in common. Their experience and the experience of the others are needed but the case that we have to address is totally new. That case first needs to be understood. IPv6 is to give everyone millions of sub addresses (we call them IDv6, IIDs that are globally addressable). People will from then on allocate one, or several, thousand domain names to themselves, in the same way that they used to have an address, a name, a nickname, a mobile directory of addresses, TV channels, file names, etc. Therefore, we are talking of a world digital ecosystem naming intrastructure of hundreds of billions of domain names plus mail names, login ID, passwords, keys, codes, etc. In addition, we the users want this to be simple, sure, and secure for everyone in every language and every orthotypography (an orthotypographic requirement that IDNA2008 adequately refused to include in the network side in refusing mapping and ICANN calls "variants" on the user side). Compared to this, IDNA2008 was a _very_ simple thing to achieve. Now, you have summarized your vision of the VIP, WG/PRECIS, IAB, and IUCG problem in a metaductive manner. IMHO, this is correct. Metaduction is the proper and only way to address a problem of this size and complexity as a way to think in networks. However, metaduction is a way of thinking that everybody partly uses all the time but that is still only explored as such, at least in the way you use it, within our ALFA (Architecture Libre/Free Architecture) research framework. Some have emphasized that there was a deep need for a common glossary. Yes! However, the target is not only to use the same glossary, but also to have a common understanding of the ways of thinking of the concerned parties (engineers, operators, users). Therefore, let me explain it and translate what you mean to others, then analyze what you state and what it might imply in order to address these groups' needs, as they result from our IDNA2008 final consensus. At 10:39 27/07/2011, jean-michel bernier de portzamparc wrote: >Jefsey, > >I read your mails and compare them with our discussions. What I feel >is that we progressively switch to and from the three forms of >comparison, we call semantical (sense) as opposed to mathematical >(one character at a time) and physical (same external form). These three types belong to what we are exploring as "intelligent thinking" in order to address complexity, as an alternative to Edgar Morin's "complex thinking". Complex means woven, (complexus: canvas in Latin), like the web. Intelligent thinking is based on the idea that there are three(+one) levels of intelligence: 1. physical, like the Internet lines and nodes, 2. logical/mathematical, like the protocols, 3.1. semantical, like the meaning of what is exchanged. 3.2 pragmatical, like a paradigm (everyone thinks the same): This corresponds to : 1. "to be in good intelligence with" and interlinks, 2. "intelligence" (as in the CIA) as information and command of the hyperlinks, 3.1. be intelligent, i.e. to be able to adequately use that information in modeling (comprehending) it and observing/emulating the model behavior. 3.2. the same but when instead of considering a single semantic processors one considers a semantic processor network: a crowd, country, culture, community, etc. Here, the reasoning cannot be classical deduction, induction, abduction,or even hypothetico-deduction. We call it metaduction. It consists in building a brain vision, a mental map of what we understand. We call it an ontography (because 50% of the brain uses vision related functions, e.g. "theory" means an observation, we refer to our "points of view", etc.). The legend of this "map" is an ontology. Then, the metaductive reasoning consists in observing the mental map and progressing through it. This is truly mentally walking a theory. One, therefore, understands that metaduction extensively uses contextual models, and that being dependent on models makes it totally dependent on context, i.e. on the adjacencies that define a context (or in IDNA2008 terms and thinking environment: "joiners" and "CONTEXTO"). As a consequence, when - physical logic is built on correspondence - and mathematical logic is built on equivalence - then semantical logic is built on coherence - and pragmatical logic is, in addition, dependent on internal consistency. (note: pragmatic is semantic in a context, i.e. considering the influence/interference of a given relational space and therefore of its referent [an exemple of referent is the IANA, which up to now was unique, however the Internet technology defines one IANA per DNS class]). Communications are about exchanging (uttering/understanding) our "maps" with others. Our first needs are, therefore, to name, locate, protect, and access our "maps" in a simple, sure, and secure manner. This is what WG/PRECIS and ICANN/VIP attempt to do. This is a part of the IDNA2008 consequences that I proposed to discuss two years ago and that led me to appeal the IAB against the IESG's lack of warning about the consequences of IDNA2008 when publishing the RFC set. Let me remind you here that the outcome of these appeals was extremely positive as they identified that this issue extended far outside the area of responsibility of the IETF since it concerns the whole digital ecosystem, even though IDNA2008 bluntly reminded us about the true, very larger extent of the Internet architecture. In this digital ecosystem, the Internet legacy proposition/contribution does: - name in using domain names, login, etc., - locate in using IP addresses, - protect in encrypting, - access in using keywords, etc. - deal with transmitting datagrams as efficiently as possible (this is end to end connectivity) - want that "Everything else should be done at the fringes" (RFC 1958: Architectural Principles of the Internet). IDNA2008 has clarified what, in diversity support, is: - at the end to end (protocol) level (RFC set) - and at a fringe to fringe intelligent level that the IETF never documented before. This is why the RFC 5895, which permitted our IDNA2008 consensus, was published only for informational purposes. Because its matter was "unusual" for the IETF: "this document does not specify the behavior of a protocol that appears 'on the wire'. It describes an operation that is to be applied to user input in order to prepare that user input for use in an "on the network" protocol. As unusual as this may be for a document concerning Internet protocols, it is necessary to describe this operation". - and permitted this way to support what is at the brain to brain, human semantic and pragmatic level. IDNA has removed constraints on the Internet architectural support of diversity (while considering the case of the linguistic diversity), hence of complexity. In so doing, it also modified our reading of the Internet architecture: it showed that the Internet is also built on the principle of subsidiarity (in addition to the principle of constant change [RFC 1958] and of the principle of simplicity [RFC 3439: Some Internet Architectural Guidelines and Philosophy]). The consequence that we are faced with is threefold: 1. we have to adapt to IDNA2008 changes and update ourselves and the technology to the IDNA2008 unleashed opportunities. 2. we are in an open architectural context that we are not familiar with, however it only results from a full reading of the RFCs that we know as well as from a full use of the very unchanged code that we use every day. The danger is that we can consider solutions that are already provided or contradict them without noticing it. This was the case of IDNA2003. This still is the case of the IDNA concept (RFC 6055). 3. the architectural context that we call the IUI (cf. below) i.e. the Internet Use Interface on the Internet side of it, and the Intelligent Use Interface on our user side, is something that we will also intelligently use (i.e. with our same intelligence and need for simplicity, surety and security) with other technologies we should consider (mobile phones, regular mail, registries, etc.). We are not used to their standardization except common users. While implicitly simplicity, surety and security on our user side calls for an advisable unicity (RFC 1958) in the coherence and consistency of the proposed solutions. This should be helped by the use of the same IDNA2008 on the Internet side and our demand of a single follow-up on this Internet side: this is why, as users, we wish for the same common liaison and work between the "sons of IDNA2008", like VIP, PRECIS, IUCG, and IDNABis experience, etc. >This is a plex. Yes. A plex is a network of ideas. This is the very nature of complexity. A plex is a plex of a plex etc. We observe that metaduction, as introduced above, is not about reducing complexity into small simpler problems (rationalism) because one loses the influence of the complexity (the whole is more than the addition of its parts because parts lose the whole when being split from other parts). Metaduction is about looking at confusion as a whole, to progressively map it, to study the map when looking for its apices (plural of apex) of complication and simplicity, i.e. what seems to be the most difficult to understand and what seems to be the simplest to do to clarify things. This is a pure application of RFC 3439: in very large systems one must apply the principle of simplicity. > It meshes domain name, variants, phishing, meanings, sounds, > feelings, perceptions, etc. This is human communication vs. machine > communications. Object communications - as we know them, are based upon geometric correspondence: translation, forgetting the size or not. Machine communications - as we know them, are based upon the mathematical comparison function: equivalence, equality, if then else. Human communications - want to use machines acting as peripheral simplificators (operators of complexity simplification) are based upon the semantical comparison function: coherence - or on its pragmatic similitude. IDNA2008 has established an interface between these three forms of communications in the way that it establishes the relation between the Internet and applications, which in turn need an interface with the Internet. This middleware is what permits us, the users, to use the Internet in the way we want. This middleware will also be present when we deal with any other digitized communications technology this is why we used to call it the Intelligent Use Interface (IUI) and have started exploring it in parallel to IDNA2008. >We therefore need to address it as a plex, metasimplify it and find >its apex of simplicity. Yes. This is the process that I introduced above. However, metaduction is not the way the IETF, ICANN, etc. think. This was acknowledged by ICANN in a very interesting fundamental document named ICP-3. http://www.icann.org/en/icp/icp-3.htm. It states that the Internet community proceeds through experimentation. Therefore, ICANN called for community experimentation. This was in 2001.. It seems that we were alone in carrying it out. Except for Google, which by its size can do something equivalent at any time with http://code.google.com/intl/fr/speed/public-dns/ their Public DNS. We do not discuss an alternative root or so on, or the extension of the root. We are speaking about a full true implementation of the DNS itself, the way it is documented and in the light IDNA2008 unconstrains it. . > I think that clarifying what "string" means in the three types of > comparisons would help a lot. > >Physical : same frequency >Mathematical : same components >Semantical : same what? You have to also consider the Pragmatic alternative to Semantic; There are community side effects in what is discussed. A "Variant" as per VIP could be what is related to Pragmatic. The term could be used. >A way to address this point would be to look for another word than >"string" that would lead people to identify the differences with a >mathematical string in terms of comparison. You have to also consider the Pragmatic alternative to Semantic; There are community side effects in what is discussed. A "Variant" as per VIP could be what is related to Pragmatic. The term could be used. And we could define it along similitude grades depending on contexts A way to address this point would be to look for a word other than "string" that would lead people to identify the differences with a mathematical string in terms of comparison. >Also, to decide if their comparison is correspondence, equivalence >or coherence. This makes sense. This is a common approach to start with more appropriated and identified definitions. It is also to decide if their comparison is correspondence, equivalence, or coherence. Or rather acceptance in the pragmatic case. >This way we can use the principle of correspondence to check where we are. The principle of correspondence states that innovation in science must not only explain new aspects but also keep explaining these that were already explained. This is the IDNA prerequisite and what IDNA2008 guaranteed: the DNS as we know it and it is deployed millions of times, operational protocols, and users' satisfaction MUST not be affected. Thank you. Now we have to agree upon a new word to qualify a "smart string" if a "dumb string" is something we cannot read (spell) but only see. This means that: - a "dumb string" (symbol) supports a signal - a "string" supports content - a "smart string" to supports a thought. I would propose using "sememe", with a coherence seme by seme: http://en.wikipedia.org/wiki/Seme_%28semantics%29. - a "local smart string" to support a relational space's accepted "pragmeme" between a "pract" and an "allopract" (cf.pragmatician experts). Let me be clear, if we accept that: The last two propositions cannot be processed by a machine in a way that an RFC can describe, but an RFC can describe a common procedure and the guidelines for such a process to be carried by common agreement. We have a good example in the way Unicode code-points are worked out, langtag tables are built, ccTLDs are defined, etc. I suggest that we work on this and add these definitions to our glossary. Then, I think we should start from Marc Blanchet's Draft http://www.ietf.org/id/draft-blanchet-precis-framework-02.txt and discuss if a graphcode approach could address his requirements. Note: I use the concept of "graphcode" for a stringprep replacing algorithm made of a table of character graphical symbols for every existing script: one (phishing proof) symbol per geometric form. Each graph-point corresponds to a number of "in-code-points", and to one single "out-code-point" per orthotypography. This is a pragmatic equivalent of RFC 5892, i.e. the algorithm is not processed by a computer program but by a multibrain consensus. Then, the resulting code-graph (equivalent to code-point in a graphcode) system could be implemented for a test at one of the layers of the ML-DNS. Note: The ML-DNS is an IDNA2008 conformant encapsulation of the DNS that we are exploring (testing is to be carried before being documented), to process a naming pile that is able to address the people's final needs. This pile is the pile of the variants of the same name in various classes and presentations, e.g. A-label, U-label, UDN (user actual entry), etc. A major difference with the IDNA context is that the ML-DNS supports a single "IDNApplication service" per machine (single resolution source). However, frankly, my first and main concern is that your approach confirms that these three (VIP, PRECIS, and IUCG) groups are working on things very similar and quite intricate. They do need to relate in a way or another. At least, as the users of their deliverables, we need to ensure that they do. The work that they are engaged in is revamping Shannon's communications theory in a multilingual human context. It is worth some consideration. jfc From jfc@morfin.org Thu Jul 28 22:29:02 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBD421F8853 for ; Thu, 28 Jul 2011 22:29:02 -0700 (PDT) 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: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_92=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+BpxO8zQi5W for ; Thu, 28 Jul 2011 22:29:01 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1D21F884F for ; Thu, 28 Jul 2011 22:29:01 -0700 (PDT) Received: from 162.187-227-89.dsl.completel.net ([89.227.187.162]:54442 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qmfd5-00036a-W4; Thu, 28 Jul 2011 22:29:01 -0700 Message-Id: <7.0.1.0.2.20110729072752.0e0d6a68@jefsey.com> Message-Id: <7.0.1.0.2.20110727122404.06a73278@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 29 Jul 2011 07:29:42 +0200 To: internet users contributing group From: "J-F C. Morfin" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: "idna-update@alvestrand.no work" Subject: [iucg] Internet User review: IDNA2008 follow-up at IETF/PRECIS and ICANN/VIP 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, 29 Jul 2011 05:29:02 -0000 I copy this for IDNA Update, since I cannot use my usual e-mail address there. jfc ---- Jean-Michel, I agree with you. However, things are not that simple. Andrew Sullivan asked for an algorithm and he is right: machines and systems need algorithms. What you emphasize is that in our cases (Variants, Stringprep replacement, IDNA support on the user side, extended services naming, IUsers' expectations, etc.) the algorithmic nature is just as precise as the mathematical algorithm that Andrew expects, but it obeys an entirely different logic because it also involves a brain to brain level. We have the tool (fringe to fringe as permitted by IDNA2008 and exemplified in RFC 5895) to support it but we first have to understand and document this logic. Therefore, we first need to get everyone who shares this burden to accept that their approach is to be shared with others and to understand that their logic and the logic of the others will help, but that the final logic cannot be a common logic. It is a new logic to we have to explore in common. Their experience and the experience of the others are needed but the case that we have to address is totally new. That case first needs to be understood. IPv6 is to give everyone millions of sub addresses (we call them IDv6, IIDs that are globally addressable). People will from then on allocate one, or several, thousand domain names to themselves, in the same way that they used to have an address, a name, a nickname, a mobile directory of addresses, TV channels, file names, etc. Therefore, we are talking of a world digital ecosystem naming intrastructure of hundreds of billions of domain names plus mail names, login ID, passwords, keys, codes, etc. In addition, we the users want this to be simple, sure, and secure for everyone in every language and every orthotypography (an orthotypographic requirement that IDNA2008 adequately refused to include in the network side in refusing mapping and ICANN calls "variants" on the user side). Compared to this, IDNA2008 was a _very_ simple thing to achieve. Now, you have summarized your vision of the VIP, WG/PRECIS, IAB, and IUCG problem in a metaductive manner. IMHO, this is correct. Metaduction is the proper and only way to address a problem of this size and complexity as a way to think in networks. However, metaduction is a way of thinking that everybody partly uses all the time but that is still only explored as such, at least in the way you use it, within our ALFA (Architecture Libre/Free Architecture) research framework. Some have emphasized that there was a deep need for a common glossary. Yes! However, the target is not only to use the same glossary, but also to have a common understanding of the ways of thinking of the concerned parties (engineers, operators, users). Therefore, let me explain it and translate what you mean to others, then analyze what you state and what it might imply in order to address these groups' needs, as they result from our IDNA2008 final consensus. At 10:39 27/07/2011, jean-michel bernier de portzamparc wrote: >Jefsey, > >I read your mails and compare them with our discussions. What I feel >is that we progressively switch to and from the three forms of >comparison, we call semantical (sense) as opposed to mathematical >(one character at a time) and physical (same external form). These three types belong to what we are exploring as "intelligent thinking" in order to address complexity, as an alternative to Edgar Morin's "complex thinking". Complex means woven, (complexus: canvas in Latin), like the web. Intelligent thinking is based on the idea that there are three(+one) levels of intelligence: 1. physical, like the Internet lines and nodes, 2. logical/mathematical, like the protocols, 3.1. semantical, like the meaning of what is exchanged. 3.2 pragmatical, like a paradigm (everyone thinks the same): This corresponds to : 1. "to be in good intelligence with" and interlinks, 2. "intelligence" (as in the CIA) as information and command of the hyperlinks, 3.1. be intelligent, i.e. to be able to adequately use that information in modeling (comprehending) it and observing/emulating the model behavior. 3.2. the same but when instead of considering a single semantic processors one considers a semantic processor network: a crowd, country, culture, community, etc. Here, the reasoning cannot be classical deduction, induction, abduction,or even hypothetico-deduction. We call it metaduction. It consists in building a brain vision, a mental map of what we understand. We call it an ontography (because 50% of the brain uses vision related functions, e.g. "theory" means an observation, we refer to our "points of view", etc.). The legend of this "map" is an ontology. Then, the metaductive reasoning consists in observing the mental map and progressing through it. This is truly mentally walking a theory. One, therefore, understands that metaduction extensively uses contextual models, and that being dependent on models makes it totally dependent on context, i.e. on the adjacencies that define a context (or in IDNA2008 terms and thinking environment: "joiners" and "CONTEXTO"). As a consequence, when - physical logic is built on correspondence - and mathematical logic is built on equivalence - then semantical logic is built on coherence - and pragmatical logic is, in addition, dependent on internal consistency. (note: pragmatic is semantic in a context, i.e. considering the influence/interference of a given relational space and therefore of its referent [an exemple of referent is the IANA, which up to now was unique, however the Internet technology defines one IANA per DNS class]). Communications are about exchanging (uttering/understanding) our "maps" with others. Our first needs are, therefore, to name, locate, protect, and access our "maps" in a simple, sure, and secure manner. This is what WG/PRECIS and ICANN/VIP attempt to do. This is a part of the IDNA2008 consequences that I proposed to discuss two years ago and that led me to appeal the IAB against the IESG's lack of warning about the consequences of IDNA2008 when publishing the RFC set. Let me remind you here that the outcome of these appeals was extremely positive as they identified that this issue extended far outside the area of responsibility of the IETF since it concerns the whole digital ecosystem, even though IDNA2008 bluntly reminded us about the true, very larger extent of the Internet architecture. In this digital ecosystem, the Internet legacy proposition/contribution does: - name in using domain names, login, etc., - locate in using IP addresses, - protect in encrypting, - access in using keywords, etc. - deal with transmitting datagrams as efficiently as possible (this is end to end connectivity) - want that "Everything else should be done at the fringes" (RFC 1958: Architectural Principles of the Internet). IDNA2008 has clarified what, in diversity support, is: - at the end to end (protocol) level (RFC set) - and at a fringe to fringe intelligent level that the IETF never documented before. This is why the RFC 5895, which permitted our IDNA2008 consensus, was published only for informational purposes. Because its matter was "unusual" for the IETF: "this document does not specify the behavior of a protocol that appears 'on the wire'. It describes an operation that is to be applied to user input in order to prepare that user input for use in an "on the network" protocol. As unusual as this may be for a document concerning Internet protocols, it is necessary to describe this operation". - and permitted this way to support what is at the brain to brain, human semantic and pragmatic level. IDNA has removed constraints on the Internet architectural support of diversity (while considering the case of the linguistic diversity), hence of complexity. In so doing, it also modified our reading of the Internet architecture: it showed that the Internet is also built on the principle of subsidiarity (in addition to the principle of constant change [RFC 1958] and of the principle of simplicity [RFC 3439: Some Internet Architectural Guidelines and Philosophy]). The consequence that we are faced with is threefold: 1. we have to adapt to IDNA2008 changes and update ourselves and the technology to the IDNA2008 unleashed opportunities. 2. we are in an open architectural context that we are not familiar with, however it only results from a full reading of the RFCs that we know as well as from a full use of the very unchanged code that we use every day. The danger is that we can consider solutions that are already provided or contradict them without noticing it. This was the case of IDNA2003. This still is the case of the IDNA concept (RFC 6055). 3. the architectural context that we call the IUI (cf. below) i.e. the Internet Use Interface on the Internet side of it, and the Intelligent Use Interface on our user side, is something that we will also intelligently use (i.e. with our same intelligence and need for simplicity, surety and security) with other technologies we should consider (mobile phones, regular mail, registries, etc.). We are not used to their standardization except common users. While implicitly simplicity, surety and security on our user side calls for an advisable unicity (RFC 1958) in the coherence and consistency of the proposed solutions. This should be helped by the use of the same IDNA2008 on the Internet side and our demand of a single follow-up on this Internet side: this is why, as users, we wish for the same common liaison and work between the "sons of IDNA2008", like VIP, PRECIS, IUCG, and IDNABis experience, etc. >This is a plex. Yes. A plex is a network of ideas. This is the very nature of complexity. A plex is a plex of a plex etc. We observe that metaduction, as introduced above, is not about reducing complexity into small simpler problems (rationalism) because one loses the influence of the complexity (the whole is more than the addition of its parts because parts lose the whole when being split from other parts). Metaduction is about looking at confusion as a whole, to progressively map it, to study the map when looking for its apices (plural of apex) of complication and simplicity, i.e. what seems to be the most difficult to understand and what seems to be the simplest to do to clarify things. This is a pure application of RFC 3439: in very large systems one must apply the principle of simplicity. > It meshes domain name, variants, phishing, meanings, sounds, > feelings, perceptions, etc. This is human communication vs. machine > communications. Object communications - as we know them, are based upon geometric correspondence: translation, forgetting the size or not. Machine communications - as we know them, are based upon the mathematical comparison function: equivalence, equality, if then else. Human communications - want to use machines acting as peripheral simplificators (operators of complexity simplification) are based upon the semantical comparison function: coherence - or on its pragmatic similitude. IDNA2008 has established an interface between these three forms of communications in the way that it establishes the relation between the Internet and applications, which in turn need an interface with the Internet. This middleware is what permits us, the users, to use the Internet in the way we want. This middleware will also be present when we deal with any other digitized communications technology this is why we used to call it the Intelligent Use Interface (IUI) and have started exploring it in parallel to IDNA2008. >We therefore need to address it as a plex, metasimplify it and find >its apex of simplicity. Yes. This is the process that I introduced above. However, metaduction is not the way the IETF, ICANN, etc. think. This was acknowledged by ICANN in a very interesting fundamental document named ICP-3. http://www.icann.org/en/icp/icp-3.htm. It states that the Internet community proceeds through experimentation. Therefore, ICANN called for community experimentation. This was in 2001.. It seems that we were alone in carrying it out. Except for Google, which by its size can do something equivalent at any time with http://code.google.com/intl/fr/speed/public-dns/ their Public DNS. We do not discuss an alternative root or so on, or the extension of the root. We are speaking about a full true implementation of the DNS itself, the way it is documented and in the light IDNA2008 unconstrains it. . > I think that clarifying what "string" means in the three types of > comparisons would help a lot. > >Physical : same frequency >Mathematical : same components >Semantical : same what? You have to also consider the Pragmatic alternative to Semantic; There are community side effects in what is discussed. A "Variant" as per VIP could be what is related to Pragmatic. The term could be used. >A way to address this point would be to look for another word than >"string" that would lead people to identify the differences with a >mathematical string in terms of comparison. You have to also consider the Pragmatic alternative to Semantic; There are community side effects in what is discussed. A "Variant" as per VIP could be what is related to Pragmatic. The term could be used. And we could define it along similitude grades depending on contexts A way to address this point would be to look for a word other than "string" that would lead people to identify the differences with a mathematical string in terms of comparison. >Also, to decide if their comparison is correspondence, equivalence >or coherence. This makes sense. This is a common approach to start with more appropriated and identified definitions. It is also to decide if their comparison is correspondence, equivalence, or coherence. Or rather acceptance in the pragmatic case. >This way we can use the principle of correspondence to check where we are. The principle of correspondence states that innovation in science must not only explain new aspects but also keep explaining these that were already explained. This is the IDNA prerequisite and what IDNA2008 guaranteed: the DNS as we know it and it is deployed millions of times, operational protocols, and users' satisfaction MUST not be affected. Thank you. Now we have to agree upon a new word to qualify a "smart string" if a "dumb string" is something we cannot read (spell) but only see. This means that: - a "dumb string" (symbol) supports a signal - a "string" supports content - a "smart string" to supports a thought. I would propose using "sememe", with a coherence seme by seme: http://en.wikipedia.org/wiki/Seme_%28semantics%29. - a "local smart string" to support a relational space's accepted "pragmeme" between a "pract" and an "allopract" (cf.pragmatician experts). Let me be clear, if we accept that: The last two propositions cannot be processed by a machine in a way that an RFC can describe, but an RFC can describe a common procedure and the guidelines for such a process to be carried by common agreement. We have a good example in the way Unicode code-points are worked out, langtag tables are built, ccTLDs are defined, etc. I suggest that we work on this and add these definitions to our glossary. Then, I think we should start from Marc Blanchet's Draft http://www.ietf.org/id/draft-blanchet-precis-framework-02.txt and discuss if a graphcode approach could address his requirements. Note: I use the concept of "graphcode" for a stringprep replacing algorithm made of a table of character graphical symbols for every existing script: one (phishing proof) symbol per geometric form. Each graph-point corresponds to a number of "in-code-points", and to one single "out-code-point" per orthotypography. This is a pragmatic equivalent of RFC 5892, i.e. the algorithm is not processed by a computer program but by a multibrain consensus. Then, the resulting code-graph (equivalent to code-point in a graphcode) system could be implemented for a test at one of the layers of the ML-DNS. Note: The ML-DNS is an IDNA2008 conformant encapsulation of the DNS that we are exploring (testing is to be carried before being documented), to process a naming pile that is able to address the people's final needs. This pile is the pile of the variants of the same name in various classes and presentations, e.g. A-label, U-label, UDN (user actual entry), etc. A major difference with the IDNA context is that the ML-DNS supports a single "IDNApplication service" per machine (single resolution source). However, frankly, my first and main concern is that your approach confirms that these three (VIP, PRECIS, and IUCG) groups are working on things very similar and quite intricate. They do need to relate in a way or another. At least, as the users of their deliverables, we need to ensure that they do. The work that they are engaged in is revamping Shannon's communications theory in a multilingual human context. It is worth some consideration. jfc