Stability of valid IDN labels
lbleriot at gmail.com
Sun Apr 20 23:28:53 CEST 2008
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.
> 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
More information about the Idna-update