FW: Your statement on Identifiers and Unicode 7.0.0

[JFC Morfin]

Dear John,

Thank you for this response. The whole thing would indeed call for a
much longer review that does not belong here ***IF*** RFC 5895 is
taken out of the IDNA issue. As I consider that IDNA2008 only reached,
and stands through, the consensus we found over the RFC 5895 concepts,
my only interest is to know if what we are going to do in order to
solve our UNICODE difficulties:

1) does not infringe upon the existing RFC set.
2) is understood enough in here for you to document the general
internet precautions that our permissionless innovation testing could require.

In this, we only respect the demands that the RFC 6852 modern paradigm
participation require. Prior to beginning experimentation, we will
incorporate and our company will officially endorse the OpenStand
principles that are now the reason why I had to appeal RFC 6852 so
that it can be clarified.


At 19:37 05/02/2015, John C Klensin wrote:
>As the first person to have posted a proposal for a CLASS-based
>system for IDNs, when I read your suggestions, I don't believe
>you understand the implications and limitations of that approach
>even as well as I did then, much less as well as I do now.  In
>particular, from an i18n standpoint, the many issues with
>comparison and equality that have become major topics of
>conversation in recent years (with the current issue about
>non-decomposable code points being a fairly minor example)
>suggest that a different Class would do almost nothing to
>eliminate the need for character and string canonicalization
>("preparation").  From a DNS technology perspective, the point
>at which a different Label Type would be needed, not just a
>different CLASS is not easily identified and described.  New
>CLASSes have, in practice, proven hard to deploy broadly.  New
>Label Types are much worse -- so much worse that one of the DNS
>WGs approved a proposal to depreciate them entirely, eliminating
>the possibility of any additional ones, a few years ago.

Since January 8, 2015 we have identified different technology referents.

You're citing a proposal, about which the IETF has apparently lost
interest in not making it an RFC, is useful, but it feels a little
misleading to me (cf. below :-)). More seriously, a few years ago the
IESG published the IDNA2003 RFCs: sometimes it is good to review what
was done a few years ago.


>As to ICP-3, while I've got a personal copy that I just checked,
>I can't even find it any more on ICANN's web site.

<http://archive.icann.org/en/icp/icp-3-background/lynn-statement-09jul01.htm>http://archive.icann.org/en/icp/icp-3-background/lynn-statement-09jul01.htm


>General
>searches find a copy of Stuart Lynn's statement about it, but
>the links in that statement that are supposed to point to the
>document itself are all broken and a search for "ICP-3" on
>ICANN's site turns up nothing.

https://www.icann.org/search/#!/?searchText=ICP-3


>I'll leave it to you and others
>whether your citing a policy document about which the
>organization that created the policy has apparently lost
>interest is useful, but it feels a little misleading to me.

I accept that you do not like ICANN and that they have lost interest
in what is useful.

You are correct that their document is misleading when it seems to
contradict RFCs. But you have to read carefully what it actually says.
We adopted it as a working reference because it seems to be of
pertinent common sense in terms of experimentation precautions. Brian
Carpenter also wrote interesting things.

Prior to Jan 8, 2015, we would have proposed an RFC. Now we will
publish an experimentation charter. I would suggest a common OpenStand
work on the issue, as I suppose permissionless coopetitive innovation
may multiply this kind of situations.


>More important, I can see nothing in ICP-3, a discussion about a
>unique DNS root, that could be used to support your statement
>unless you are referring to the statement that starts "None of
>this precludes experimentation done in a manner that does not
>threaten the stability of name resolution in the authoritative
>DNS....".   It does not appear to me that you are proposing an
>experiment of that sort.  Perhaps I'm incorrect.

Good. This is the point I wanted to be sure about.

We do not want to introduce any disruptive innovation, just one which
addresses our user needs. But one never knows. This is why it is
better to inform, explain, and ask.


