Wikidna team final report
psuger at gmail.com
Tue Sep 1 05:08:20 CEST 2009
I am reporting the WG/IDNABIS/LC grouped conclusions from those involved in
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
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"
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
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
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)
· 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Idna-update