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

[JFC Morfin]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/vip/attachments/20110903/a4c74c3b/attachment.html