Subject: Re: [iucg] [precis] Fw: I-D Action: draft-yoneya-precis-mappings-00.txt

From: JFC Morfin <[email-masked]>
Date: Fri, 28 Oct 2011 09:00:48 +0200

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-masked]>
>
>Begin forwarded message:
>
>Date: Mon, 24 Oct 2011 03:09:24 -0700
>From: [email-masked]
>To: [email-masked]
>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 
> (&quot;PRECIS&quot;)
>    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-masked]
>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-masked]
>https://www.ietf.org/mailman/listinfo/precis