Subject: Re: [iucg] [vip] FW: [latin-vip] Loudly spoken opinions - input for today's meeting

From: JFC Morfin <[email-masked]>
Date: Sat, 03 Sep 2011 01:06:25 +0200

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/rfc5507
       - http://wiki.tools.ietf.org/rfc/rfc6055.txt
       - 
<http://tools.ietf.org/id/draft-iab-dns-applications-02.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

---

From: JFC Morfin <[email-masked]>
Date: Sat, 03 Sep 2011 11:58:08 +0200

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.

---

From: JFC Morfin <[email-masked]>
Date: Sat, 03 Sep 2011 15:31:37 +0200

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