Subject: Re: [iucg] [Idna-arabicscript] mapping of Full Stops

From: jefsey <[email-masked]>
Date: Tue, 13 Oct 2009 00:30:58 +0200

I apologize, I forgot to copy IUCG. In the meanwhile John Klensin and 
Wil Tan conforted our position and the importance of the netlocale 
issue and of experience. Obviously our priority is to support century 
old orthtypography rather than six year old prototyping. We will 
certainly not consider the re-registration of one or thousands of 
domain names as a serious issue if its to correct a possible semantic 
pollution.

jfc

--------

Dear Sarmad,

 From what I currently understand:

- you want to add U+06D4 as a local IDN separator in the example list 
of the Mapping document because expect it to facilitate things for 
your linguistic community.
- Paul is OK with adding another example in an open list
- John believes that this facilitation should be offered to every 
community that has a similar need
- Vint believes that this should not be carried by the IETF, and 
proposes ICANN instead
- John objects to ICANN, for several reasons, and others may object 
for reasons other than those
- Eric recalls that U+06D4 is supported in labels in IDNA2003
- Andrew agrees with John if the request is global, with Vint if not, 
ICANN being suited or not
- I agree with Paul, also with John: you will not be the only one to 
ask for such tunings, so this kind of needs should be addressed on a 
structural basis if they belong to IDNA2010. But this is another 
architectural story and we need to gain operational experience and 
more inputs.

As internet lead users, we set-up the IUCG (Internet users 
contributing group) with a mission that we started experimenting 
during the recent months. It is to _facilitate_ the user experience 
of the digital convergence. This has led to the conceptual addition 
of a middle common layer-set between the Internet (and other passive, 
active, or ambient content transport technologies) and the user. This 
includes what some call the UI (user interface). Because we believe 
the Internet to be the most probable central technology for the 
digital convergence, upon IESG avdvise we requested our IUCG to be 
established as the non-WG IETF [email-masked] mailing list. It was 
copied many of the WG-IDNABIS mails.

The way that we are exploring Facilitation implementation is to 
implement it on top of the Network layers, so that the Facilitation 
can be seen from the network point of view as just another UI, 
outside of the IETF scope, but still in close relation with it. We 
called that UI "Interplus" since it plugs layers on the user side (or 
they may be implemented in using a user OPES or as a distributed OPES 
network [ONES]), so that the user who is choosing to use it feels 
like he or she was interfacing an "Internet PLUS" network system. We 
have indentified three layers that are to be plugged in a top-down 
order (from the user):

(1) a "pseudo-network" layer hosting network service oriented 
interapplication slots
(2) an interoperation layer interfacing Internet network applications 
and pseudo-network local or distant interapplication slots
(3) the virtual Internet presentation layer as implemented by the IDN 
interapplication.

In this Interplus user side UI architecture, IDNA is not individually 
supported at the user application level, but it is generally 
supported at the IDNAPLUS interapplication slot. It is in this way 
that the slot can be called, through the interoperating layer by the 
local DNS name server slot and filter every local and external 
request, and in this way participate in an mbient prevention of the 
DNS pollution. One of the tasks that we have is to explore the Netix 
interoperation system that will dispatch and control this kind of 
intertasking througout the interoperation layer.

This user side UI architecture uses a four layer domain name pile, 
including the UDN (what the user types in), LDN (what local 
processing may need), the ADN (what the applications need), and the 
IDN (what the Internet supports, i.e. A-labels and regular DNs [there 
is no need to differentiate between DNs and IDNs since, moreover, we 
use an identical syntax to describe them]). IDNAPLUS uses the 
"punyplus" extended algorithm.

This algorithm converts UDNs to LDN to ADNs to IDNs in(back and forth):
- optionally mapping characters to others, on the information coming 
from netlocale files.
- converting every character to lowercase and inserting a metadata 
uppercase indicator when appropriate (back and forth) as indicated in 
"netlocale" files.
- respecting the IDNA2008 tables and using punycode

We had not discussed LDN, "netlocale" files and data, maintenance, 
IUCG repositiry and support yet because we did not want to confuse 
the now nearly ended IDNA2008 debate. I will introduce them in the 
coming days to the punyplus documents and I_D.

The table that John refers to, along with the inputs from ISP and 
communities, etc. will be maintained as an IUCG registry of the MDRS 
(multilingual and distributed referencing system) that will 
distribute netlocale data. We merged our MLTF research unit 
(Multilinguistics and Facilitation Technologies) with IUCG and have 
also engaged ourselves in a series of reference tables in order to 
attempt to exhaustively and comprehensively document the 
interplus/intersem (semiotic internet of thoughts) metastructure. 
This is in line with the ccTAGs I_D, the ISO 3166, 639, 10646, and 
15924, and RFC 4646 areas, extending into the semiotic and 
mecalanguages space (with signs, symbols, logos, gestures, etc. as 
introduced in the Mapping document) and bridging them in a networked 
usage perspective.

Since French majuscules will not be supported by IDNA2008, 
Project.FRA (open ontology using its namespace as a taxonomy) and 
Multilinc (multilinguistics test-bed) will test IDNAPLUS and report 
the result to the IETF towards some IDNA2010 finalization. We are 
currently working on the first Interplus SIS (software integrated 
system) prototype project. We will certainly include your suggestion 
and test it throught the Multilinc project.

We will also keep this list well informed and let you know about the 
test cooperation we will need.

Best
jfc