Subject: [newprep] Directions for a Framework

From: Mark Lentczner <[email-masked]>
Date: Wed, 19 May 2010 08:56:20 -0700

Charter issues aside, I'd like to share some thoughts about possible directions for a new framework (which would be one way address the current stringprep users):

Like stringprep, I imagine that such a framework should be limited in scope to address strings that are chosen by humans, typed by humans (at some point), but then need to be used as tokens within protocols. The aim is that when two humans enter what they believe to be the same string, the resulting prepared strings can be compared identically character by character. It is expected that different protocols using such a framework would need to adapt it to their needs, notably adjusting the set of acceptable characters primarily for syntactic reasons.  (I.e.: one protocol might need to exempt U+0040 COMMERCIAL AT ('@') because that is a separator in the protocol. Another protocol might be fine with that character, but need to exclude U+007C VERTICAL LINE for similar reasons.)

In the exploratory work I did (reported here earlier), I found there were three potential ways forward:

1) Build a stringprepbis along the same lines as stringprep, but defined in terms of Unicode properties. This would insulate it from being tied to one version of Unicode, while keeping it essentially the same.

2) Build a framework based on UAX #31. UAX #31 already is a framework, though it is admittedly looser in approach than stringprep. An IETF framework based on UAX #31 would probably settle on the basic method (UAX #31 has at least two), and reduce the set of options available for profiles to something closer to stringprep's mix-n-match approach.

3) Abstract out IDNA2008's work into a new framework. This would require generalizing the work in IDNA2008, as it is defined in light of IDNA2008's specific identifier needs. (For example, the restriction to lower case is incorporated into several of the other character tests.)

As I found, the second and third approaches are much more aligned (given UAX #31 as of Unicode 5.2, and given a conceptual generalization of the IDNA2008 approach), than the first. The stringprepbis approach would need significant work to incorporate the understanding gleaned from the original IDNA and work of the IDNAbis WG.

Between the second and third, the second would be less work (as the bulk of it is in UAX #31), but the third is likely to match IDNA2008 more closely (perhaps to the point that practically, implementations could implement IDNA2008 as a profile of the new framework.) 

Either of the later two approaches induces standards coupling: Either with UAX #31 or with IDNA2008. UAX #31 does have significant stability guarantees, and is intended for this kind of use. IDNA2008 expressly decided not to build a framework and so the third approach would either have to depend on the wording of IDNA2008 in a way it wasn't intended, or duplicate the work, and either track it or risk divergence. A particular issue with either are the "contextual checks", which both have, and can be considered a moving target.

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

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: JFC Morfin <[email-masked]>
Date: Wed, 19 May 2010 23:35:44 +0200

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 May 2010 13:01:30 -0400

On Wed, May 19, 2010 at 11:35:44PM +0200, JFC Morfin wrote:
> 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?"

I can't speak for anyone else, but I don't think it's my goal (because
I don't believe it to be realistic).  In particular, any plan that
contains as a stated goal "prevent phishing" is IMO just a plan to
tilt at windmills: con artists have been around at least as long as
human language, and I don't think we are likely to form a WG that will
completely prevent their craft.  Moreover, universal quantification in
the face of the possibility operator has at best difficult semantics,
and I'm therefore not at all sure I understand what "every possible
orthotypographic string" would be.

Stringprep has some practical issues, and my impression is that the
plan is to try to address those.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: jefsey <[email-masked]>
Date: Fri, 21 May 2010 17:21:42 +0200

At 19:01 20/05/2010, Andrew Sullivan wrote:
>I don't believe it to be realistic).

Dear Andrew,

>In particular, any plan that
>completely prevent their craft.

Preventing is not impeaching. I am quoting a user need and target. 
The level of prevention can only result from an international 
standard (ISO) consensus. The technical side is not, IMHO, to decide 
of what phishing prevention requires, but to technically support the 
requirements from concerned parties, ranging from linguists to banks, 
Govs, etc.

>Moreover, universal quantification in

Definition is with grammarians, semantitians and terminologists. Our 
job is to provide them with tools to support them.

>plan is to try to address those.

What is stringprep the first question, then what are its practical 
issues. Either you try to define stringprep from its past variations 
and you try to addapt to them. Or you try to define a unique solution 
to address stringprep kinds of uses and adapt current stringprep in 
using that unique solution. As an Internet User I am more interested 
in the latter approach. That is all.

Best.
jfc