> > We are ***not*** considering a writing system, but a printed
> > sign system for a single purpose: ID/naming non confusability.
>
>Ok.  There have been a number of attempts to design unambiguous
>symbol systems for various purposes over the centuries.  They
>are certainly feasible even though all of the successful ones of
>which I'm aware have very small symbol repertoires.  They also
>have little or nothing to do with internationalization.  The
>thing that makes internationalization important, useful, and, by
>the way, hard, involves trying to accommodate the huge diversity
>in human languages, writing systems, and ways of forming
>mnemonics.  If you are going to focus on a new symbol (or sign)
>system, that may be entirely worthwhile, but it has nothing to
>do with the present issues any more than attempts to solve
>language and communications problems with invented languages
>like Esperanto have to do with issues in communication and
>writing in modern French.

This is your opinion. Ours is different. The only point of
consideration is that our experimentation does not disturb the
existing operations.


> > There are five layers involved.
> > - an unchanged DNS use, operated in CLASS "FL" (Free/Libre)
> > implying any DBMS being used by nameservers.
>
>See above.   And no.  Because a new CLASS requires either
>significant modifications to existing root servers or a new set
>of root servers and many existing tools (including most or all
>existing resolution libraries) seem to assume CLASS=IN,
>"unchanged" is impossible and "any DBMS being used by
>nameservers" is at best unrealistic.

I hear you.

For the reason that some do not respect RFCs, you consider our project
unrealistic. You know the IETF and te Internet technical community
better than me: if this is really the IETF technology's deployment
status, it is sad news. It would imply that before any enhancement we
really need to refurbish a few software programs!

This is the interest of accessing the source code.


> > - the list of accepted character signs.
> > - the non-confusable visualization of these characters.
> > - the list of corresponding UNIGRAPH code points
> > - a fringe to fringe punnycoding/decoding for the CLASS "FL"
> > DNSLIB root zone.
>
>While you might be able to apply the Punycode algorithm to the
>code set for your signs, it would almost certainly be a bad
>idea.  Punycode provides a reasonable, perhaps optimal, encoding
>for a rather large (over 2&20) code set with certain local
>compactness properties.   If you are going to have a repertoire
>of non-confusable signs experience suggests that repertoire will
>be limited to a few hundred signs or fewer (unless you assume
>users will have special training in recognizing distinctions
>among signs, which the above appears to reject).  There is
>little to be gained and quite a lot of compactness to be lost
>from using Punycode.  With a repertoire of that size, you'd
>almost certainly be better off just numbering them.

I am afraid that there is some confusion about the purpose of
UNIGRAPH. This is not for anyone to learn anything. This is only to
protect machines from cheaters.


>Finally, if you were going to build and use a coding system like
>that but still wanted to use the DNS, you don't need a new CLASS
>or other specialized arrangements.  Just find an appropriate
>subtree, put the labels in it coded however you like (I'd
>recommend using only octets with the high bit turned on to avoid
>the DNS's ideas about ASCII-range case matching) and assume that
>the "any octets" discussion of RFC 2181 will provide you with
>all the DNS facilities you need.   Or, if you conclude that you
>next something ASCII-compatible, there are far less complex and
>more compact approaches than the Punycode for small repertoires.

The use of the test "FL" CLASS is only for "IN" CLASS tidiness
protection. In a "permissionless innovation" coopetitive
"post-status-quo" context, I think it is advisable to separate the
intertest area from the internet operations. This is what we learned
from ICP-3.


> > Please explain where is a possible impossibility.
>
>I was concerned about natural languages and associated writing
>systems, not an artificially-chosen symbol system.

Same.

We need a natural language, non-confusable natural flat reading
system, not an artificially conceived successive system.


Summary: after
- my appeal to make sure everything is OK on the Governance side,
- having incorporated
- and endorsed OpenStand
- we will work on an RFC 5895 application
- using UNIGRAPH instead of a direct use of ISO 10646,
- in CLASS "FL" supported via an HomeRoot approach
- and documented through a SuperIANA prototype
- and possibly using HappyIPs (who knows?)

As far as we understand from you - at least for the DNS issues - this
does not threaten the stability of name resolution in the authoritative DNS.

All is perfect in Leibnitz's "best of all possible worlds".

jfc