Dear Lisa,<br><br>It took a few days for france@large to consider all your mails in attachment. We found that they raise three fundamental problems that have not been discussed yet but that now needs to be addressed prior to any publication of the IDNA2008 documentation set. <br>
<br>These problems are the network neutrality, security, and operative independence that are to be enhanced or at least respected when introducing IDNA2008. However, IDNA2008 is Internet neutral; it can be tested, introduced, and supported in a non-neutral manner. IDNA2008 is both a protocol and architecture. The protocol security aspects are covered in the current security section, but the architectural security aspects are not discussed.<br>
<br>Moreover:<br><br>- IDNA2008 represents a substantial technical progress of the Unicode globalization towards a Multilingual Internet (represented for example by an independence from a Unicode specific version and reduced mapping at protocol level). This means a better support of specific namespaces that currently are, can be operated, or are to be built, outside of the area of ICANN's governance (as prepared by the ICANN ICP-3 document, france@large has applied through a two-year community test). This in particular includes non-IDNA presentations, non class "IN" classes.<br>
<br>- RFC 3935 assigns the IETF with the responsibility for a much broader Internet than the ICANN footprint, i.e. "A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it. The term includes both the "core Internet" (ISP networks) and "edge Internet"(corporate and private networks, often connected via firewalls, NAT boxes, application layer gateways and similar devices). The Internet is a truly global network, reaching into just about every country in the world. The IETF community wants the Internet to succeed because we believe that the existence of the Internet, and its influence on economics, communication, and education, will help us to build a better human society."<br>
<br> We do not have the time, technical capacity or experimental background now to tackle this issue at an IETF standardization level. However, the IETF MUST make it clear that if the resolution of IDNA operational and architectural issues is delayed and possibly delegated to ICANN's (*) IDN Guidelines Committee (cf. WG Chair 19 December 2009 mail) or is assumed by the IUCG open special interest group for an IDNA2010 BCP on the implementation, transition, and deployment of IDNA2008 ( <a href="http://idna2010.org">http://idna2010.org</a>), some principles must be clearly and consistently spelled and be respected by these entities because they belong to the IETF rights, duties, and values. The first of them is that these entities must be open to any interested individual.<br>
<br>- The WG/IDNABIS Charter states: "It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions." At the WG/IDNABIS, we considered the technical exceptions within the protocol definitions and minimized them. However, there are other exceptions that may arise in the protocol experimentation, deployment, and various applications that can lead (as you have yourself noted) to conflicts on the same user machine, within the same usage, the same application or the same network governance area. Our mission is to document how to avoid such technical, security and operational problems or to list them in the security section with the principles that should be followed in order to best protect Internet Users. <br>
<br>- The WG/IDNABIS Charter also states: "The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system". This is true at every level of the DNS: this is also true for the first level. This means that this WG must ensure that its document set and its consequences are not possibly used to disturb the current use and operation of the domain name system at architectural, security, and operational levels. This is not the case. The documents should at least include the mention of these risks, and how they should be defeated or that further work on the issue is to be carried. <br>
<br>- The IETF is not involved with the "current use and operation of the domain name system", except for one major exception. This exception is the management of the IANA registry. This is described in RFC 2860 and RFC 5226 (which obsoletes RFC 2424). There are two main cases involving the IETF's direct responsibility to the point where it can exercise its ability to cancel the IETF/ICANN MOU:<br>
<br>---- in case of experimentation by ICANN and/or IETF<br>---- in case of a conflict between the standard and the way ICANN applies an IETF standard.<br><br><br>There are non-ICANN entities which may de facto or legally share or assume the IANA's role to the legitimate benefit of some IDN internet communities; they will be called IDNO (IDN Organizations).<br>
<br>There are expressed concerns and demonstrated situations where ICANN, or other IDNO, that the current use and operation of the domain name system might be disturbed. There are three classes of (possible) situations where this happens:<br>
<br>- the lack of distribution equilibrium between the kind of potential difficulties to experiment, analyze, and address that is due to the limitations imposed by ICANN to participate in its experimentation which is restricted to non-roman IDNccTLDs. It is to be expected that most of the new difficulties to experiment will be located<br>
<br>---- at IDNgTLDs along with more innovative uses and the lack of a governmental authority to sustain their naming policy,<br>---- at bidi TLDs, <br>---- and at roman TLD where the orthotypography is not fully supported (as Latin language TLDs, and especially French). <br>
<br>- These TLDs MUST either be a part of the ICANN experimentation on an equal footing basis, or an IETF sponsored complementary experimentation should be organized by adding a batch of experimental TLDs in the root file towards to warranty an equal chance of access to experimental operations and sales, on a first come first serve basis (**).<br>
<br>- the commercial discrimination that is imposed by ICANN’s internal rules between candidates to IDNg/ccTLD on IDNA and root capacity related technical grounds (after two years of an official public campaign denying such limitations and an offer to register gTLD candidates (with 500 candidates being persistently rumored)). This is in clear contradiction with the WTO rules and the international agreements concerning the Technical Barriers to Trade. Due to the RFC 5226 (2424) on the "first come, first serve" principle in IANA registration and the RFC 2860, the IETF could find itself involved in a lengthy international commerce case that could affect the credibility of its international responsibility capacity and further delay IDNs for years to come.<br>
<br>- new Internet architectural readings, such as "Interplus", which was introduced by the IUCG, based upon IDNA2008 findings. This WG should add in the security section that this potential risk has been identified, the IUCG was requested to document "Interplus like" architectural frameworks, and it will rest with ICANN, IETF, and the appropriate IDNO and Internet User representations to address it.<br>
<br><br>RFC 3935 assigns the IETF with the goal to make the Internet work better: "The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds". <br>
<br>Standards are well defined in RFC 3935: "As used here, the term describes a specification of a protocol, system behaviour or procedure that has a unique identifier, and where the IETF has agreed that "if you want to do this thing, this is the description of how to do it". It does not imply any attempt by the IETF to mandate its use, or any attempt to police its usage - only that "if you say that you are doing this according to this standard, do it this way". The benefit of a standard to the Internet is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users."<br>
<br>As a result, this WG should make it clear that any derivative work where additional neutrality, security, or operational additional constraints that is based upon privately contracted situations that would not fully respect "its description of how to do it", including its principles for derivative work, might not be interoperable and, therefore, should not be attempted by ICANN and IDNA having entered into a comparable MoU with the IETF. This restriction is a consequence of the IETF RFC 2860 obligations to properly advise ICANN.<br>
<br>RFC 3935 also states: "The Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create." <br>
<br>What is discussed in this very memo shows that IDNA2008 may lead to important, yet potentially disruptive, innovations that the IETF, ICANN, IDNOs and Internet Users should collectively evaluate and canalize. IDNA2008 permits misuses that they all should oppose in unison.<br>
<br>Jean-Michel de Portzamparc<br><br>(*) The WG/IDNABIS Chair wrote on 2009/12/29 that: "It has been suggested that a better forum in which to deal with IDNA2003 and IDNA2008 incompatibility is the ICANN IDN Guidelines Committee. That may be a better forum with broader participation than the IDNABIS working group in which the TR46 proposal or other proposals may be discussed. If we adopt Cary Karp's offer, your observations, below, would be input into the Guidelines committee discussions." For years, none of the participants to this note has succeeded to participate to the ICANN process on an individual basis or through an ICANN constituency. <br>
<br>(**) france@large has answered the French Government pending public call for candidates to manage the ".fr" namespace (This answer has been published as a book and can be found at <a href="http://www.lulu.com/content/paperback-book/pni/7143574">http://www.lulu.com/content/paperback-book/pni/7143574</a>). As part of this response it noted its interest to manage the ".tf" TLD and to orient it towards French litterature (Textes Français). It also is one of the technical sponsors of Project.FRA and a Member of the A-FRA (<a href="http://a-fra.org">http://a-fra.org</a>). The gTLD policy published by ICANN since its Paris meeting permitted ".FRA" to start proposing French IDNs in parallel with AFNIC (".fr") even if the French Government continued to procrastinate or did not retain france@large as the operator of ".fr" or of "tf". The recent policy change introduced by ICANN, in turn procratisnating about gTLDs, gives AFNIC (.fr) an unfair advantage in deploying French IDNs. Moreover if French language orthotypography is not properly supported. Repeated documented requests and a pending I_D on the way to support them (<a href="http://www.ietf.org/id/draft-iucg-punyplus-03.txt">http://www.ietf.org/id/draft-iucg-punyplus-03.txt</a>) was systematically ignored by the Chair and you.<br>
<br>Project.FRA has a three phase deployment plan:<br>A. free test ULD (user level domain) in Interplus class IU (Internet Users) <br>B. non-profit non-free ULD zone in class IU<br>C. non-profit commercial IDNgTLD also in class IN and IU.<br>
<br>Phase A is now in pre-operations. Phase B will be initiated as soon as the IDNA2010 BCP on the implementation, transition, and deployment of IDNA2008 is completed. Phase C should have been initiated as soon as ".fra" is in the ICANN Root file as a regular gTLD. Its purpose is to pay for the Phase A and B voluntary and experimental project. <br>
<br><br> ----------------------------------------<br><br>At 21:33 01/12/2009, Lisa Dusseault wrote:<br>One example I discussed with Patrik yesterday, was whether locale<br>might affect mapping. I'd like to get better insight into the general<br>
understanding of that.<br><br>1. Could locale determine whether a PVALID character should be mapped<br>into another PVALID character prior to following the rules to turn<br>into an ALABEL? I believe the consensus answer is probably SHOULD NOT<br>
or MUST NOT because that would make domains with that valid character<br>unreachable by software using those locale rules.<br><br>2. Could locale determine whether, or how, a DISALLOWED character is<br>mapped into a PVALID character prior to getting an ALABEL? For<br>
example:<br> - in locale Laputa, disallowed character (x230) is not used in the<br>local language, so it's not mapped, an error occurs so a user seeing<br>that in a Web page can't reach any actual domain<br> - in locale Balnibarbi, (x230) is considered to be the same as O,<br>
so it's mapped to 'o', and a Balnibarbi user reaches domains<br>containing o's<br> - in locale Glubbdubdrig, (x230) is considered to be the<br>capitalized version of (x231) and a Glubbdubdrig user reaches a<br>
different set of domains containing 's<br><br>Note that none of these locale rules would necessarily make domains<br>containing completely unreachable to their users -- a Web page<br>containing a link with would be looked up without mapping that<br>
character to another (assuming the conclusion of point 1 above).<br><br>If I'm reading between the lines correctly, communication is hampered<br>between people who are writing under the assumption that this kind of<br>
locale-dependent scenario is going to happen, and people who are<br>writing under the assumption that this kind of locale-dependent<br>scenario ought to be forbidden and nobody would try such a crazy<br>thing.<br><br><br>
At 22:04 01/12/2009, Lisa Dusseault wrote:<br>I don't believe we know what the WG consensus position is around how<br>strongly pre-lookup mappings are recommended and in what use cases,<br>and how compatible optional pre-lookup mappings are with IDNA2003<br>
in-protocol mapping.<br><br>Agreeing with you to a large extent Vint, I believe there is a strong<br>consensus in the WG that mappings "aren't part of the protocol",<br>meaning mapping shouldn't be required in all cases. Certainly,<br>
registries shouldn't be required to automatically map any character<br>into any other character before registering the mapped domain name:<br>better to make the domain name holder be explicit about the exact<br>domain name they are registering. We have also referred to use cases<br>
involving client software doing lookup of domains that are already<br>supposed to be valid, in which context an invalid character would<br>simply be a software error rather than a situation that required<br>mapping. In this matter, we have consensus to do something different<br>
in IDNA2008 vs IDNA2003.<br><br>I believe we also do have consensus in the equivalence of A-label and<br>U-label forms and transformation in either direction.<br><br>After that it gets confusingly nuanced. We even discussed having a<br>
different term for optional, pre-lookup mapping of user-typed-in<br>domain names, including links found in HTML typed in by the HTML<br>author. I believe we do have consensus in the WG that this type of<br>helpful mapping is going to be implemented, for example in Web<br>
browsers, as being a user experience that is preferred over a dialog<br>interruption or error.<br><br>So that leaves us with a great deal of progress in IDNA2008, and a lot<br>that is decided by WG consensus, but still with a gap in our total<br>
consensus. Some people would prefer that optional, pre-lookup mapping<br>be wide open. Others would prefer would that although pre-lookup<br>mapping should be optional, IF it is done, it MUST be done one way.<br>There's even room for a middle ground where there might be more than<br>
one recommended standard set of mappings, but they should be done as a<br>matter of standardization and not as a matter of full implementer<br>discretion, if at all possible. There is room for splitting the<br>mappings territory up per-application: perhaps domains in HTTP URLs<br>
and browser address bars should be mapped one way, but other types of<br>URLs could follow "no mappings allowed" rules.<br><br>Finally, we have the options around transition strategies (such as<br>bundling recommendations) that might allow us to come to consensus<br>
regarding these optional pre-lookup mapping questions.<br><br>I appreciate all the discussion that is leading us to a better<br>understanding of the issues around those last issues, and developing<br>consensus regarding those last options.<br>
<br><br>At 16:06 02/12/2009, Lisa Dusseault wrote:<br>I'd like to try to unpack some of the different use cases we're<br>talking about a little more.<br><br>ISTM that use cases where the person following the link is the person<br>
who is typing it in, are use cases that locale-dependent mapping might<br>be most useful. If I'm in a locale where (x230) is considered to be<br>the capitalized version of o (ASCII o), it might very well be most<br>
helpful to make that mapping. Use cases where the same user is typing<br>in the domain names that then looks them up include:<br> - typing links in the address bar<br> - typing mail address in the To field of an email<br>
- Writing a Web page, blog post or email, wherein I check that the<br>links work before posting/sending my document<br><br>In contrast, the use case where the person looking up the domain<br>F .example is not the person who typed it in, then in most cases we<br>
no longer know the intent or locale of the person who typed in the<br>domain. It may be the same locale as the person who is looking up the<br>domain but it may not be. The person who typed in the domain may have<br>intended f .example or foo.example, and may have tested that before<br>
sending/posting the link, but we no longer have that information. Use<br>cases include:<br> - Following a HTTP link in any Web page, document, blog post, email, etc<br> - Using a mailto link (explicit or implicit), e.g. when one person<br>
sends me another person's email address<br><br>We probably would all agree that people follow links while Web<br>browsing far more often than they type them in, and even when typing<br>in, auto-complete probably drastically reduces the new cases of<br>
from-scratch mapping and lookup.<br><br>However, we probably have quite different assumptions about how much<br>Internet activity takes place among users of a consistent locale. Can<br>we assume that Patrik wants interpreted as because he communicates<br>
mostly in Swedish with Swedish users and mostly reads Swedish Web<br>pages? Or must we assume that Patrik also gets email from german and<br>swiss senders, and also reads Web pages (perhaps in English!) written<br>by German users who expected different mappingsH[H H\™\[ avily on our model of a user, and whether we're using ourselves as hypothetical examples or not.<br>
<br>One slightly more solid question for browsers is, would it be entirely<br>crazy to have different mapping algorithms for typed-in domain names<br>than for links followed? There might be a locale-dependent mapping as<br>
well as a global mapping. (I assume that having every established<br>locale mapping installed would be complete craziness.)<br><br>Another question is: when posted links are followed, how often do we<br>know the locale where the link was authored? Not that the browser<br>
following the link would necessarily be able to apply the mappings of<br>the locale in which it was authored, but would it be slightly better<br>to apply a global mapping than a mapping from a different locale?<br><br>Do any authoring software clients fix up links as the user types?<br>
When I type a link in a document, the authoring software often makes<br>that link active. Is there any software that automatedly lower-cases?<br> If so, would such software also be likely to map to PVALID characters<br>before the doc is finished?<br>
<br>At 20:35 02/12/2009, Lisa Dusseault wrote:<br>I don't see where that principle begins and ends. If it were entirely true, zone operators would be entirely free to register xn--garbage as a domain, entirely free to register DISALLOWED characters.<br>
<br>Since it is in the purview of IDNA designers to make a character valid or disallowed, wouldn't also be in the purview of IDNA designers to say something like "This character becomes valid on date 01/01/2020", right? So why wouldn't it be in the purview of IDNA designers to also say something like "This character becomes fully valid on date 01/01/2020, but until then, may be registered if it is bundled with another sequence"?<br>
<br>Doncha love slippery slopes <br><br><br>At 00:15 03/12/2009, Lisa Dusseault wrote:<br>>>Would someone who understands IETF process better than I do please explain why the discussion <br>>> of that character needs to proceed any further?<br>
<br><br>Even if this is a rhetorical question, I'll bite. It's because the IETF makes decisions by rough consensus and running code. Rough consensus is among informed participants as well as experts and people in certain positions of authority or responsibility. Running code certainly brings in browser/client implementation history and current client implementation concerns. It is not only operators of the countries where those languages are most spoken, that have collateral effects from the status of the characters of those languages in IDNA.<br>
<br><br>At 01:46 03/12/2009, Lisa Dusseault wrote:<br>Your argument is a fair argument to try to influence the consensus, but it is not a fair argument to overrule a consensus (not that I'm saying you are doing that). We do rely on most IETF participants being constructive most of the time. We just have no other process besides appealing to people who are forming the consensus to look at running code, reality, security concerns and so on.<br>
<br><br>At 05:01 03/12/2009, Lisa Dusseault wrote:<br>I did claim that running code was an important influence on a WG consensus, by tradition, habit and official encouragement. <br> - First, that doesn't mean it's the only influence, or the most important influence in some considerations. <br>
- Second, the term is used both strictly, as in to demonstrate interoperability directly, and also loosely. By loose interpretations of "running code" you could claim that how a country uses a character in printed books was a form of deployed code that can be used as factual evidence. <br>
<br><br>At 23:41 04/12/2009, Lisa Dusseault wrote:<br>I've been having trouble understanding how TRANSITIONAL characters that could not be mapped or looked up by clients would help us out here. (You're not the only one Erik, I was just thinking of this offline)<br>
<br>If I understand correctly, Web browsers in particular visit a corpus of Web pages with links that they would like to not only continue to support, but also continue to resolve to the same host (absent other changes). So on the day that somebody upgrades to the new version of a browser with IDNA2008, their link destinations for TRANSITIONAL characters do not change.<br>
<br>"Do not change" also means that the user doesn't suddenly start getting an error trying to follow a link with a TRANSITIONAL character in the domain.<br><br>I agree that in some models, an error is better than going to an indeterminate destination. But only in some models. To the user, upgrading their browser and suddenly having links with in domains fail where it succeeded the day before, does not seem like a real upgrade.<br>
<br> <br><br>