Stability of valid IDN labels

[LB]

sorry. I did not copy the list. Here is my answer to John.

2008/4/20, LB <lbleriot at gmail.com>:
> Dear John,
>  As I said, my view is that of @larg, a co-owner of my portion of the
>  Internet. I see my needs and your proposed solutions. That's why I
>  started arguing with Jefsey, that my needs will not be "overwhelmed"
>  by the constraints of the dominant services. And also because I think
>  that my needs are a good example of their real needs when they
>  encounter my clients.
>
>  I know it's difficult. And I have no solution (that is the role of
>  Jefsey, to document). But I need it is not worse. I need that to be
>  better. And I know that it's getting worse very quickly when the
>  solution is "more constraints."
>
>  I read but do not speak English. I use the Google translator, and I
>  read to see if it is almost readable. I will not talk much. I just
>  wanted three things:
>
>  -- Allow the needs of the French language, as the first representative
>  of linguistic diversity, not to be dismissed because our competitors
>  had rejected Jefsey. And other French and @large on this list are not
>  blocked. This seems OK.
>
>  -- Help find a solution for the PR-action after watching the debate in
>  recent years and have been attacked myself. I have some simple ideas.
>  Rather than making appealsl, I would prefer to make a Draft.
>
>  -- Push other @large and  ISOC  to participate as to whether yes / no
>  IDNA can be used or what.
>
>  I understood that the first goal of the WG in the Charter was to
>  confirm IDNA and say why you think IDNA is the only solution IETF,
>  once and for all. For the MLTF is now free to work without creating
>  confusion. And that all are in agreement - or it is IDNA is, or is a
>  different architecture for the Internet.
>
>  Thank you.
>
>  Louis.
>
>  2008/4/20, John C Klensin <klensin at jck.com>:
>
> >
>  >
>  >  --On Sunday, April 20, 2008 1:17 AM +0200 LB <lbleriot at gmail.com> wrote:
>  >
>  >
>  > > Dear Vint,
>  > > As co-owners of the Multilingual Internet (that is the French
>  > > translation for "at large"), our position is that we do not
>  > > want to depend on the constraints, because it is not known if
>  > > it will be accepted and how far they will go.
>  > > ...
>  > > John Klensin began studying why we could not do otherwise than
>  > > IDNA. This is the first thing to do.
>  > >
>  >
>  >  Louis,
>  >
>  >  The purpose of the "alternatives" effort was never to cause a rethinking of
>  > the IDNA effort, but merely to put the claimed alternatives in context and
>  > examine the tradeoffs involved.   It will move along as I have time and,
>  > more important, as I get specific input from others.  But it certainly is
>  > not the highest priority as compared to making whatever improvements are
>  > needed in IDNA.
>  >
>  >  More important, there is a discussion about IDNs that Jefsey and I have had
>  > many times.  Often we seem to be in complete agreement; sometimes I get
>  > notes that appear to indicate that we are not.  I find the combination
>  > bewildering, to put it mildly, because I don't see the difference between
>  > the discussions in which we agree and those in which we do not.
>  >
>  >  I had assumed that those discussions had all been forward to, or accurately
>  > summarized to, MLTF, and hence that you were aware of them.  However, just
>  > in case that is not the case, let me try to summarize something that has
>  > been said many times before.
>  >
>  >  Almost no one, perhaps no one at all, who has made a serious and careful
>  > study of IDNs believes that they are, or can be, a complete solution to the
>  > many issues of getting identifiers that are culturally and linguistically
>  > completely correct.  The problems come from the DNS and its inability to do
>  > context-dependent (or, more specifically, locale-dependent) matching of
>  > strings.  One could make IDNs a little better for that purpose by making
>  > them language dependent. However, that would make them worse for other
>  > purposes and would cause complications for the many contexts in which
>  > non-words (e.g., strings with embedded digits) are used in domain name
>  > labels. There are other tradeoffs between ease of use, implementation, or
>  > deployment that might have yielded IDN answers different from IDNA (and,
>  > again, the "alternatives" document is intended to evolved into a discussion
>  > of those tradeoffs), but none of them solve the multicultural problem --
>  > some are just a little better or a little worse than others for that
>  > purpose.
>  >
>  >  Instead, real progress on culturally-sensitive identifiers requires moving
>  > completely out of the DNS context and into a context in which use (and
>  > storage, and management) of such identifiers is the primary objective.  Many
>  > of us think in terms of such efforts lying "above" the DNS, with
>  > culturally-specific identifiers (and matching rules, etc.) resolving to DNS
>  > names that, in turn, resolve to network identifiers, but a system that would
>  > be parallel to, or replace, the DNS is plausible (at least in principle --
>  > the deployment issues associated with getting from "here" to "there" are
>  > very serious and complex).  But whether those other efforts are
>  > complementary to the DNS or instead of it, IDNA needs to work as well as
>  > possible for the job of representing DNS-based identifiers in a broad range
>  > of scripts.  Jefsey has encountered, and you will encounter, considerable
>  > resistance if you come to a mailing list or WG with a mission of improving
>  > IDNA and say "you should be addressing this other issue instead" or "don't
>  > do any thing more with IDNA until you have addressed our issues".  "IDNA
>  > won't solve this particular problem" is more relevant, but most of us
>  > already know that -- you don't need to convince us because we are already
>  > convinced (for some class of problems) and trying nonetheless wastes
>  > everyone's time.
>  >
>  >  best,
>  >    john
>  >
>  >
>  >
>  >
>
>
>
> --
>
> LB
>


-- 
LB