Subject: [iucg] Wikidna team final report

From: Patrick Suger <[email-masked]>
Date: Tue, 1 Sep 2009 05:08:20 +0200

Dear Colleagues,

I am reporting the WG/IDNABIS/LC grouped conclusions from those involved in
http://wikidna.org.

1. our main concern is the consistence of the presented documents with the
WG-Charter because we initially identified, reported and verified that we
could build a robust, fool-proof, multilingualized and Intersem (Semiotic
Internet) ready multi-layered domain name system (ML-DNS) on top of it.

2. we tried to best help this WG in achieving its task as quickly as
possible once it was clear that its intent was not to eventually address the
final needs of the Internet/IETF users but only to improve the IDNA
concepts.

It then it became clear that our evaluation of the constraints imposed on
IDNA by the eventual satisfaction of these final needs where not considered
as part of the WG concerns. It meant that we could not act as catalysts of
an IETF originated use centric solution.

We found, with the help of the IESG and IAB, a way (IUCG bootstrap) to
organize the exploration of the user client/people centric network
architecture we think we need and the World Summit for the Information
Society (WSIS) unanimously called for. As users we are not interested in
incremental, disruptive, or confusing but in "intelligent" development. We
mean by this "inter-legere", i.e. conceived as a distributed adaptative
network of function sets, able to flexibly network our own relational
spaces, their supporting applications, and the world diversity. We see one
of these set as being the Internet itself. This is what we call the
"networks of the network of networks" or the "hardware, software, brainware"
pile.

3. the first thing we collectively confirmed is that IDNA can only be
supported by a presentation layer. Since IDNA actually works for years, it
meant that the Internet presentation layer works well. So, we copied the
DDDS reasoning which identified the DNS as a DDDS identified from it. We
identified IDNA as the Internet legacy's Internationalized presentation,
characterized by the "xn--" presentation tag (prestag) of its tagged labels;
the default (English ASCII) presentation being characterized by a lack of
prestag.

4. we then identified the need to clarify the client "post-wire" layers
needed to correctly support the users' orthotypographic expectations from
multilingual user (domain) names (UDNs), to application interchanges
(domain) names (ADNs), and their ultimate support by the DNS in the case of
the Internet domain names (I/DNs).  For the support of the resulting
technology independent, semantic addressing ready, (domain) name pile we
need the most robust and proven solutions.

5. we identified that:

·         UDN (user) were adequately supported by ISO 10646; Unicode could
support additional canonization services; and IDNA supported features we can
need in cases such as homography and majuscules, for example.

·         the Punycode algorithm could be transparently trimmed (we dubbed
it "Punyless") to address our security/stability needs from ADNs
(application) to IDNs (Internet).

·         an alphadecimal reading of DNS labels and sub-labels permitted by
its LDH limitations warranted a very clear and robust resolution tool that
was to be absolutely protected. We even think that Vixie's security oriented
proposition might be considered.

·         on one hand local name servers and on another hand OPES that may
support ONES (open networked extended services) permitted a distributed SNHN
(small network/home network/stand alone host) light and powerfull "netship"
architecture that might suite us.

6. we also identified two main lacks :

·         the need of an interapplication system, we dubbed as "netix", that
would actually interlink client applications in order to support active
contents, while the Internet layers only support passive contents.

·         a total lack of preparation of the Internet Governance, Adminance
(as we name technical governance) and economy to the multi-ledger domain
name space with heterarchic roots,  as a full usage of classes and
presentation lead to (cf. ICANN ICP-3 document).

7. As a result we accepted that it was possible:

·         to build the Intersem as a three uncoupled strata architecture
(telecoms signals, datacoms passive and active contents, metacoms meanings)

·         where IDNA would be the seed of a DNS/SAS interface (domain name
system/semantic addressing system)

·         and the DNS namespace could form the taxonomy of the Intersem
ontologies.

This means that the Internet could be transparently extended in an IDNA
interoperable way to support the Intersem.

We called that extended Internet, the "Internet Plus" (with Plugged Layers
User System) and the extension "shim" (word also used by IAB for the IDNA)
the "interplus". The Interplus would be made of an interapplication and of a
pseudo-network layers, and could virtually support the presentation layer
plus some other end to end functions.

8. We then engaged into two test beds (as per IETF standard requirement)
projects:

