Dear John,<div>Sorry, but I am travelling to and have a poor vision of my screen. I hope that this mail will make sense as I can hardly edit my text.</div><div><br>The point is that you assume that characters bijectively fold. This is not the case. "é","è", "ê", "ë" and "e" fold the same: as the same unicode "E". <br>
<br>2009/2/18 John C Klensin <<a href="mailto:klensin@jck.com">klensin@jck.com</a>>:<br>>> --On Wednesday, February 18, 2009 03:30 +0100 JFC Morfin<br>> <<a href="mailto:jefsey@jefsey.com">jefsey@jefsey.com</a>> wrote:<br>
>> At 01:10 18/02/2009, John C Klensin wrote:<br>>><br>>> Dear John,<br>>> We are not talking here of mapping on the registration side,<br>>> but in the naming policy; to be voted by the ".fr" ccTLD BoD -<br>
>> or the French Parliament, since ".fr" is legally delegated as<br>>> a public service.<br>>><br>>> The actual way this will be implemented will then be a<br>>> different question.<br>
>><br>>> The position can either be for the Gov to publish an RFP<br>>> calling for an alternative solution to IDNA, or for users to<br>>> develop it and use it with broad support. I think the<br>>> consensus will be pragmatic: "confusion starts from the very<br>
>> mistyping".<br>><br>> I was writing from the standpoint of the implementation<br>> pragmatics, rather than from that of the process by which the<br>> decision would be made, so we had a slight miscommunication.<br>
> However, I am also assuming that France would be unlikely to cut<br>> itself off from the global Internet by adopting a protocol<br>> "alternative to IDNA" that would require specialized<br>> implementations of browsers and other application software and<br>
> perhaps specialized implementations of the DNS --<br>> implementations that would not interoperate in predictable ways<br>> with the software used elsewhere in the world.<br>><br>> But your explanation makes part of the point I was trying to<br>
> make to Mark and Andrew: if something we do constrains an<br>> implementation past the point that the implementers (or relevant<br>> policy-makers) consider acceptable, we will see "solutions" that<br>
> cause far more "massive" interoperability problems than a mere<br>> few mismatched characters, even if those lead to false<br>> positives. If we treat a pair of characters that might be<br>> considered the same as distinct,<br>
<br>They are distinct as lower cases, the same symbol (not the same character) as upper cases.</div><div>The whole internationalization doctrine has this problem of not differentiating between the symbol and the character.<br>
<br>> then the registry (and policy<br>> makers) have all three possible options: using matching<br>> registrations to treat the pair the same way, using variant<br>> blocking to be sure that only one is registered, or treating<br>
> labels containing the two forms as distinct. It is rationale<br>> to hope that set of choices gives the decision-makers enough<br>> flexibility to avoid their deciding that there is no reasonable<br>> choice other than to, e.g., creating a DNS variation that would<br>
> do server-side matching in a way precisely adapted to French<br>> needs. By contrast, if we did the mapping and made a choice<br>> that was unacceptable, the odds of the sort of RFP you describe<br>> are obviously increased.<br>
><br>>>> > and another possible meaning, which is "expanding to match<br>>>> > other characters, and registering those _too_? For instance<br>>>> > the example that Jefsey provided is just <a href="http://xn--cole-9oa.fr">école.fr</a> and<br>
>>> > <a href="http://ecole.fr">ecole.fr</a>, which could easily be resolved by registering<br>>>> XÀole.fr also whenever <a href="http://xn--cole-9oa.fr">xn--cole-9oa.fr</a> is registered.<br>>><br>
>> Unfortunately, this proposed procedural patch<br>>><br>>> 1. does not make sense since <a href="http://ecole.fr">ecole.fr</a> is already registered<br>>> (actually in this case reserved) and a decision MUST be taken.<br>
>> As for probably a million of other accentuated domain names).<br>><br>> Without expressing a position as to whether it would be wise or<br>> not, practical or not, this is consistent with the reasons why<br>
> many domains have created sunrise or similar mechanisms to aid<br>> with the introduction of new facilities such as IDNs. And<br>> decisions about the relationship between IDNs that contain<br>> decorated characters and the base label string (with only<br>
> undecorated ones) will have to be taken in every domain that<br>> uses Latin characters and introduces IDNs.<br><br>This decision is simple: unicode or not unicode, the language or the keyboard, internationalisation or multilingualisation. The problem is not related to IDNA but to decades of an erroneous internationalisation strategy. <br>
<br>However, the solution is not simple. Yet to force people against their right and will is not a good solution because it is not stable.<br><br>>> 2. is not legally acceptable:<br>>><br>>> --- "école" means school;<br>
>> --- "ecole" can be a TM: ex. <a href="http://www.defl.ca/fr/ecole.html">http://www.defl.ca/fr/ecole.html</a>.<br>>> For other terms the accentuated and the non-accentuated terms<br>>> are different words or TMs.<br>
><br>> Here is where you confuse me, or perhaps we confuse each other.<br>> Because of its exact-match properties, the DNS (with or without<br>> IDNs) is notably unsuited to a "do what I mean" function. I am<br>
> probably misunderstanding you, but it appears from the above<br>> that you are expecting a system that will cause the same pair of<br>> labels to be treated as matching under some circumstances and as<br>> not-matching in others. <br>
<br>In your terms, yes. In French terms, no. </div><div><br></div><div>The problem is that "your" approach is based on internationlization (i.e. internationalising English ASCII as a reference) not on multilingulalization (each language/script being its own reference). <br>
<br>I do not claim there is not an internationalization impossibility, only that so far it was not found. And I fear that when looking for a solution French engineers, lead users and users will look more for a multilingualization than an internationalization solution. This would technically divide the Internet. Giving the French solution the ability to support multilateralization as a general feature. We both know the outcome: that French internet would have a presentation layer.<br>
<br>>I don't know how to do that in the DNS<br>> or in any conceivable IDN protocol that rests on top of it.<br><br>This is the question to be answered. I do not have a global solution either, and this is why I suppose that no-case folding might be the most acceptable patch. But the decision of accepting that patch is not mine: it belongs to the market and to the French national communities. <br>
<br>>> --- "Ecole" will usually mean a national school.<br>>> --- "schule", "scola", etc. are valid terms from French<br>>> languages that would not suffer the constraint. This would<br>
>> create an anti-competitive commercial image imballance.<br>>> --- There is "<a href="http://ecole.gouv.fr">ecole.gouv.fr</a>" which will oblige to a documented<br>>> legal terminology decision.<br>
><br>>> 3. would violates the French language and people's equality. I<br>>> do not see it being legally and technically accepted just<br>>> because the IETF did not find a solution.<br>><br>> I don't understand how one can have a reasonable expectation of<br>
> both "A" and "not-A" being true at the same time, which your<br>> comment appears to require unless the situation is to be treated<br>> as unfair and anticompetitive. <br><br>The problem lies with case-folding being accepted in the DNS technology while the impact of case-folding has not been considered enough.<br>
<br>> That would make simple<br>> first-order logic unfair. Perhaps it is, but I don't know quite<br>> what to do about it. Even without IDNs, if I obtain a label in<br>> a particular domain that you think you would like because it<br>
> bears some relation to your business, you may reasonably believe<br>> that my having it is anticompetitive. <br><br>We misunderstand. What is anti-competitive is that people not born with accentuated names or whose name is not challenged by accentuated names have not a problem others have.<br>
<br>>But, if you were able to<br>> take it away from me, I would probably consider that act<br>> anticompetitive for the same reason. There is no way to win in<br>> such a competition. <br><br>Yes there is at least one : not to create an artificial problem in forcing a language to follow the rules of another one. Please remember that this problem is not related to IDNA but to a wrong doctrine (internationalization) and to the resulting rough AZERTY standard (one could imagine solutions, but that would call on a wide debate of the francophonie).<br>
<br>> Instead, societies invent rules that permit<br>> one entity to use the name and the other to not do so or perhaps<br>> for neither to use the name. This is really no different, or<br>> so it appears to me.<br>
<br>Yes. But that rule has to be proposed, debated, voted, and accepted. Before doing just that, people will want to know about the reasons why, about a plan B, and give a try finding a solution.<br><br>I do not think that "because of Unicode, AZERTY keyboard, and IETF" will be accepted as a good reason enough. I may be wrong, but I would be surprised this would not lead to a de facto francophone internet replication. Moreover that DNS is at the boarder between Internet and Intersem (semantic network). I hardly see French speakers removing accentuated terms from French (and the same for many other languages) just to please the ASCII computers ?<br>
<br>Best<br>jfc<br></div><div><br></div><div>PS. You seem to imply that I would consider challenging IDNA. I recall you that my whole effort is precisely the opposite. To build a better architecture to include and enforce IDNA (and to extend it when needed/possible). This is why I urge this WG to proceed, because we need the IDNA solution to finally settle before we can build around/on top of it and stay fully interoperable.</div>
<div><br></div><div>This results from this WG which plainly answered that it did not intend to develop the solution we need. And this is why I made located within the IETF the lead user architecture that could consider that extension, based upon some different premises than this WG. After the Chair of this WG said it would be plain IETF spirit.</div>
<div><br></div><div>I recall you that I wrote a Draft on this (the system currently does not accept) to investigate how this user approach of mine would be the best way to deploy the IETF propositions such as IDNA and IPv6.</div>
<div><a href="http://iucg.org/drafts/draft-iucg-innov-dep-strat-00.txt">http://iucg.org/drafts/draft-iucg-innov-dep-strat-00.txt</a><br></div><div><br></div>