[newprep] wg/newprep project: clarification asked

JFC Morfin <jefsey@jefsey.com> Wed, 19 May 2010 21:35 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: newprep@core3.amsl.com
Delivered-To: newprep@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7403A687E; Wed, 19 May 2010 14:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Level:
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_60=1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoQLypeqmcfU; Wed, 19 May 2010 14:35:44 -0700 (PDT)
Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id A24E13A67BD; Wed, 19 May 2010 14:35:44 -0700 (PDT)
Received: from 12.135-225-89.dsl.completel.net ([89.225.135.12]:52316 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from <jefsey@jefsey.com>) id 1OEqvP-0001VN-8W; Wed, 19 May 2010 14:35:35 -0700
Message-Id: <7.0.1.0.2.20100519230359.05dfd258@jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 19 May 2010 23:35:44 +0200
To: Alexey Melnikov <alexey.melnikov@isode.com>, Peter Saint-Andre <stpeter@stpeter.im>, newprep@ietf.org
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <E9728BD9-05DE-485B-B2DB-7F3D440B49E6@lindenlab.com>
References: <E9728BD9-05DE-485B-B2DB-7F3D440B49E6@lindenlab.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage2.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: iucg@ietf.org, IESG <iesg@ietf.org>
Subject: [newprep] wg/newprep project: clarification asked
X-BeenThere: newprep@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Stringprep after IDNA2008 <newprep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/newprep>, <mailto:newprep-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/newprep>
List-Post: <mailto:newprep@ietf.org>
List-Help: <mailto:newprep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/newprep>, <mailto:newprep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 21:35:45 -0000

Mark's review is clear and enlightening.

As you know, as Internet Users, we believe IDNA2008 represents 
several major achievements. One is to uncouple the Internet and 
Unicode while succeeding in using ISO 10646 Unicode generated tables. 
This is a double big step ahead:

-          giving the Internet its own independent charset.
-          advancing towards a better transtechnology/usage 
operational scripting methods unification.

However, IDNA still has to document three major issues that affect 
stringprep and definitely disqualify any further involvement of 
Unicode in the network support of strings:

-          lack of support of orthotypograhy (i.e. language script syntax)
-          the multitude of "stringpreps" functions (at least one per 
ISO 639-6 linguistic entity) that are now to be specified on the users' side.
-          how they will be administered together (what will then 
also concern "newprep")

This is why what you call "IDNA" (just what is IDNA DNS layer 
related, not what will be User layer related) also cannot qualify at 
this stage. Everything is to be discussed together; the different 
stringpreps are equivalents to additional languages with their own 
orthotypographies.

Now, as users, we have a different, more pragmatic approach that goes 
further and does not call on this endless kind of discussion. This is 
because as Internet lead users we are more interested in forward 
compatibility (i.e. with our needs, innovation, and simplification) 
than in backward compatibility (installed basis).

In a technological evolution, those who were in advance knew that 
their solution might not be final. Cf. RFC 1958: the fundamental 
Internet architectural principle of constant change. The second main 
architectural Internet principle (RFC 1958 and 3439) is the principle 
of simplicity. We are not interested in several stringprep solutions 
due to historical or partial technical analysis. We are interested in 
a stable, unique, comprehensive manner to format strings in the world 
digital ecosystem, which is currently mainly under Internet 
technology that prevents phishing and sustains a single sorting and 
indexing order.

This is our architectural target. Our implementation strategy is to 
help and use every effort that can help reaching that target, and 
oppose (IETF and real world operations) every attempt that would 
confuse or delay it.

This is because our main interest is not so much to "influence those 
who design, use, and manage the Internet for it to work better", 
(without a definition of what "better" may means RFC 3935is 
meaningless anyway); our main interest is for us and our partners to 
best use the Internet to better suit our common and present-day 
needs. This SHOULD be the same. However, experience has shown that it 
MIGHT not always be the same.

This is why the best is to clarify this issue from the onset. I was 
not responded to when we started the WG/LTRU on langtags and I had to 
force the consensus the way we know. I was very clearly responded to 
in the case of IDNA and we were able to fully support the consensus.

---

My question is therefore:

-          "a need is identified by our Internet user contributing 
party. This need is for a stable, unique, comprehensive manner to 
orthotypographically format prepared strings whatever the script and 
language. Such a format must prevent phishing and support a single 
registry indexing and sorting order of every possible 
orthotypographic string, throughout the Internet protocols, related 
applications, and interoperated technologies.
-          Is this or is this not also an immediate or ultimate goal 
for the AD, WG Chair, and WG/newprep possible participants?"

Depending on the response given, we will participate and try to help 
this wg/newprep effort, or we will pursue our own project, with the 
ambition to address our needs while keeping things as interoperable 
with newprep-like endeavors as is possible.

I thank you for your time, attention, and response.

jfc

At 17:56 19/05/2010, Mark Lentczner wrote:
>It should be noted that *all* approaches induce standards coupling 
>with Unicode itself, though that is, I think, a clear aim of this 
>group. Unicode as a whole has many different stability guarantees, 
>of various levels, and I believe it is quite reasonable to choose 
>which parts of Unicode to couple to in order to achieve the aims 
>needed by IETF protocols and human nomenclature.
>
>While I think the above discussion reveals I lean toward the UAX #31 
>approach, I'm eager to learn what others think of these approaches, 
>and ideas for other ways to proceed.
>
>- Mark