·         Multilinc mostly oriented towards multilinguisation issues,

·         and Project.FRA more oriented towards the semantic aspects and the
MDRS (Multilingual Distributed Reference System), i.e. the common referents
of collective or personal relational spaces needed by intercomprehension
facilitation systems.

9. we then used that consistent model to check that the WG-IDNABIS document
set was appropriate, i.e. that it was possible for the Interplus to provide
a stable, reliable and secure "IDNA" support.

This lead us to publish our WG/LC comments, completed by comments on the IAB
IDN current draft.

10. We have then collected the whole WG/LC comments and authors' comment set
and maintained all this material on our http://wikidna.org site.  We intend
to publish it as an Internet Draft:

·         to help us make sure there is no technical conflict between our
Internet vision and the IDNA2008 documents.

·         to check that (except for the completed IDNA-Bidi Draft) the WG/LC
comments are answered by the authors.

·         because the document set still does not fully match the Charter,
in particular on the mapping issue. This was acknowledged by the proposition
to modify the Charter accordingly. We are not opposed to this change due to
work achieved, as it makes clear that IDNA has not yet reached the
transparency we need.

NB. This memo results from my notes and has not been edited due to a last
minute proposition. We decided to publish it as is to match the end of the
WG/LC.

Patrick Suger.

---

From: Elisabeth Blanconil <[email-masked]>
Date: Wed, 23 Sep 2009 02:38:52 +0200

Dear Dominique,

this is the IETF, it means engineers. Engineers know machines and
RFCs, not people and uses. For them telling some non-English speaker
"you can now eventually do what you expected and not only use
American" is candidly "reformating" him. They worked hard for ten
years to permit people to use their own scripts, but they still do not
want they use them in the way of their own language.

I know most outside the IETF think it is to support some capitalistic
strategy of their employer (read RFC 3869 by the IAB on that risk). I
do not think so in this case. The fundamental misunderstanding is they
confuse domain names with hackers' mnemonics (the hack is to better
remember a TM you saw on a Bus side because it is has to be written in
a different way).

Just be careful. We do not care about language. This is the IETF not
the UNESCO. DNs are neutral labels chains. The job of this WG is
precisely to make sure IDNs are also script neutral. This is for
people to use them as steganographic labels chains (such as these
famous possible menmonics) they must be neutral so they can support
any embedded semantic. Steganography depends on end to end (brain to
brain) orthotypography. Imposing an IETF English orthotypography that
bans 50% of the human character set kills most of the steganographic
interest of IDNA as a system for more linguistically complex
languages..

Never mind, this is a technically easy to solve layer violation (here,
at the IETF/LC or in the field deployment), between "engineering" and
"usering" layers. They deal with software, we deal with brainware. The
only thing we need is the RFCs to be eventually published so we build
on top. The pity is that we did a lot of work together and we are just
two lines of text and three lines of code a part from a common
consensus. Next time.

Best.
Elisabeth Blanconil

2009/9/22 Dominique Lacroix <[email-masked]>:
>  Gervase Markham <[email-masked]> wrote:
>
> since they
> started using the DNS and the Internet, which could have been up to
> around 25 years ago.
>
> After thinking, are you sure, dear Gervase, that such an argument (25 years
> of use) is an effective one to demonstrate that a choice is the right one?
> It could be 25 years of wrong use by users who have not any other choice...
> In French, we say: "fait accompli". I'm sure you understand it.
> And in Latin: "Errare humanum, perseverare diabolicum."
>
> Your fundamental misunderstanding is to not realise that DNS names are
> aides memoire, not words in a particular language, no matter how much
> they may resemble the latter.
>
> The double nature of DNS is indeed a great source of issues.
> IMHO, actually, domain names are *labels* (in French "étiquettes").
> And as digital labels, they are both: computing signs and linguistic signs.
> For the major part of users, reading a domain name when surfing deals mostly
> with language rules.
> As that double nature system is an original one, I believe the designers of
> the system are probably free to take in account more or less rules of each
> kind.
> If IETF wished to better take in account the linguistic aspects of domains
> names it could be possible, don't you think?
> But perhaps the price could be more complicate computing rules?
> I wonder if this list  is the best place for such a debate. Is there a
> better one?
>
> Best regards,
> @+, Dominique Lacroix
>
> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>