From jefsey@jefsey.com Fri Sep 2 16:01:48 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 1D38A21F8B3A for ; Fri, 2 Sep 2011 16:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.736 X-Spam-Level: X-Spam-Status: No, score=-101.736 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9tJADJV1CIa for ; Fri, 2 Sep 2011 16:01:47 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1947221F8B2A for ; Fri, 2 Sep 2011 16:01:47 -0700 (PDT) Received: from 213.140-227-89.dsl.completel.net ([89.227.140.213]:53078 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qzcld-0008Ho-Cd; Fri, 02 Sep 2011 16:03:23 -0700 Message-Id: <7.0.1.0.2.20110903004055.05a5e6e0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 03 Sep 2011 01:06:25 +0200 To: Francisco Arias , "vip@icann.org" From: JFC Morfin In-Reply-To: References: <4E565B58.5060803@alvestrand.no> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1460593056==.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: iucg@ietf.org Subject: Re: [iucg] [vip] FW: [latin-vip] Loudly spoken opinions - input for today's meeting X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 23:01:48 -0000 --=====================_1460593056==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:45 02/09/2011, Francisco Arias wrote: >I wonder what others think about the ideas in this document posted to the >latin team. Apologies to Harald for putting you in the spot. Dear Francis, I looked at Harald's contribution carefully. 1. I fully support his "DO NOT DO VARIANTS FOR LATIN SCRIPT" position when considering the issues from an internet technology point of view (i.e. IDNA2008, RFC 5890-5894). 2. However, I do not share his limitations when I consider the same issues from an IUI (Intelligent Use Interface) point of view (i.e. from what is very limitedly exemplified by RFC 5895 - a smart middle networkware between users' plug and socket - i.e. an intelligent fringe addition). The IESG has decided that the IUI was research, at least in part. The IAB made clear that it did not belong to the IETF area (it is actually multitechnology), but it is active in considering from the sole internet DNS and internet PoV some of the same issues that I am exploring in order to support them through the IUI in a universal perspective. This is why any ICANN debate or WG like this WG/VIP, IMHO, should: 2.1. refer to the IAB's RFCs and Drafts: - http://wiki.tools.ietf.org/rfc/rfc5507 - http://wiki.tools.ietf.org/rfc/rfc6055.txt - http://tools.ietf.org/id/draft-iab-dns-applications-02.txt 2.2. position ICANN in the global semiotic area. In other words: internet domain names are usually names of domains/people, more or less adapted to the internet orthotypography (i.e. the script syntax). Depending on the linguistic and semantic context, there might be an interest or a need for variants, i.e. a pragmatic equivalence between different strings. This means four main needs: - an algorithm to avoid homography. - the (partial) support of the linguistic orthotypography within the internet orthotypography. - the aliasing of certain strings. - a mechanism to prevent alias/string conflicts. 3. The mission of the IETF (as defined by Harald - RFC 3935) is to influence those who design, use, and manage the Internet (i.e. ourselves) for it to work better. I am an Internet User (IUse). We IUsers have directly opposed at the WG/IDNABis on three issues, but we were able, however, to reach the IDNA2008 consensus as these issues were positively resolved. The issues were: 3.1. the location of the support of variants (mapping) by the DNS. The Unicode/IETF people wanted a limited mapping in the IDNA technology. This broke the neutrality of the Internet and opened a Pandora's box. The charter disfavored mapping. The RFC 5895's proposed text addressed the issue. 3.2. orthotypography. I wanted IDNA2008 to acknowledge the orthotypography issue and propose a way to address it. This was not even opposed, it was outright disregarded. The problem that I brought to everyone's attention was the French (and Latin) majuscules semantic impact. IDNA2008 does not even allude to them. It was not bad that I was defeated on this point because this makes the ML-DNS mandatory (i.e. multilayer/multilingual variant support). I reported why to the IESG which accepted IDNA2008 as a result (http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt) 3.3. ICANN's role. The initial idea was that post-IDNA2008 users' issues would be addressed by ICANN. I opposed that (I have not experienced, ever, a situation when ICANN would want to represent me!), and ICANN did not indicate interest in spite of my mails to the BoD members and ICANN reps (Tina and Cary) at the WG. Therefore, the idea was forgotten. 3.4. Homographic confusion. We never were able to discuss it. The result is that the universal domain naming linguistic diversity (i.e. the designation of any intellectual, operational, industrial, commercial, physical, emotional, etc.) digital support is to be carried by external subsidiarity in a way meeting IDNA2008 rules, when the internet is involved. 4. As a result, one sees that: 4.1. syntax, semantic, pragmatic, scripting and multilinguistic issues are concerned, i.e. every semiotic ( atlarge) aspects. This belongs to what we call the Intersem (Semiotic Internet) layers. 4. 2. variants are by their essence related to users and not to the internet technology. This means that the same variants will be required by users of every technology as well as mean that they will be described, analyzed and documented with the same terminology. This means that the context will be at the end of the day: 4.2.1. either a Semiotic Digital Use Authority coordinating the cooperation of all the semiotic technology oriented endeavors and deciding about a user/digital ecosystem semiotic strategy to which everyone should adhere. 4.2.2. or each of us proceeds independently and trusts that people's use will stabilize the tools and usages. -- ICANN does it based upon IETF RFCs and its possible solutions. However, I fear ICANN has not the technological capacity to address the points it raises. -- IUsers do it based upon ICANN-ICP-3, IETF RFCs and the IUI architecture and in helping the development of a test technology. -- Without forgeting the IETF parallel needs on IRIs and protocols (WG/PRECIS). With a possible further cooperation to build a coordination? 5. What to do now? My suggestion would be that: 5.1. ICANN/VIP should expose the needs that it identifies in terms of variants from a user semiotic PoV, publishing its vision of Users' needs. It should carefully consider the IAB/IETF experience and recommendations, understanding that what the IETF cannot support (cf. Harald) would have to be supported by the ML-DNS within the IUI layers' framework. 5.2. In any case, on our IUser side, we will continue exploring the IUI architecture with plans for three research actions: 5.2.1. semiotic experimentation through Project.FRA, i.e. an open French ontology with the ".fra" TLD using its name space as a commonly drafted taxonomy. 5.2.2. consolidation, experimentation, and support of an IUI technology, including an ML-DNS and the use of the unique virtual root names matrix. 5.2.3. a documentation set of the IUI architecture based on that experimentation and a common multilingual internet terminology. We all may have our opinions, positions, pet ideas. However, I think this is really a case for the IAB to provide serious guidance or for a more global architecture to emerge for the whole digital ecosystem and being supported by an appropriatedly extended model. Best, jfc --=====================_1460593056==.ALT Content-Type: text/html; charset="us-ascii" At 07:45 02/09/2011, Francisco Arias wrote:
I wonder what others think about the ideas in this document posted to the
latin team. Apologies to Harald for putting you in the spot.

Dear Francis,

I looked at Harald's contribution carefully.

1. I fully support his "DO NOT DO VARIANTS FOR LATIN SCRIPT" position when considering the issues from an internet technology point of view (i.e. IDNA2008, RFC 5890-5894).

2. However, I do not share his limitations when I consider the same issues from an IUI (Intelligent Use Interface) point of view (i.e. from what is very limitedly exemplified by RFC 5895 - a smart middle networkware between users' plug and socket - i.e. an intelligent fringe addition).

The IESG has decided that the IUI was research, at least in part. The IAB made clear that it did not belong to the IETF area (it is actually multitechnology), but it is active in considering from the sole internet DNS and internet PoV some of the same  issues that I am exploring in order to support them through the IUI in a universal perspective.

This is why any ICANN debate or WG like this WG/VIP, IMHO, should:

2.1. refer to the IAB’s RFCs and Drafts:
      - http://wiki.tools.ietf.org/rfc/rfc5507
      - http://wiki.tools.ietf.org/rfc/rfc6055.txt
      - http://tools.ietf.org/id/draft-iab-dns-applications-02.txt

2.2. position ICANN in the global semiotic area. In other words: internet domain names are usually names of domains/people, more or less adapted to the internet orthotypography (i.e. the script syntax). Depending on the linguistic and semantic context, there might be an interest or a need for variants, i.e. a pragmatic equivalence between different strings. This means four main needs:

   - an algorithm to avoid homography.
   - the (partial) support of the linguistic orthotypography within the internet orthotypography.
   - the aliasing of certain strings.
   - a mechanism to prevent alias/string conflicts.

3. The mission of the IETF (as defined by Harald - RFC 3935) is to influence those who design, use, and manage the Internet (i.e. ourselves) for it to work better. I am an Internet User (IUse). We IUsers have directly opposed at the WG/IDNABis on three issues, but we were able, however, to reach the IDNA2008 consensus as these issues were positively resolved. The issues were:

3.1. the location of the support of variants (mapping) by the DNS. The Unicode/IETF people wanted a limited mapping in the IDNA technology. This broke the neutrality of the Internet and opened a Pandora’s box. The charter disfavored mapping. The RFC 5895's proposed text addressed the issue.

3.2. orthotypography. I wanted IDNA2008 to acknowledge the orthotypography issue and propose a way to address it. This was not even opposed, it was outright disregarded. The problem that I brought to everyone’s attention was the French (and Latin) majuscules semantic impact. IDNA2008 does not even allude to them. It was not bad that I was defeated on this point because this makes the ML-DNS mandatory  (i.e. multilayer/multilingual variant support). I reported why to the IESG which accepted IDNA2008 as a result ( http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt)

3.3. ICANN's role. The initial idea was that post-IDNA2008 users' issues would be addressed by ICANN. I opposed that (I have not experienced, ever, a situation when ICANN would want to represent me!), and ICANN did not indicate interest in spite of my mails to the BoD members and ICANN reps (Tina and Cary) at the WG. Therefore, the idea was forgotten.

3.4. Homographic confusion. We never were able to discuss it.

The result is that the universal domain naming linguistic diversity (i.e. the designation of any intellectual, operational, industrial, commercial, physical, emotional, etc.) digital support is to be carried by external subsidiarity in a way meeting IDNA2008 rules, when the internet is involved.

4. As a result, one sees that:

4.1. syntax, semantic, pragmatic, scripting  and multilinguistic issues are concerned, i.e. every semiotic  ( atlarge)  aspects. This belongs to what we call the Intersem (Semiotic Internet) layers.

4. 2. variants are by their essence related to users and not to the internet technology. This means that the same variants will be required by users of every technology as well as mean that they will be described, analyzed and documented with the same terminology.

This means that the context will be at the end of the day:

4.2.1. either a Semiotic Digital Use Authority coordinating the cooperation of all the semiotic technology oriented endeavors and deciding about a user/digital ecosystem semiotic strategy to which everyone should adhere.

4.2.2. or each of us proceeds independently and trusts that people's use will stabilize the tools and usages.

  -- ICANN does it based upon IETF RFCs and its possible solutions. However, I fear ICANN has not the technological capacity to address the points it raises.
  -- IUsers do it based upon ICANN-ICP-3, IETF RFCs and the IUI architecture and in helping the development of a test technology.
  -- Without forgeting the IETF parallel needs on IRIs and protocols (WG/PRECIS).

With a possible further cooperation to build a coordination?

5. What to do now?

My suggestion would be that:

5.1. ICANN/VIP should expose the needs that it identifies in terms of variants from a user semiotic PoV, publishing its vision of Users’ needs. It should carefully consider the IAB/IETF experience and recommendations, understanding that what the IETF cannot support (cf. Harald) would have to be supported by the ML-DNS within the IUI layers’ framework.

5.2. In any case, on our IUser side, we will continue exploring the IUI architecture with plans for three research actions:

5.2.1. semiotic experimentation through Project.FRA, i.e. an open French ontology with the ".fra" TLD using its name space as a commonly drafted taxonomy.

5.2.2. consolidation, experimentation, and support of an IUI technology, including an ML-DNS and the use of the unique virtual root names matrix.

5.2.3. a documentation set of the IUI architecture based on that experimentation and a common multilingual internet terminology.

We all may have our opinions, positions, pet ideas. However, I think this is really a case for the IAB to provide serious guidance or for a more global architecture to emerge for the whole digital ecosystem and being supported by an appropriatedly extended model.

Best,
jfc

--=====================_1460593056==.ALT-- From jefsey@jefsey.com Sat Sep 3 02:53:25 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 DC81F21F8C50 for ; Sat, 3 Sep 2011 02:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wVqkM3tPyAm for ; Sat, 3 Sep 2011 02:53:25 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA1121F8C4C for ; Sat, 3 Sep 2011 02:53:25 -0700 (PDT) Received: from 213.140-227-89.dsl.completel.net ([89.227.140.213]:53720 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QzmwG-00082F-4H; Sat, 03 Sep 2011 02:55:01 -0700 Message-Id: <7.0.1.0.2.20110903112533.05a5e828@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 03 Sep 2011 11:58:08 +0200 To: "vip@icann.org" From: JFC Morfin In-Reply-To: <58093F5E-1FF1-4293-BF3E-5C7282D7E937@frobbit.se> <0AAAC08A-52D3-4FF2-BBEC-2596336971DC@frobbit.se> References: <58093F5E-1FF1-4293-BF3E-5C7282D7E937@frobbit.se> <0AAAC08A-52D3-4FF2-BBEC-2596336971DC@frobbit.se> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1499696049==.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: iucg@ietf.org Subject: Re: [iucg] [vip] [latin-vip] Loudly spoken opinions - input for today' 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, 03 Sep 2011 09:53:26 -0000 --=====================_1499696049==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit At 09:00 03/09/2011, Patrik Fältström wrote: >One thing we also have are two words spelled the same, but >pronounced differently that means different things. >Example (in Swedish): > >kista [chi:sta] : A suburb of Stockholm, where lots of IT industry is located >kista [chista] : A coffin At 09:01 03/09/2011, Patrik Fältström wrote: >Let me also say explicitly that I support the findings in this document. In French: State = Government state = status In the roman world at least: xxxx = word Xxxx = Family name. I reviewed again the response of Harald, considering the way he and Patrik seem to understand the ICANN questionnaire as engineers, when I try to understand it as a multilinguist (multilinguistics: the cybernetics of the linguistic diversity, i.e. how languages can and will technicaly coexist, conflict, or mutually assist). I also have had some feed-backs from the IUCG controverted Glossary effort. As a result, the main questions seem to be: 1. what is a variant? 2. how does it differs from the ICANN definition of alias? 3. How ICANN does name an IETF alias? 4. How does that relate with Webster alias (": otherwise called : otherwise known as"). The difficulty here seems to be "otherwise called/known" by who? Depending on inputs, it seems that this "who" can be the registry, the protocol, the UI, the IUI, the doxa, the multilinguistic rules or algorithm, ICANN, a global semiotic authority, the TM owners, the towns, the Governments, Courts of Justice, Chambers of Commerce, Academies, etc. etc. The main source of experience on this is to be Fast Track: are there already some information from its real registrations and registrant/user comments. jfc PS. In the ICANN document I would change "concept/idea" into "concept/notion" for clarity sake. --=====================_1499696049==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit At 09:00 03/09/2011, Patrik Fältström wrote:
One thing we also have are two words spelled the same, but pronounced differently that means different things.
Example (in Swedish):

kista [chi:sta] : A suburb of Stockholm, where lots of IT industry is located
kista [chista]  : A coffin

At 09:01 03/09/2011, Patrik Fältström wrote:
Let me also say explicitly that I support the findings in this document.

In French:
State = Government
state = status

In the roman world at least:
xxxx = word
Xxxx = Family name.

I reviewed again the response of Harald, considering the way he and Patrik seem to understand the ICANN questionnaire as engineers, when I try to understand it as a multilinguist (multilinguistics: the cybernetics of the linguistic diversity, i.e. how languages can and will technicaly coexist, conflict, or mutually assist).  I also have had some feed-backs from the IUCG controverted Glossary effort.

As a result, the main questions seem to be:

1. what is a variant?
2. how does it differs from the ICANN definition of alias?
3. How ICANN does name an IETF alias?
4. How does that relate with Webster alias (": otherwise called : otherwise known as").

The difficulty here seems to be "otherwise called/known" by who?

Depending on inputs, it seems that this "who" can be the registry, the protocol, the UI, the IUI, the doxa, the multilinguistic rules or algorithm, ICANN, a global semiotic authority, the TM owners, the towns, the Governments, Courts of Justice, Chambers of Commerce, Academies, etc. etc. The main source of experience on this is to be Fast Track: are there already some information from its real registrations and registrant/user comments.

jfc

PS. In the ICANN document I would change "concept/idea" into "concept/notion" for clarity sake.


--=====================_1499696049==.ALT-- From jefsey@jefsey.com Sat Sep 3 04:06:18 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EF321F8C0D for ; Sat, 3 Sep 2011 04:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.019 X-Spam-Level: X-Spam-Status: No, score=-103.019 tagged_above=-999 required=5 tests=[AWL=1.580, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqNaht1xomJF for ; Sat, 3 Sep 2011 04:06:18 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5B73321F8BF8 for ; Sat, 3 Sep 2011 04:06:18 -0700 (PDT) Received: from 213.140-227-89.dsl.completel.net ([89.227.140.213]:53996 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qzo4l-0001eH-GT; Sat, 03 Sep 2011 04:07:52 -0700 Message-Id: <7.0.1.0.2.20110903121345.05a5e970@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 03 Sep 2011 13:10:54 +0200 To: "vip@icann.org" From: JFC Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: iucg@ietf.org Subject: [iucg] oups! 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, 03 Sep 2011 11:06:19 -0000 Please read: In French: Etat = Government état = status Upper-cases can or not wear an accent. There is no difference. In ASCII "etat" is supposed to mean both. This kind of confusion cannot be accepted due to its semantic impact. Also, please remember that in this case "E" is just a way to express (in using an upper-case) that E is a majuscule. Unicode has no other way to support the "majuscule metadata" that upper-cases: this is why I said that the lack of upper-case support by IDNA2008 (to the contrary to IDNA2003, which did not affect upper-case entries from end to end, as the DNS does not either) was not bad. It implies the mandatory use of an added middle-netware (I call the IUI and which will offer intelligence on a fringe to fringe basis, between the user's computer plug and its unchanged OS socket. cf. IAB RFC 3238 on OPES). As in some other scripts, the important thing is not to transport the same typography on an end to end basis, but to carry the same message, i.e. data + metadata, on a fringe to fringe basis. Architecturally this important because it affects the kind of technical communication stratum we consider. - In value-added datacommunication (OSI, TCP/IP) the model includes communications oriented metadata in the envelope (along the layers of that model). If there may be a need for the content to be accompanied by metadata : these metadata are conveyed by the "presentation" layer. IDNA2008 institutes the missing TCP/IP presentation layer through the rudimentary "xn--" prefix. This is rudimentary because the metadata is correctly in the header, but not directly accessible (not at a structural address). - the stratum above telecommunication (no metadata) and datacommunications (metadata in the header) is the metacommunications where metadata are sent/obtained by their own. There are therefore two ways to deliver the othotypographic "majuscule" pay-load: - either in using the domain name. We still are in the rudimentary solution, but we can improve it if this becomes a stable extended way to proceed. - or in paralleling the data delivery with a metadata delivery ("the first character of the related domain name is a majuscule"). In this case we are outside of the standard telecommunications and value-added and extended datacommunications: we have entered metacommunications. To date the Internet is not a metacommunications technology. The possible improvement to support metadata, hence to support variants, can be: - to use another presentation, in changing or extending the "xn--" header. - xm-- means that the first letter is a majuscule: - "xn--5-- means that the fifth character is a majuscule or is a figure to take into a local list of numbers - etc. - in extending the punycode syntax and introducing an escape signal. for example "état"="status" and "^état"="Etat". - in acknowledging that this leads to a change of the nature of the domain name field in the TCP/IP packet. It becomes the presentation layer support. This calls for a presentation protocol defaulting to a regular ASCII FQDN. However, this definitely belongs either to the UI in the current IDNA IAB architecture, or to the IUI in the traditional Internet architecture as IDNA2008 read it and in the multitechnology digital ecosystem. This leads to the questions: 1) how does this WG/VIP intend to see its conclusion technically supported? 2) Will ICANN publish an IDNA/ICANN stringprep/stringextract function? 3) Will it develop or specify an IUI? 4) or will it publish its findings as a multilinguistics contribution. jfc From jefsey@jefsey.com Sat Sep 3 06:27:03 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 75E5F21F8B2E for ; Sat, 3 Sep 2011 06:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.775 X-Spam-Level: X-Spam-Status: No, score=-100.775 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHiKrnFQ71+q for ; Sat, 3 Sep 2011 06:27:03 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id F0B6B21F8B2A for ; Sat, 3 Sep 2011 06:27:02 -0700 (PDT) Received: from 213.140-227-89.dsl.completel.net ([89.227.140.213]:54870 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QzqGs-0002cn-Su; Sat, 03 Sep 2011 06:28:32 -0700 Message-Id: <7.0.1.0.2.20110903133831.05a5eab8@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 03 Sep 2011 15:31:37 +0200 To: Cary Karp ,vip@icann.org From: JFC Morfin In-Reply-To: <4E620AC9.6030908@nic.museum> References: <58093F5E-1FF1-4293-BF3E-5C7282D7E937@frobbit.se> <4E620AC9.6030908@nic.museum> 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] Descriptive terminology 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, 03 Sep 2011 13:27:03 -0000 At 13:08 03/09/2011, Cary Karp wrote: >I urgently suggest that we expand our descriptive terminology with >the term "homoglyph" to designate situations such as the one used in the >Cyrillic/Latin illustration above. No! :-) Cary, I fully understand your point and I support it. But not at the price of an added confusion. Glyphs are definitely out of our scope. Characters are signs that are graphed. The way they are graphed is not an issue for computer protocols and registries. The problem we meet here is that we use Unicode/ISO 10646 which distinguish between the graphed signs on non sign, non graph related premises. ISO10646/Unicode have cons and pros. One of these cons is to introduce a confusion in the use of some signs. To address this "unisoconfusable" characters issue we need an anti-homographic canonalization algorithm. This algorithm may based on unigraph (graphic signs) or unisign (general semiotic) tables or correspondances or on any other idea you might have. In the current IUse work, we start from 63.000+ 16x16 or 16x8 bitmaps on an excel table. An immediate sort shows around 10.000 strictly unisoconfusable graphs (same bitmap). Our problem is to find a complete code point description table, fill it with bitmaps representations, work on their positionning (for exemple all of them locked in one of the four corners and centered), comparabilities from human indications, etc. and come-up with different tables corresponding to degrees of confusability and check the results from real operations experimentation. Then the confusability algorithm should be amended from the experimentation inputs. Once we have obtained this, string confusability should be added through human inputs to IANA. this is why the happiana mailing list is concerned. The resulting registry may be quite important in size (and therefore in term of traffic) and the registration/validation process will be an industry issue and probably a perpetual battle if confusables are not also displayed in a cultural appropriate manner. This method should then also be applicable to check logo confusability, etc. jfc From jefsey@jefsey.com Thu Sep 8 15:44:08 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 E15BF21F8BE7 for ; Thu, 8 Sep 2011 15:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.322 X-Spam-Level: X-Spam-Status: No, score=-101.322 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRwJM548nS4R for ; Thu, 8 Sep 2011 15:44:08 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 550B421F8BE4 for ; Thu, 8 Sep 2011 15:44:08 -0700 (PDT) Received: from 135.243-227-89.dsl.completel.net ([89.227.243.135]:57930 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1R1nM9-0004ou-0t; Thu, 08 Sep 2011 15:46:01 -0700 Message-Id: <7.0.1.0.2.20110909004300.108e0d80@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 09 Sep 2011 00:49:32 +0200 To: vip@icann.org From: JFC Morfin In-Reply-To: <20110908003308.GC37065@shinkuro.com> References: <20110908003308.GC37065@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] [rfc-editor@rfc-editor.org: BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF] X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 22:44:09 -0000 At 02:33 08/09/2011, Andrew Sullivan wrote: >Dear colleagues, > >An early draft of what became the attached RFC is referred to in our >initial definitions document for this project. It might be worth >having a look at the final RFC as you work on the draft reports. >There's a lot in there, and most of it can, I think, be helpful. > > URL: http://www.rfc-editor.org/rfc/rfc6365.txt http://iucg.org/wiki/Multilingualization_-_Glossary The IUG Multilinguization Glossary has been updated accordingly. We had been blocked in this work by copyrights PTT (pay to think) claims on terminology definitions. The ALFA generic definition of "variant", is public domain. jfc From jefsey@jefsey.com Mon Sep 12 06:20:59 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 2E8C321F8B3C for ; Mon, 12 Sep 2011 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiTWznyHd+ki for ; Mon, 12 Sep 2011 06:20:58 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5F721F8B2D for ; Mon, 12 Sep 2011 06:20:58 -0700 (PDT) Received: from 135.243-227-89.dsl.completel.net ([89.227.243.135]:51590 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1R36TK-0007Zp-BV; Mon, 12 Sep 2011 06:22:51 -0700 Message-Id: <7.0.1.0.2.20110912150616.05ba95f0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Sep 2011 15:15:09 +0200 To: Daniel Kalchev From: JFC Morfin In-Reply-To: <26B64C3C-0E35-4EF3-966B-D62E0262C6D1@digsys.bg> References: <7.0.1.0.2.20110910195223.0bfd9870@jefsey.com> <26B64C3C-0E35-4EF3-966B-D62E0262C6D1@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: "vip@icann.org" , Naela Sarras , iucg@ietf.org Subject: Re: [iucg] [vip] WHITE PAPER ON "DEFINITIONS" : YOUR COMMENTS AND FEEDBACK REQUESTED X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:20:59 -0000 At 23:12 11/09/2011, Daniel Kalchev wrote: >On Sep 10, 2011, at 20:54 , JFC Morfin wrote: > > > […] > > However, I wish we would first clearly and commonly understand > where we are and what we are currently doing before we try doing > anything else. The Internet is a communication process that aims at > permitting every human and machine to digitally relate together. As > such, it is the most complex system ever built by humans, and the > first one that has attained a universal nature. > > > > > >[good presentation of current state] Thx. >Trouble is, we have approaching deadline for this work. That means, >in my opinion that our work will be grossly incomplete. I try to update the http://iucg.org/wiki/IDNA2010_Common_Objectives (former "IDNS common targets") with the Variant Issue: I have difficulties in finding the equivalent of an IETF charter for the ICANN/VIP work. Can someone help finding it or an equivalent? >While we might restrict ourselves to root-only study on variants, we >usefulness of this work is greater in a more general context, >especially given the IDNA limitations. I do not think this work can stop. We (as humans confronted to digital systems) need to define, document and standardize our command protocols with our machines. Best jfc From jefsey@jefsey.com Mon Sep 12 11:02:18 2011 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAEA21F856B for ; Mon, 12 Sep 2011 11:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.458 X-Spam-Level: X-Spam-Status: No, score=-100.458 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_50=0.001, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt4dx82Xs-uH for ; Mon, 12 Sep 2011 11:02:18 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1521F8507 for ; Mon, 12 Sep 2011 11:02:17 -0700 (PDT) Received: from 135.243-227-89.dsl.completel.net ([89.227.243.135]:52355 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1R3A2d-00045v-3z; Mon, 12 Sep 2011 10:11:31 -0700 Message-Id: <7.0.1.0.2.20110912182516.05ba9ee8@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Sep 2011 18:57:24 +0200 To: "vip@icann.org" From: jefsey 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: "comptoir@cafedu.com" , iucg@ietf.org, maaya@funredes.org Subject: [iucg] experts X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 18:02:18 -0000 Dear all, In order to better understand the positions of the VIP Latin document to the ICANN/BoD (where there are excellent French speakers who may disagree with the conclusions) regarding the "variants" in IDNs, I tried to have look at the mailing list archives and therefore to register in the list. This seems to be reserved to the Member of the Latin VIP team. So, I google them and found the list of 11 expert members. However I am at loss to know who is a linguist and who is speaking/teaching French? Can someone help? This is important since the IETF/WG/IDNAbis shown that the French language orthotypographic support was the most complex issue for IDNs and has to be addressed on the user side (like other orthotypographic issues in other languages) making French support the best testing prototype, as representing the variant top difficulty (majuscules) while being within the ASCII range. Thank you. jfc PS. the list I got includes: Jothan Frakes, Harald Alvestrand, Andrzej Bartosiewicz, Eric Brown, Cary Karp, Nadya Morozova, Francisco Obispo, Giovanni Seppia, Will Shorter, Wil Tan, and Avri Doria. Is there anybody else I missed? ====== Cher tous, Afin de mieux comprendre les positions prises par le document du groupe Latin sur les Variantes dans les IDN devant être remis au CA de l'ICANN (où il y a d'excellents francophones qui peuvent être en désaccord avec ses conclusions) j'ai tenté de jeter un coup d'oeil sur les archives de la liste de diffusion et donc de m'y inscrire. Ceci semble réservé aux membres du "Latin VIP team". Je les ai donc googlé et j'ai trouvé une liste de 11 experts. Je suis toutefois incapable de dire qui y est un linguiste et qui y est un locuteur/professeur de français ? Quelqu'un peut-il m'aider ? Ceci est important puisque le Groupe de Travail IDNA2008 a montré que la prise en compte de l'orthotypographie française était le sujet le plus complexe à résoudre pour les "IDN" et doit être résolu du côté utilisateur (comme les autres problèmes orthotypographiques des autres langues) rendant l'abord du français le meilleur test prototype, car soulevant la pire difficulté (les majuscules) tout en étant dans la zone ASCII. Merci ! jfc PS. La liste que j'ai trouvée comprend : Jothan Frakes, Harald Alvestrand, Andrzej Bartosiewicz, Eric Brown, Cary Karp, Nadya Morozova, Francisco Obispo, Giovanni Seppia, Will Shorter, Wil Tan, and Avri Doria. Ai-je manqué quelqu'un ? From jmabdp@gmail.com Sun Sep 25 07:04:04 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 A42A221F8BA9; Sun, 25 Sep 2011 07:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4hEtkOqurHf; Sun, 25 Sep 2011 07:04:04 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C03C21F8B42; Sun, 25 Sep 2011 07:04:03 -0700 (PDT) Received: by wwf22 with SMTP id 22so3721545wwf.13 for ; Sun, 25 Sep 2011 07:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5thSj8tf/HOje9lMKvGcUKrU5u0vLnUEpKpsAAIAssk=; b=QwRvqbY69hXbFh+aTmKUuyYClL8Hwcoz2kh/CmKzceHnPIGKM17KfgrEkEFHTMXEFA x3DU7NP/+RGwdqgURcm20Lk48qvlMMCn0uK2x4ZNfRvjsTqOsKmEvCpqsjahjIvoogx+ EXtESCp3uGDGmApSmy7JWaOSlXZWcxzXULZNg= MIME-Version: 1.0 Received: by 10.227.7.27 with SMTP id b27mr4410175wbb.51.1316959602615; Sun, 25 Sep 2011 07:06:42 -0700 (PDT) Received: by 10.227.143.12 with HTTP; Sun, 25 Sep 2011 07:06:42 -0700 (PDT) Date: Sun, 25 Sep 2011 16:06:42 +0200 Message-ID: From: jean-michel bernier de portzamparc To: IETF Content-Type: multipart/alternative; boundary=002215b03ec64c277f04adc48df5 Cc: vip@icann.org, internet users contributing group , precis@ietf.org Subject: [iucg] linguistic and cultural support X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 14:04:04 -0000 --002215b03ec64c277f04adc48df5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all, We, nicknamed "JEDI"s (Jefsey disciples), have often tried to make the IETF understand and respect the implications of linguistic, cultural, political, economical diversities on protocol definition. Jefsey obtained the RFC 4645= , 4646, 4647 consensus he wanted. We also obtained the IDNA2008 consensus which was necessary to warranty the internet stability, its capacity to support any diversity by subsidiarity, and the emergence of the IUI. We still have a problem with the IETF/Unicode relations, the WG/PRECIS, the IDNA IAB work, the ICANN/VIP work on variants, extension of the punycode algorithm to support French and and the orthotypography (scripting syntax) of most of the other languages, etc. May be this quote will help some of our colleagues to understand better why the IETF is to "influence those who design, use and manage the internet" fo= r it to offer users with a better multilinguistic support. =93We live in a global world,=94... =93We have to understand that world if we =85 are going to be able to not o= nly defend this country, but to extend our relationships to others so that we can work together to defend the world that we live in.=94 =93The reality is that we have to reflect the nation we live in and we have= to reflect the world we are a part of." =93Languages are the key to understanding that world.=94... "It=92s also cr= itical to the effectiveness of current U.S. military operations." ... "If we are going to advance stability in some of the countries we are fighting in today, we have to be able to understand what motivates those countries, what motivates their people, and to understand their culture, beliefs, faiths, ideologies, hatreds and loves". =93So it is crucial to our national security to be able to have a strong language ability=94. - Leon E. Panetta (8/23/2011). US Defense Secretary. Mr. Panetta speaks on behalf of the USA, but I believe that if his understanding may be late, it is also true for every other nation. Multilinguistics, as Jefsey defined it from our IETF experience, is the cybernetics of the linguistic diversity. How languages and cultures can be adequately be supported and result in positive synergetic feed backs. Its key recipe seems to be first based upon a true network linguistic neutrality. One does not need to have more than one language to be a multilingist, one just need to understand and/or research how to better support linguistic and cultural diversity. As Mr. Panetta stated, it is critical to stability and effectiveness in our global world. Portzamparc. --002215b03ec64c277f04adc48df5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all,
We, nicknamed "JEDI"s (Jefsey disciples), have often= tried to make the IETF understand and respect the implications of linguist= ic, cultural, political, economical diversities on protocol definition. Jef= sey obtained the RFC 4645, 4646, 4647 consensus he wanted.=A0 We also obtai= ned the IDNA2008 consensus which was necessary to warranty the internet sta= bility, its capacity to support any diversity by subsidiarity, and the emer= gence of the IUI. We still have a problem with the IETF/Unicode relations, = the WG/PRECIS, the IDNA IAB work, the ICANN/VIP work on variants, extension= of the punycode algorithm to support French and and the orthotypography (s= cripting syntax) of most of the other languages, etc.

May be this quote will help some of our colleagues to understand better= why the IETF is to "influence those who design, use and manage the in= ternet" for it to offer users with a better multilinguistic support.
=93We live in a global world,=94...
=93We have to understand that w= orld if we =85 are going to be able to not only defend this country, but to= extend our relationships to others so that we can work together to defend = the world that we live in.=94
=93The reality is that we have to reflect the nation we live in and we have= to reflect the world we are a part of."
=93Languages are the key = to understanding that world.=94... "It=92s also critical to the effect= iveness of current U.S. military operations." ...
"If we are going to advance stability in some of the countries we are = fighting in today, we have to be able to understand what motivates those co= untries, what motivates their people, and to understand their culture, beli= efs, faiths, ideologies, hatreds and loves".
=93So it is crucial to our national security to be able to have a strong la= nguage ability=94.

-=A0 Leon E. Panetta (8/23/2011). US Defense Secr= etary.

Mr. Panetta speaks on behalf of the USA, but I believe that i= f his understanding may be late, it is also true for every other nation.
Multilinguistics, as Jefsey defined it from our IETF experience, is the= cybernetics of the linguistic diversity. How languages and cultures can be= adequately be supported and result in positive synergetic feed backs. Its = key recipe seems to be first based upon a true network linguistic neutralit= y. One does not need to have more than one language to be a multilingist, o= ne just need to understand and/or research how to better support linguistic= and cultural diversity.

As Mr. Panetta stated, it is critical to stability and effectiveness in= our global world.
Portzamparc.
--002215b03ec64c277f04adc48df5-- From jefsey@jefsey.com Wed Sep 28 14:27: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 9A01321F8DCF; Wed, 28 Sep 2011 14:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.028 X-Spam-Level: X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj2FBWA8yAoE; Wed, 28 Sep 2011 14:27:57 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1C11E21F8D89; Wed, 28 Sep 2011 14:27:57 -0700 (PDT) Received: from 191.39-227-89.dsl.completel.net ([89.227.39.191]:49188 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1R91hm-0003oH-5w; Wed, 28 Sep 2011 14:30:24 -0700 Message-Id: <7.0.1.0.2.20110928160216.0b525188@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 28 Sep 2011 23:35:05 +0200 To: happiana@ietf.org From: JFC Morfin In-Reply-To: <6.2.5.6.2.20110927224537.09b1f9b0@resistor.net> References: <20110927155722.26914.33845.idtracker@ietfa.amsl.com> <6.2.5.6.2.20110927224537.09b1f9b0@resistor.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1109455850==.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: iucg@ietf.org Subject: Re: [iucg] [happiana] New Version Notification for draft-leiba-iana-policy-update-00.txt 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, 28 Sep 2011 21:27:58 -0000 --=====================_1109455850==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:04 28/09/2011, SM wrote: >At 15:54 27-09-2011, Larry Masinter wrote: >>I have heard people asking for IANA to manage registration >>information in a data format (such as XML). Should documents that >>establish a registry also establish the data format? > >No. :-) > >In Section 3: > > "Accordingly, document developers need to anticipate this and include > a justification for the chosen policy in the document along with the > documentation of the choice." > >I like the idea. I am wary of this being misinterpreted as giving >more weight to IANA Considerations instead of more thought to it. The Internet is a part of the whole digital ecosystem (WDE). As such it should converge with other registries documenting the WDE or being used through the WDE. This calls for the IANA to also capitilize on the JTC1/SC32/WG2 experience and study the interest of becoming at least ISO 11179 conformant. This should lead Barry's I_D is to be "ported" into an ISO 11179 context (concepts, terminology, procedures, I/O formats, creation, relation with information provider, graded reviewers, etc.). And then consider how it would better/lesser fit the IANA needs. This was discussed at the langtag registry definition time. The langtag registry by its size is most of the IANA registry. It did not went through beacause the langtag registry was a new registry and the WG's charter did not focus on what ISO 11179 would have brought. I wish to quote an excellent mail on the matter by Debbie Garside (NB. I defeated her FDIS 3166-1 which was an uncorrect political move, but analyzing ISO 11179 conformance was a right architectural move). >"Debbie Garside" ictmarketing.co.uk> >06/27/2006 01:22 AM > >To "'LTRU Working Group'" ietf.org> >Object: [Ltru] Preliminary Investigation into Application of ISO 11179 > >Findings of a preliminary investigation into the application of ISO 11179 to >the RFC3066bis Registry > >Cost >Initial investigations suggest that ISO 11179 can be applied to the Registry >at a base level for very little cost. The main cost is in mapping the ISO >11179 terminology to the existing Registry terminology and a number of >additional data elements would be required. The Registry already >incorporates a system of metadata elements that are consistent with the >model presented within ISO 11179. > >In particular the value of the following aspects of ISO 11179-6 should be >investigated: > >Identification >The attributes registration authority identifier (RAI), data identifier >(DI), and version identifier (VI) constitute the international registration >data identifier (IRDI). At least one IRDI is required for an administered >item. > >Data identifiers are assigned by a Registration Authority; data identifiers >shall be unique within the domain of a Registration Authority. > >Requirements for a Registration Authority, and a discussion of the IRDI, >appear in ISO/IEC 11179-6. > >As each Registration Authority may determine its own DI assignment scheme, >there is no guarantee that the DI by itself will uniquely identify an >administered item. For example, if two authorities both use sequential >6-digit numbers, there may be two administered items with the same DI's; >however, the administered items will almost certainly not be the same. > >If one administered item appears in two registers, it will have two DI's. >Therefore, both the DI and the RAI are necessary for identification of an >administered item. > >If particular attributes of an administered item change, then a new version >of the administered item shall be created and registered. The registrar >shall determine these attributes. In such a case, a VI is required to >complete the unique identification of an administered item. > >For further guidance, see ISO/IEC 11179-6. > >An IRDI can serve as a key when exchanging data among information systems, >organizations, or other parties who wish to share a specific administered >item, but might not utilize the same names or contexts. > >ISO/IEC 11179 does not specify the format or content of a unique DI. > >The IETF (or LTRU) would need to apply for an International Code Designator >(ICD) - a four integer code; this coupled with the organization name as well >as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU. >The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as >Registration Authority Identifier which is currently BSI. > >Implications for the LTRU Registry >The DI (or UI - Unique Identifier) cannot be the Subtag as there are already >conflicting Subtags within the registry (e.g. cy/CY). It is more preferable >that the unique identifier be the chosen language/country/script name >(please note, this is not the preferred name). This would fit with the >current ISO 639-3, -5 and -6 models and open the Registry to adoption by >meta-data knowledge grids. (I will take a good look at the naming >conventions within ISO 3166-1 at a later date but prior to publication of >FDIS 3166-1). > >Anomalies within ISO naming conventions of standards issued prior to the >adoption of ISO 11179 can be dealt with on a case by case basis via set >rules. > >The Subtag would become a "Representation" with the name being the unique >"Data Identifier". This would involve having a "Primary Description" which >would form the DI. > >In reviewing the "Required Metadata Attributes" for a "Preferred Standard" >Status administered item, preliminary investigations reveal no serious >additional requirements other than those already mentioned here. Some >manipulation and interpretation of registry data and standard mandatory >requirements would be required but no difficulties are envisaged. I would >refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34) > >Benefits >The ISO 11179 model allows for there being conflicting codes between >different meta-data registries in conformity with ISO 11179; that is part of >the conceptual model. ("in conformity with" is correct - there are >essential parts of the standard). > >In essence, the ISO 11179 meta-model supports linkage to other ISO 11179 >conformant meta-data registries thus facilitating data exchange/interchange >whilst giving the LTRU Registry ownership of the data elements contained >therein - they become LTRU elements giving room for manoeuvre should ISO get >it wrong. > >This will make language tags more meaningful in the future. The key word >here is "linkage". ISO 11179 conformant meta-data registries facilitate the >creation of knowledge grids, grid computing and the semantic web! > >Conclusion >At first glance the cost/value ratio favours ISO 11179; there appears to be >very little cost yet the true benefits of future interoperability and data >exchange are unknown. > >It is recommended that further investigation be conducted before application >of ISO 11179 can be discussed at WG level. > >Further benefits with regard to data interchange should be explored. > >It is further recommended that the "investigation into application of ISO >11179 Meta Data Registries to the Registry and its registration procedures >be conducted by nominated members of the WG with a view to application" be >added to the new LTRU Charter. > >Best regards >Debbie Garside More information on ISO 11179 MetaData registries: http://metadata-stds.org/ http://en.wikipedia.org/wiki/ISO/IEC_11179 Best jfc --=====================_1109455850==.ALT Content-Type: text/html; charset="us-ascii" At 08:04 28/09/2011, SM wrote:
At 15:54 27-09-2011, Larry Masinter wrote:
I have heard people asking for IANA to manage registration information in a data format (such as XML). Should documents that establish a registry also establish the data format?

No. :-)

In Section 3:

  "Accordingly, document developers need to anticipate this and include
   a justification for the chosen policy in the document along with the
   documentation of the choice."

I like the idea.  I am wary of this being misinterpreted as giving more weight to IANA Considerations instead of more thought to it.

The Internet is a part of the whole digital ecosystem (WDE). As such it should converge with other registries documenting the WDE or being used through the WDE. This calls for the IANA to also capitilize on the JTC1/SC32/WG2 experience and study the interest of becoming at least ISO 11179 conformant. This should lead Barry's I_D is to be "ported" into an ISO 11179 context  (concepts, terminology, procedures, I/O formats, creation, relation with information provider,  graded reviewers, etc.). And then consider  how it would better/lesser fit the IANA needs.

This  was discussed at the langtag registry definition time. The langtag registry by its size is most of the IANA registry. It did not went through beacause the langtag registry was a new registry and the WG's charter did not focus on what ISO 11179 would have brought.

I wish to quote an excellent mail on the matter by Debbie Garside (NB. I defeated her FDIS 3166-1 which was an uncorrect political move, but analyzing ISO 11179 conformance was a right architectural move).

"Debbie Garside" <debbie <at> ictmarketing.co.uk>
06/27/2006 01:22 AM

To "'LTRU Working Group'" <ltru <at> ietf.org>
Object: [Ltru] Preliminary Investigation into Application of ISO 11179

Findings of a preliminary investigation into the application of ISO 11179 to
the RFC3066bis Registry

Cost
Initial investigations suggest that ISO 11179 can be applied to the Registry
at a base level for very little cost.  The main cost is in mapping the ISO
11179 terminology to the existing Registry terminology and a number of
additional data elements would be required.  The Registry already
incorporates a system of metadata elements that are consistent with the
model presented within ISO 11179. 

In particular the value of the following aspects of ISO 11179-6 should be
investigated:

Identification
The attributes registration authority identifier (RAI), data identifier
(DI), and version identifier (VI) constitute the international registration
data identifier (IRDI). At least one IRDI is required for an administered
item.

Data identifiers are assigned by a Registration Authority; data identifiers
shall be unique within the domain of a Registration Authority.

Requirements for a Registration Authority, and a discussion of the IRDI,
appear in ISO/IEC 11179-6.

As each Registration Authority may determine its own DI assignment scheme,
there is no guarantee that the DI by itself will uniquely identify an
administered item. For example, if two authorities both use sequential
6-digit numbers, there may be two administered items with the same DI's;
however, the administered items will almost certainly not be the same.

If one administered item appears in two registers, it will have two DI's.
Therefore, both the DI and the RAI are necessary for identification of an
administered item.

If particular attributes of an administered item change, then a new version
of the administered item shall be created and registered. The registrar
shall determine these attributes. In such a case, a VI is required to
complete the unique identification of an administered item.

For further guidance, see ISO/IEC 11179-6.

An IRDI can serve as a key when exchanging data among information systems,
organizations, or other parties who wish to share a specific administered
item, but might not utilize the same names or contexts.

ISO/IEC 11179 does not specify the format or content of a unique DI.

The IETF (or LTRU) would need to apply for an International Code Designator
(ICD) - a four integer code; this coupled with the organization name as well
as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU.
The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as
Registration Authority Identifier which is currently BSI. 

Implications for the LTRU Registry
The DI (or UI - Unique Identifier) cannot be the Subtag as there are already
conflicting Subtags within the registry (e.g. cy/CY).  It is more preferable
that the unique identifier be the chosen language/country/script name
(please note, this is not the preferred name).  This would fit with the
current ISO 639-3, -5 and -6 models and open the Registry to adoption by
meta-data knowledge grids. (I will take a good look at the naming
conventions within ISO 3166-1 at a later date but prior to publication of
FDIS 3166-1). 

Anomalies within ISO naming conventions of standards issued prior to the
adoption of ISO 11179 can be dealt with on a case by case basis via set
rules.  

The Subtag would become a "Representation" with the name being the unique
"Data Identifier". This would involve having a "Primary Description" which
would form the DI.

In reviewing the "Required Metadata Attributes" for a "Preferred Standard"
Status administered item, preliminary investigations reveal no serious
additional requirements other than those already mentioned here. Some
manipulation and interpretation of registry data and standard mandatory
requirements would be required but no difficulties are envisaged. I would
refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34)

Benefits
The ISO 11179 model allows for there being conflicting codes between
different meta-data registries in conformity with ISO 11179; that is part of
the conceptual model.  ("in conformity with" is correct - there are
essential parts of the standard).

In essence, the ISO 11179 meta-model supports linkage to other ISO 11179
conformant meta-data registries thus facilitating data exchange/interchange
whilst giving the LTRU Registry ownership of the data elements contained
therein - they become LTRU elements giving room for manoeuvre should ISO get
it wrong.

This will make language tags more meaningful in the future.  The key word
here is "linkage".  ISO 11179 conformant meta-data registries facilitate the
creation of knowledge grids, grid computing and the semantic web!

Conclusion
At first glance the cost/value ratio favours ISO 11179; there appears to be
very little cost yet the true benefits of future interoperability and data
exchange are unknown. 

It is recommended that further investigation be conducted before application
of ISO 11179 can be discussed at WG level.

Further benefits with regard to data interchange should be explored.

It is further recommended that the "investigation into application of ISO
11179 Meta Data Registries to the Registry and its registration procedures
be conducted by nominated members of the WG with a view to application" be
added to the new LTRU Charter. 

Best regards
Debbie Garside

More information on ISO 11179  MetaData registries:
http://metadata-stds.org/
 http://en.wikipedia.org/wiki/ISO/IEC_11179

Best
jfc




--=====================_1109455850==.ALT-- From duerst@it.aoyama.ac.jp Wed Sep 28 22:04:28 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 747BA21F8DBA for ; Wed, 28 Sep 2011 22:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.751 X-Spam-Level: X-Spam-Status: No, score=-99.751 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llkCCNWxIgxs for ; Wed, 28 Sep 2011 22:04:28 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id A158621F8DB9 for ; Wed, 28 Sep 2011 22:04:27 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p8T5799V001898 for ; Thu, 29 Sep 2011 14:07:09 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 1c57_3007_e209c8bc_ea58_11e0_99a2_001d096c566a; Thu, 29 Sep 2011 14:07:09 +0900 Received: from [IPv6:::1] ([133.2.210.1]:48642) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 29 Sep 2011 14:07:11 +0900 Message-ID: <4E83FCF9.8030301@it.aoyama.ac.jp> Date: Thu, 29 Sep 2011 14:07:05 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: happiana@ietf.org References: <20110927155722.26914.33845.idtracker@ietfa.amsl.com> <6.2.5.6.2.20110927224537.09b1f9b0@resistor.net> <7.0.1.0.2.20110928160216.0b525188@jefsey.com> In-Reply-To: <7.0.1.0.2.20110928160216.0b525188@jefsey.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 29 Sep 2011 01:40:39 -0700 Cc: Randy Presuhn , iucg@ietf.org Subject: Re: [iucg] [happiana] New Version Notification for draft-leiba-iana-policy-update-00.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 05:04:28 -0000 On 2011/09/29 6:35, JFC Morfin wrote: > The Internet is a part of the whole digital ecosystem (WDE). As such it > should converge with other registries documenting the WDE or being used > through the WDE. This calls for the IANA to also capitilize on the > JTC1/SC32/WG2 experience and study the interest of becoming at least ISO > 11179 conformant. This should lead Barry's I_D is to be "ported" into an > ISO 11179 context (concepts, terminology, procedures, I/O formats, > creation, relation with information provider, graded reviewers, etc.). > And then consider how it would better/lesser fit the IANA needs. > > This was discussed at the langtag registry definition time. The langtag > registry by its size is most of the IANA registry. It did not went > through beacause the langtag registry was a new registry and the WG's > charter did not focus on what ISO 11179 would have brought. Just for the record, I was co-chair of the responsible ltru WG. It is true that the issue of ISO 11179 was brought up on that list by JFC Morfin. And as the excerpt below shows, it is true that not all other WG participants were a-priori against ISO 11179 conformance, whatever that would have meant. However, if my recollection and my judgment of the WG situation is correct, I think given the general interests in the WG, JFC Morfin would have had an extremely hard time obtaining any kind of WG consensus towards ISO 11179 conformance even if he had pressed the issue. I can't speak for any WG participants in particular, but my guess is that the overhead was simply seen as too big, with not enough actual gains. Regards, Martin. > I wish to quote an excellent mail on the matter by Debbie Garside (NB. I > defeated her FDIS 3166-1 which was an uncorrect political move, but > analyzing ISO 11179 conformance was a right architectural move). From randy_presuhn@mindspring.com Thu Sep 29 11:11: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 7433D21F86DD; Thu, 29 Sep 2011 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBIUjHDv71Cn; Thu, 29 Sep 2011 11:11:58 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id D3A4921F86B3; Thu, 29 Sep 2011 11:11:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=f62wIuwkpuL6v6mfHVkTm7MQOqkep1BfxxtTUppf1hPYww4Z6/vtf4DA5wcaTeGq; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.175.238] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R9L88-0002hl-38; Thu, 29 Sep 2011 14:14:44 -0400 Message-ID: <05ca01cc7ed3$cd367840$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: =?utf-8?Q?Martin_J._D=C3=BCrst?= , References: <20110927155722.26914.33845.idtracker@ietfa.amsl.com> <6.2.5.6.2.20110927224537.09b1f9b0@resistor.net> <7.0.1.0.2.20110928160216.0b525188@jefsey.com> <4E83FCF9.8030301@it.aoyama.ac.jp> Date: Thu, 29 Sep 2011 11:15:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee2881296f28a495ed6e6fbade5ed3cea89eb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.175.238 X-Mailman-Approved-At: Thu, 29 Sep 2011 15:43:40 -0700 Cc: iucg@ietf.org Subject: Re: [iucg] [happiana] New Version Notification for draft-leiba-iana-policy-update-00.txt X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 18:11:58 -0000 Hi - (as the other former co-chair of ltru) > From: "Martin J. Dürst" > To: > Cc: ; "Randy Presuhn" > Sent: Wednesday, September 28, 2011 10:07 PM > Subject: Re: [happiana] New Version Notification for draft-leiba-iana-policy-update-00.txt > > On 2011/09/29 6:35, JFC Morfin wrote: > > > The Internet is a part of the whole digital ecosystem (WDE). As such it > > should converge with other registries documenting the WDE or being used > > through the WDE. This calls for the IANA to also capitilize on the > > JTC1/SC32/WG2 experience and study the interest of becoming at least ISO > > 11179 conformant. This should lead Barry's I_D is to be "ported" into an > > ISO 11179 context (concepts, terminology, procedures, I/O formats, > > creation, relation with information provider, graded reviewers, etc.). > > And then consider how it would better/lesser fit the IANA needs. > > > > This was discussed at the langtag registry definition time. The langtag > > registry by its size is most of the IANA registry. It did not went > > through beacause the langtag registry was a new registry and the WG's > > charter did not focus on what ISO 11179 would have brought. > > Just for the record, I was co-chair of the responsible ltru WG. It is > true that the issue of ISO 11179 was brought up on that list by JFC > Morfin. And as the excerpt below shows, it is true that not all other WG > participants were a-priori against ISO 11179 conformance, whatever that > would have meant. The first reference to 11179 in my records is a posting from L. Gillam on March 21, 2005, where it was mentioned in passing in a note about what was happening with various ISO specifications. The issue of whether there was a need for the language subtag registry to be 11179 compliant was added as issue #1027 on June 7, 2005. The clear WG consensus was that it was while 11179 compliance might have been a nice thing, it was also clearly overkill for the needs of the language subtag registry. Taken in the context of JFC Morfin's overall record in the working group, I believe that his insistance was widely perceived as part of a dilatory strategy. > However, if my recollection and my judgment of the WG situation is > correct, I think given the general interests in the WG, JFC Morfin would > have had an extremely hard time obtaining any kind of WG consensus > towards ISO 11179 conformance even if he had pressed the issue. I can't > speak for any WG participants in particular, but my guess is that the > overhead was simply seen as too big, with not enough actual gains. Numerous postings on (and off) the mailing list directly expressed the concern that reaching and verifying full compliance with 11179 was not worth the effort, particularly given the relatively narrow scope of the language subtag registry. During the course of the WG's work, JFC Morfin made numerous attempts to increase the scale and scope of the work. If there had been any support for broadening the work to include all the stuff he wanted thrown in, then use of 11179 might have made more sense and possibly gotten some support. Randy From jfc@morfin.org Fri Sep 30 08:33:23 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 72DA021F8B16 for ; Fri, 30 Sep 2011 08:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNuCeEKpK4jv for ; Fri, 30 Sep 2011 08:33:22 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 584C621F8B14 for ; Fri, 30 Sep 2011 08:33:22 -0700 (PDT) Received: from 191.39-227-89.dsl.completel.net ([89.227.39.191]:54688 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1R9f80-0007Qn-Mr; Fri, 30 Sep 2011 08:35:57 -0700 Message-Id: <7.0.1.0.2.20110930123119.0b5252d0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 30 Sep 2011 17:40:52 +0200 To: =JeffH , IETF IDNA Update WG From: "J-F C. Morfin" In-Reply-To: <4E853263.1040508@KingsMountain.com> References: <4E853263.1040508@KingsMountain.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 - morfin.org X-Source: X-Source-Args: X-Source-Dir: Cc: Pete Resnick , iucg@ietf.org, websec-chairs@tools.ietf.org, Peter Saint-Andre , Adam Barth Subject: Re: [iucg] IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec 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, 30 Sep 2011 15:33:23 -0000 Jeff, I am sorry I cannot study your inputs before one or two weeks. From your mail, I fear there is a misunderstanding concerning the impact of IDNA2008 on the architecture and security of the network user side. Basically, the problem is as follows: - the support of a language in the OSI model is achieved at the presentation layer. - the support of the linguistic diversity (scripts and orthotypography of each language) at end user level, to be constantly adapted to variants as demanded by people and the foreseeable semantic orient extension of networking, means an incredibly complex presentation layer. - the Internet has no presentation layer. However, IDNA2008 has introduced a stable, simple, and secure way to support the IDN linguistic diversity. That it was able to do it without changing a single bit in existing Internet protocols means that this way was buried into the Internet architecture from the very beginning. Warning!: that it took ten years to exemplify a solution without documenting an architectural principle in line with RFC 1958 and 3439 means that the true Internet model is not with us yet. This new model is under IETF and non-IETF investigation - and you participate in its exploration. What we already know is that: - from the beginning of the IDNA2008 work I asked if the target was to support IDNA for the Internet or for the users. The charter and the Chair said "for the Internet". So, I committed to make sure that I could build the user oriented extension (I called the ML-DNS as in multi-layer) on top of the IDNA2008 solution. My referent was the support of French semantics in IDNs. There were rough times but a Pete Resnick and Paul Hoffman I_D (which became the RFC 5865 for information) exemplified a solution for our "unusual" case and permitted a full consensus. It introduced (my reading) cooperation with external subsidiarity as an Internet architectural principle. - that consensus was however questioned on two points: - by me: the inability to support orthotypographic metadata (example: the meaningful French majuscules - that may be represented by but are not upper cases) - by the AD: the very IDNA architecture concept is costly and insecure. Several applications (as what you discuss) on the same machine may resolve the same user entry to different IPs. This called for the concept of a smart (virtual) middlebox I named the IUI (see below). It had to be simple (RFC 2934), optional (introduction) and at fringes (because being smart) or at edges (OPES). I was one of the active people in discussing this: 1. I reported the IESG my IDNA2008 unresolved problems as Project.FRA leader, an experimental project of open networked ontology supported by a Francophone namespace: - the way I would architecturally address it, - the urgency for them to accept IDNA2008 so we could start working on a stable definition of the Internet Use Interface IETF requirements (IUI). - the implied major problem of IETF responsibility (cf. RFC 3935) in specifying the resulting multi-technology users' digital ecosystem Intelligent Use Interface (IUI) - I would address through an appeal. 2. I therefore constructively appealed against the lack of an IESG or IAB disclaimer in IDNA2008 RFCs alerting everyone of the implied enormous extension and simplification in reading the Internet technology. The lack of disclaimer has lead to several requests for information like yours (WG/PRECIS, Hapiana, ICANN/WG/VIP) and work at the IUCG. The IESG and IAB response and the parallel IAB road map were equally constructive. IAB/IESG responses and RFC 5865 lead to understand that IUI architectures and standardization are not in the in the IETF area and that interfacing protocol should be completed by an informational "how to" in the case no IUI is being involved (as exemplified by the IDNA2008 RFC set). Based upon my position during the WG work and the final consensus we reached, I would suggest this simple rule: the IETF can use MUSTs only for the end to end, SHOULDs only for the fringe to fringe, and MAYs for the applications to applications. This way Internet protocol requirements are stable and clear, and IUI test designers and further standardizers have clear inputs to implement their services and their interface with the various local applications (network apps such as the DNS, IUI mutual service apps, and the User's side applications such as a browser). Without prejudging the finalization of the post-IDNA2008 Internet and digital ecosystem Model, I think the "plug, end, fringe, application, brain" layering protects the future. jfc At 05:07 30/09/2011, =JeffH wrote: >Hi, > >In working towards completion of.. > > HTTP Strict Transport Security (HSTS) > > >..and.. > > The Web Origin Concept > https://tools.ietf.org/html/draft-ietf-websec-origin > >..we are attempting to address the proper way to reference IDNA2008 >and IDNA2003 in terms of stipulating comparisons of domain names >(that may or may not be IDNs). > >In discussions with our ADs and a few IDNA-literate folks, we've >been informed that the IDNA-specific language in the >recently-released RFC6265 HTTP State Management spec isn't quite up >to the standards they would like to see at this time. > >Thus I've performed some surgery on >draft-ietf-websec-strict-transport-sec and have included below the >specific section portions that are IDNA specific (this is from my >working copy which isn't quite yet overall ready tonight to submit as -03). > >The key context to keep in mind when reviewing the below is that the >key "processing" -- essentially a domain name comparison -- will >occur deep within the bowels of HTTP clients, well along the >processing pipeline for URIs, and presumably after >IDNA-canonicalization and requisite validation/testing has occurred. >However, the guidance we've received is that given the complexities >and subtleties of IDNA processing and considerations, our specs >really should be more explicit about the foregoing assumption(s) and >the downside risks if the requisite validation/testing is not performed. > >With that context in mind, thoughts on the below are solicited. >Apologies for just having these excerpts at this time, but I ought >to have -websec-strict-transport-sec-03 submitted in the next few days at most. > >thanks, > >=JeffH > . > . > . >7. User Agent Processing Model > > This section describes the HTTP Strict Transport Security processing > model for UAs. There are several facets to the model, enumerated by > the following subsections. > > This processing model assumes that the UA implements IDNA2008 > [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 11 > "Internationalized Domain Names for Applications (IDNA): Dependency > and Migration". It also assumes that all domain names manipulated in > this specification's context are already IDNA-canonicalized as > outlined in Section 8 "Domain Name IDNA-Canonicalization" prior to > the processing specified in this section. > > The above assumptions mean that this processing model also > specifically assumes that appropriate IDNA and Unicode validations > and character list testing have occured on the domain names, in > conjunction with their IDNA-canonicalization, prior to the processing > specified in this section. See the IDNA-specific security > considerations in Section 13.2 "Internationalized Domain Names" for > rationale and further details. > . > . > . >8. Domain Name IDNA-Canonicalization > > An IDNA-canonicalized domain name is the string generated by the > following algorithm, whose input must be a valid Unicode-encoded (in > NFC form [Unicode6]) string-serialized domain name: > > 1. Convert the domain name to a sequence of individual domain name > label strings. > > 2. When implementing IDNA2008, convert each label that is not a Non- > Reserved LDH (NR-LDH) label, to an A-label. See Section 2.3.2 of > [RFC5890] for definitions of the former and latter, refer to > Sections 5.3 through 5.5 of [RFC5891] for the conversion > algorithm and requisite input validation and character list > testing procedures. > > Otherwise, when implementing IDNA2003, convert each label using > the "ToASCII" conversion in Section 4 of [RFC3490] (see also the > definition of "equivalence of labels" in Section 2 of the latter > specification). > > 3. Concatenate the resulting labels, separating each label from the > next with (".") a %x2E character. > > See also Section 11 "Internationalized Domain Names for Applications > (IDNA): Dependency and Migration" and Section 13.2 "Internationalized > Domain Names" of this specification for further details and > considerations. > . > . > . >11. Internationalized Domain Names for Applications (IDNA): Dependency > and Migration > > Textual domain names on the modern Internet may contain one or more > "internationalized" domain name labels. Such domain names are > referred to as "internationalized domain names" (IDNs). The > specification suites defining IDNs and the protocols for their use > are named "Internationalized Domain Names for Applications (IDNA)". > At this time, there are two such specification suites: IDNA2008 > [RFC5890] and its predecessor IDNA2003 [RFC3490]. > > IDNA2008 obsoletes IDNA2003, but there are differences between the > two specifications, and thus there can be differences in processing > (e.g. converting) domain name labels that have been registered under > one from those registered under the other. There will be a > transition period of some time during which IDNA2003-based domain > name labels will exist in the wild. User agents SHOULD implement > IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of > [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. > If a user agent does not implement IDNA2008, the user agent MUST > implement IDNA2003. > . > . > . >13. Security Considerations > . > . > . >13.2. Internationalized Domain Names > > Internet security relies in part on the DNS and the domain names it > hosts. Domain names are used by users to identify and connect to > Internet hosts and other network resources. For example, Internet > security is compromised if a user entering an internationalized > domain name (IDN) is connected to different hosts based on different > interpretations of the IDN. > > The processing models specified in this specification assume that the > domain names they manipulate are IDNA-canonicalized, and that the > canonicalization process correctly performed all appropriate IDNA and > Unicode validations and character list testing per the requisite > specifications (e.g., as noted in Section 8 "Domain Name IDNA- > Canonicalization"). These steps are necessary in order to avoid > various potentially compromising situations. > > In brief, some examples of issues that could stem from lack of > careful and consistent Unicode and IDNA validations are things such > as unexpected processing exceptions, truncation errors, and buffer > overflows, as well as false-positive and/or false-negative domain > name matching results. Any of the foregoing issues could possibly be > leveraged by attackers in various ways. > > Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in > terms of disallowed characters and character mapping conventions. > This situation can also lead to false-positive and/or false-negative > domain name matching results, resulting in, for example, users > possibly communicating with unintended hosts, or not being able to > reach intended hosts. > > For details, refer to the Security Considerations sections of > [RFC5890], [RFC5891], and [RFC3490], as well as the specifications > they normatively reference. Additionally, [RFC5894] provides > detailed background and rationale for IDNA2008 in particular, as well > as IDNA and its issues in general, and should be consulted in > conjunction with the former specifications. > >13.3. Denial of Service (DoS) > . > . > . > > >--- >end > From jefsey@jefsey.com Fri Sep 30 09:18: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 ACDF521F8CF2; Fri, 30 Sep 2011 09:18:10 -0700 (PDT) X-Quarantine-ID: <6jrsA5xy1lst> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char FC hex): To: ...mputer.org>,\n Martin J. D\374rst ) id 1R9fpY-0000yK-AC; Fri, 30 Sep 2011 09:20:56 -0700 Message-Id: <7.0.1.0.2.20110930174319.07c833a0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 30 Sep 2011 18:25:50 +0200 To: Larry Masinter , Barry Leiba , Martin J. Dürst From: JFC Morfin In-Reply-To: References: <20110927155722.26914.33845.idtracker@ietfa.amsl.com> <6.2.5.6.2.20110927224537.09b1f9b0@resistor.net> <4E840439.8090409@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: "happiana@ietf.org" , iucg@ietf.org Subject: Re: [iucg] [happiana] New Version Notification for draft-leiba-iana-policy-update-00.txt 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, 30 Sep 2011 16:18:10 -0000 At 18:53 29/09/2011, Larry Masinter wrote: >Comment on draft-leiba-iana-policy-update: > >I think it's awkward to try to update BCP 26 (RFC 5226) with a >separate stand-alone document. Why not just produce an updated 5226? > >(In which case, the discussion below WOULD be in scope, although I >agree it isn't now.) The WG/LTRU case resulted from a conjunction of different commercial, political and strategic biases (as documented in RFC 3869) of real magnitude. It only is interesting here due to the experience it represented and by its lessons. It taught me (at least) that the IANA had to be: - protected by openness against bias and capture - at the proper level of user requirement, i.e. multilingual - at the proper level of architectural evolution, i.e. interusable The IANA does not meet these requirements today. There are two possible scenarii which are similar to its DNS support and foreseeable evolution. - either as the Internet registry of a referential galaxy, hence conforming to the rules of such a galaxy. - or as the Internet source of metadata that will be mixed by MataData referent services (MDRS) providers. Further inputs on this, the Lee Gillam proposition (ISO 11179), the governmental and industry level international implications (the IETF weak to strong consensus I obtained [against me] was only a simple part of the story), the real target, the risks for the IETF, the present MDRS related concerns, etc. would need a reporting I_D of mine on the matter. Not about the past, but about the today similar and more extended risks and alternatives. I will try to write such an I_D in the coming weeks. Because the decision about the IANA's future necessarily lays on this list. Best jfc