Re: [workon] review of new contributions since the IDNA2008 appeal.
JFC Morfin
Saint-Andre's newprep Charter proposition. They address the same
"non-ASCII" issue and, therefore, are complementary and help in
showing how to best approach it: probably through a WG but with a
more generalized Charter.
---
IDNA2008 is, firstly, an improvement in clarifying the relation
between Unicode and the Internet. I did not raise that issue in my
appeal because it is technical, whereas my appeal is about
architectural awareness. However, the way that these two documents
read IDNA2008 shows that:
- my appeal over the lack of a proper IESG/IAB disclaimer on the de
facto established:
-- finalization of the Internet architectural essence
-- Internet Usage Interface (IUI) and, therefore, the resulting need
to document the User Side counter-part of IDNA2008 (i.e. what we call
in here IDNA2010) and their mutual adminance (what we call in here IDNA2012).
- should _also_ extend to a disclaimer concerning the non-ASCII area
doctrine that has been established by IDNA2008, an area these two
propositions seek to explore without fully considering the
implications of IDNA2008 that IDNA2010 should document.
---
Let us come back to the character support implications of IDNA.
1. IDNA needs character tables that match the needs of the Internet
naming system. These tables can be established with its own coding or
by using ISO 10646 codes. The table that was documented by Patrik Falst�m:
- is theIDNA Internet core Table. As such, it is a superset of all
the zone tables that zone managers may decide to use.
- uses ISO 10646/Unicode code points. This addresses those cases
where an IDNA table is a restriction of ISO 10646/Unicode, but does
not address those cases where IDNA tables are an extension of ISO
10646/Unicode.
2. IDNA2010 now should establish the criteria and methods for zone
managers to restrict or extend the IDNA2008 Internet core table into
IDNA2010 IUI tables (plural).
3. Then, IDNA2012 should use these criteria and methods to coherently
extend the same strategy to the other non-ASCII that are used by
Internet protocols, one by one.
This boils down to completing the work that I initially documented as
a preliminary to any IDNA (i.e. Non-ASCII in Domain Names) effort: a
Universal Character Set for Internet protocols
---
A. Restrictions
There may be different criteria to restrict the IDNA2008 tables. They
can be local (by a zone manager). They can be operational, such as
fighting phishing: in order to only retain the code points, the glyph
of which in a selected universal font cannot be confused by readers,
optical readers, law enforcement agencies, etc.
B. Extensions
The WG/IDNABIS has failed to support French and, more generally,
Latin languages' majuscules. This example (others have been
considered that are documented at http://idna2010.org) shows that
A-labels and U-Labels _cannot_ be transformed into each other without
a loss of information. This is an orthotypographic (typographic
syntax) issue because this affects the underlying semantics. My
interest is in supporting the Semantic Addressing System in using the
ML-DNS (i.e. a DNS based homogenous support of the Naming Pile
[A-label, U-label, etc.] to be documented as fully compatible with
IDNA2010 [loop process)). The Semantic Addressing System needs full
semantic information preservation from IUI to IUI (i.e. further to
end to end, the "unusual" situation documented by the abandoned
Mapping document, which will necessarily be a part of the call for
IAB guidance that the IESG will place, or of my appeal to the IAB if
the IESG does not do it.
C. Stability
The first major step ahead of IDNA2008 was to unlock Unicode and the
Internet. This was necessary because their jobs IRT characters are
complementary, but different. This is only when the work, as
described above, has been completed and validated through field
experimentation that a parallel and non conflicting parallel growth
of the Unicode and Universal Character Set for the Internet could be
pursued. This belongs to what we expect to be further documented in
IDNA2012 Best Practices.
---
Please note that all of this discussion is independent from
punycode/UTF-8. Except for the fact that I know how to support IUI
extended tables with punyplus (cf. Appeal Annexes), but not with
UTF-8 extensions (actually, the real problem is to be found here).
JFC