At 07:50 26/10/2011, Yoshiro YONEYA wrote:
Dear all,
I submitted a preliminary mapping document as an individual (no hat).
I'd like to discuss this topic at Taipei.
Dear Yoshiro,
Being only an IETF user I cannot afford attending its meetings. Here
are some IDNA2008 remarks on the concerned topic.
1. Lack of a presentation layer
The reason as to why IDNs and Internationalized strings support takes
so long is that it is supposed to be the job of an OSI presentation
layer, which is absent from the Internet.
1) The IDNA concept and IDNA2003 were based upon a presentation layer
patch that did not scale the number of scripts, language specifics,
and time (Unicode new versions) very well.
2) IDNA2008 has only partly uncovered, introduced, and implemented
the very rich non-OSI way that the Internet supports presentation services.
2. The solution is to be RFC 1958 conformant.
As a result, there are three, RFC 1958, well defined issues:
2.1. Single network encoding
RFC 1958:3.2: "If there are several ways of doing the same thing,
choose one. [...] Duplication of the same protocol functionality
should be avoided as far as possible". This means how to make the
IDNA2003 and IDNA2008 transition and coexist within end to end
Internet protocols. The response is RFC 1958:3.5 "Keep it simple.
When in doubt during design, choose the simplest solution."
This is why IAB's RFC 6055 "explores issues with Internationalized
Domain Names (IDNs) that result from the use of various encoding
schemes such as UTF-8 and the ASCII-Compatible Encoding produced by
the Punycode algorithm. It focuses on the importance of agreeing on a
single encoding and how complicated the state of affairs ends up
being as a result of using different encodings today."
2.2. Orthotypography
RFC 1958:5.4: "Designs should be fully international, with support
for localization (adaptation to local character sets). In particular,
there should be a uniform approach to character set tagging for
information content." This means that the support of linguistic
orthotypography, i.e. scripting syntax, is mandatory (French, Latin
language, PRECIS mapping, etc.).
However, IDNA2008 could not support it on an end to end basis - RFC
1958:4.3: "Public (i.e. widely visible) names should be in
case-independent ASCII. Specifically, this refers to DNS names, and
to protocol elements that are transmitted in text format."
Therefore, it must be addressed differently - RFC 1958:3.6
"Modularity is good. If you can keep things separate, do so." and RFC
1958:2.3: "Everything else should be done at the fringes.": the
response is carried out by fringe to fringe modules. This is the
enormous power of IDNA2008: to address (linguistic, application,
etc.) diversity by (local, contextual) subsidiarity.
2.3. Scalability
RFC 1958:3.1: "Heterogeneity is inevitable and must be supported by
design"; RFC 1958:2:1: "The community believes that the goal is
connectivity, the tool is the Internet Protocol, and the intelligence
is end to end rather than hidden in the network."; RFC 1958:3.3: "All
designs must scale readily to very many nodes per site and to many
millions of sites".
This means that the whole "IDNA" architectural concept is to be
reviewed in order for it to be simple, orthotypographic, and scalable
fully using IDNA2008 to address the heterogeneity of the linguistic diversity.
3. Consequent need
Without considering any other context and technical opportunity, this
means that the IDNA2008 should modularly support orthotypography on a
fringe to fringe basis so as to readily scale to very many nodes,
many millions of sites, and many billions of kinds of
(orthotypographic) use. The IDNA2003 fringe is stringprep, which did
not scale. IDNA2008 puts punycode at the fringe: therefore, punycode
has to transparently scale, and punycode can transparently scale.
3.1. Algorithmic solution
How to make punycode scale? RFC 1958 says nearly everything:
RFC 1958:6.1 "All designs must fit into the IP security
architecture". RFC 1958.6.2: "the primary responsibility of the end
users to protect themselves." - RFC 1958:6.5. "To ensure
interoperation between endpoints [] one algorithm (or suite of
algorithms) should be mandated to ensure the ability to negotiate a
[] context between implementations. Without this, implementations
might otherwise not have an algorithm in common and not be able to
communicate []." RFC 1958:3.8: "Avoid options and parameters whenever
possible. Any options and parameters should be configured or
negotiated dynamically rather than manually"
- punycode is to be enhanced into a "punyplus" strictly punycode
conformant algorithm, with (an) extension(s) to be defined.
- so it may optionally support applications' orthotypographic needs
(upper-cases, variants, etc.) in a simple, dynamic manner.
- this must be kept transparent to IDNA2003 and non-enhanced punycode versions.
3.2. Architecturally stable framework solution.
The rest is to be deduced from the above requirements: the simplest
manner to obtain this and to answer the pertinent questions raised by
the Applications AD (Lisa Dussault) after the WG and ITEF/LC is to
embed that "simple dynamic manner" in order to serve multi-level
applications into an IDNA2008 multi-level service. RFC 5895
exemplifies one of them. The term "ML-DNS", standing for multilayer
DNS front-end service, generalizes the concept.
Once you have accepted this, you see that there still is a lot of
architectural work, but that this architectural work:
1. is orthogonal to the "punyplus" design.
2. will only better house and protect the punycode/punyplus function.
4. Implementation
4.1. Conceptual clarification
RFC 1958:4.2 "A single naming structure should be used."
RFC 1958:3.12: "All specifications should use the same terminology
and notation, and the same bit- and byte-order convention".
This means that the priority should be to unify DNs and IDNs into a
single Internet Domain Name System (IDNS) that could interoperate
with other technologies' DNS and be documented simply and by using
the same terms and models.
4.2. Intertesting
RFC 1958:3.14 "And perhaps most important: Nothing gets standardised
until there are multiple instances of running code."
The whole issue should be tested. This means that once the current
WG/PRECIS, happianna, ICANN variants, IAB and IUCG inputs are
gathered (RFC 1958:3.7 "In many cases it is better to adopt an almost
complete solution now, rather than to wait until a perfect solution
can be found"), it should be the right time to document an experiment
on an architectural framework at a fringe IDNs use Interface (IUI)
that is able to support the multiple IDN layers (ASCII, UTF-8,
with/without uppercase, etc.) that are actually being discussed.
However, an "intertest" charter, i.e. the terms and conditions for
the community to use the Internet as the test-bed of its own
evolution, should be crafted first based on RFCs and ICANN/ICP-3
various lists of constraints.
jfc
--
Yoshiro YONEYA <[email protected]>
Begin forwarded message:
Date: Mon, 24 Oct 2011 03:09:24 -0700
From: [email protected]
To: [email protected]
Subject: I-D Action: draft-yoneya-precis-mappings-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Mapping characters for PRECIS classes
Author(s) : Yoshiro YONEYA
Filename : draft-yoneya-precis-mappings-00.txt
Pages : 9
Date : 2011-10-24
Preparation and comparison of internationalized strings
("PRECIS")
Framework [I-D.ietf-precis-framework] is defining several classes of
strings for preparation and comparison. In the document, case
mapping is defined because many of protocols handle case sensitive or
case insensitive string comparison and therefore preparation of
string is mandatory. As described in IDNA mapping [RFC5895] and
PRECIS problem statement [I-D.ietf-precis-problem-statement],
mappings in internationalized strings are not limited to case, but
also width and/or delimiters are taken into consideration. This
document considers mappings other than case mapping in PRECIS
context.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yoneya-precis-mappings-00.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-yoneya-precis-mappings-00.txt
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
