<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Vint, et al,<div><br></div><div>This seems reasonable to me. I would offer two refinements.</div><div><br></div><div>First, each registry, in cooperation with its registrars, could use the sunrise period to register all of the variants that are automatically mapped together under IDNA2003 but will become separate under IDNA2008. The variants would all point to the same address(es), so the result should be the same for anyone looking up a name under either the IDNA2003 or IDNA2008 rules. When the sunrise period is over, the variants could become unregistered or could be transferred to others. The existing registrant would have first say, of course. I'm implicitly suggesting a business strategy for the registries and registrars, and that may or may not appeal to them. For ICANN accredited registries and registrars, there might need to be some coordination with ICANN too, particularly if the variant registrations are provided at no charge during the sunrise period. I haven't given this extensive thought, and I haven't talked to others in ICANN, so I can't speak authoritatively, but it seems to me a plausible strategy for smoothing the transition. In essence, this is the mirror of the strategy you're proposing in the sense that all the variants are registered and then the undesired ones trickle away.</div><div><br></div><div>One might ask if the number of variants will be unwieldy, and one can point to examples like Mississippi or hisssss... as stressful cases. My intuition is that even if a few cases explode, the overall impact will be small. I'll go on record here and suggest the impact will be less than 10% for any existing domain.</div><div><br></div><div>Second, you've proposed the timing of the transitions would be up to each registry. That's a good suggestion in terms of providing maximum flexibility, but it seems to me that some of the timing is governed by the browsers. I would expect there will be a date when IDNA2008 is phased in and a separate, later date when IDNA2003 is declared dead. In between these dates, I would expect the registries will have to phase over.</div><div><br></div><div>These details aside, I am very glad there is attention to a transition plan. That's something that has been a difficult area for both IPv6 and DNSSEC, and I think IDNAbis will be much better off with this attention to transition.</div><div><br></div><div>Thanks,</div><div><br></div><div>Steve</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Dec 14, 2009, at 2:12 PM, Vint Cerf wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><font class="Apple-style-span" face="Courier">It is recommended to use a fixed width font to display this message</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Introduction of Eszett (sharp-S) and Final Sigma</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">See <a href="http://typefoundry.blogspot.com/2008/01/esszett-or.html">http://typefoundry.blogspot.com/2008/01/esszett-or.html</a> for an</font></div><div><font class="Apple-style-span" face="Courier">interesting perspective on 'Sharp-S'</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Introduction</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">The IDNABIS working group has spent two years evolving documents</font></div><div><font class="Apple-style-span" face="Courier">describing the use of Unicode in Internet domain name labels. We have</font></div><div><font class="Apple-style-span" face="Courier">ended the IETF Last Call with a lengthy discussion on the manner in</font></div><div><font class="Apple-style-span" face="Courier">which the Unicode characters Latin Small Letter Sharp-S (U+00DF) and</font></div><div><font class="Apple-style-span" face="Courier">Greek Small Letter Final Sigma (U+03C2) are to be introduced into use.</font></div><div><font class="Apple-style-span" face="Courier">The so-called Zero-Width Joiner and Zero-Width Non-Joiner (ZWJ and</font></div><div><font class="Apple-style-span" face="Courier">ZWNJ respectively) have been included as CONTEXT-Joiner (or CONTEXTJ)</font></div><div><font class="Apple-style-span" face="Courier">in the IDNA2008 documentation and the general consensus is that these</font></div><div><font class="Apple-style-span" face="Courier">two may be registered at the discretion of registries. IDNA2008</font></div><div><font class="Apple-style-span" face="Courier">specifically permits their use, in context.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">The primary debates surrounding Sharp-S and Final Sigma relate to the</font></div><div><font class="Apple-style-span" face="Courier">method of their introduction into use as PVALID characters under</font></div><div><font class="Apple-style-span" face="Courier">IDNA2008. This note represents an attempt to synthesize a</font></div><div><font class="Apple-style-span" face="Courier">philosophical basis for achieving the goal of making these two</font></div><div><font class="Apple-style-span" face="Courier">characters usable in domain name labels. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">It is useful to recall that the Domain Name System is a hierarchical</font></div><div><font class="Apple-style-span" face="Courier">system of registries. The root zone is the place where top level</font></div><div><font class="Apple-style-span" face="Courier">domain labels are registered. The Top Level domain name registries</font></div><div><font class="Apple-style-span" face="Courier">(e.g. .com, .coop, .ca, .uk) are 'pointed to' using 'delegation</font></div><div><font class="Apple-style-span" face="Courier">records' in the root zone file. Each 'dot' in a domain name is a point</font></div><div><font class="Apple-style-span" face="Courier">where 'delegation' (in DNS-speak, a zone cut) for further registration</font></div><div><font class="Apple-style-span" face="Courier">handling MAY be implemented.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">So, for example, suppose that it is desired to create a Second Level</font></div><div><font class="Apple-style-span" face="Courier">label, 'foo' under the Top Level Label 'com'. Typically, the party</font></div><div><font class="Apple-style-span" face="Courier">wishing to register domain names with the suffix 'foo.com' would</font></div><div><font class="Apple-style-span" face="Courier">request to register 'foo' as a second level label under 'com' and a</font></div><div><font class="Apple-style-span" face="Courier">delegation record would be created pointing to the name server that</font></div><div><font class="Apple-style-span" face="Courier">will respond to all domain names with the suffix 'foo.com'.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">At any point, a registration may either be an address record for,</font></div><div><font class="Apple-style-span" face="Courier">e.g., abc.foo.com, or a set of delegation records pointing to the</font></div><div><font class="Apple-style-span" face="Courier">servers Third Level label 'abc'.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">The notion of delegation is important to keep in mind when considering</font></div><div><font class="Apple-style-span" face="Courier">how to introduce new PVALID characters into labels since each label in</font></div><div><font class="Apple-style-span" face="Courier">a multi-label domain name can be managed by a different entity (ie</font></div><div><font class="Apple-style-span" face="Courier">through delegated authority). A decision by a higher level authority</font></div><div><font class="Apple-style-span" face="Courier">to treat two different labels as equivalent is a non-trivial exercise</font></div><div><font class="Apple-style-span" face="Courier">in delegation mechanics. This fact is often lost in discussions about</font></div><div><font class="Apple-style-span" face="Courier">domain names as if there were flat identifiers. They are not. They</font></div><div><font class="Apple-style-span" face="Courier">really represent delegated hierarchies and their creation is often</font></div><div><font class="Apple-style-span" face="Courier">achieved through a series of assignments of delegated authority.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">DESIDERATA ON THE INTRODUCTION OF NEW PVALID CHARACTERS</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">1. It is desirable that they can be introduced as soon as any</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">registry in the hierarchy wishes to do so without having to</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">coordinate with other registries.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">2. It is desirable that IDNA2003 compliant and IDNA2008 compliant</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">entities (programs, applications‚ etc.) co-exist without introducing</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">ambiguous resolution of domain names (ie. The same domain name</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">resolves to different IP addresses under IDNA2003 and IDNA2008</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">interpretation)</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">3. In the proposal that follows, a relaxation of the constraint</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">in (2) is that it is acceptable that IDNA2008 interpretation leads</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">to NXDOMAIN even if IDNA2003 leads to a valid IP address (or</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">vice-versa). Under this provision, the introduction of a new</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">PVALID character does not lead to distinct IP addresses (and</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">therefore hazardous ambiguity) even if it produces (temporary?)</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">non-resolution for some cases.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">It should be recognized that the millions of registries/zones in the</font></div><div><font class="Apple-style-span" face="Courier">DNS are largely independent entities. We can produce a "suggested</font></div><div><font class="Apple-style-span" face="Courier">good practice", but registries will make local determinations as to</font></div><div><font class="Apple-style-span" face="Courier">what to do based on local considerations. To discourage a particular</font></div><div><font class="Apple-style-span" face="Courier">practice, it seems best to explain what bad consequences will result</font></div><div><font class="Apple-style-span" face="Courier">from following it but as a practical matter leave the decisions up to</font></div><div><font class="Apple-style-span" face="Courier">the registry. In many ways we have already adopted this position in</font></div><div><font class="Apple-style-span" face="Courier">IDNA2008 by leaving a great many decisions about which characters to</font></div><div><font class="Apple-style-span" face="Courier">permit for registration (even if they are PVALID in protocol) for</font></div><div><font class="Apple-style-span" face="Courier">reasons of local significance or practice.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">There are many side-effects associated with introducing as PVALID</font></div><div><font class="Apple-style-span" face="Courier">characters that were formerly mapped under IDNA2003. An unknown number</font></div><div><font class="Apple-style-span" face="Courier">of URLs (or other domain-name-referencing constructs) may become</font></div><div><font class="Apple-style-span" face="Courier">unreachable upon adoption of IDNA2008, if the unmapped versions of the</font></div><div><font class="Apple-style-span" face="Courier">associated domain names have not been constructively registered and</font></div><div><font class="Apple-style-span" face="Courier">made to resolve to the same IP address as the mapped version. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">THE SHARP-S EXAMPLE</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Under IDNA2003, any reference to a domain name label containing</font></div><div><font class="Apple-style-span" face="Courier">Sharp-S is converted to a label containing 'ss' in place of Sharp-S,</font></div><div><font class="Apple-style-span" face="Courier">whereever Sharp-S appears. This revised label is then used either for</font></div><div><font class="Apple-style-span" face="Courier">registration or look up in the Domain Name System.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Under IDNA2008, Sharp-S is treated as PVALID and not converted to</font></div><div><font class="Apple-style-span" face="Courier">'ss'.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Many of the suggested transition tactics have attempted a kind of</font></div><div><font class="Apple-style-span" face="Courier">"perfection" in which there is either a deadline by which everything</font></div><div><font class="Apple-style-span" face="Courier">works under IDNA2008 or new mechanisms to somehow distinguish between</font></div><div><font class="Apple-style-span" face="Courier">IDNA2003 and IDNA2008 or urge strenuous efforts to make everything</font></div><div><font class="Apple-style-span" face="Courier">backward compatible with IDNA2003 mappings - especially for the two</font></div><div><font class="Apple-style-span" face="Courier">problem characters Sharp-S and Final Sigma. I am ignoring everything</font></div><div><font class="Apple-style-span" face="Courier">else but these in this contribution since my sense is that this</font></div><div><font class="Apple-style-span" face="Courier">working group may go along with anything that "solves" the problem</font></div><div><font class="Apple-style-span" face="Courier">with them. Joiners I think we can assume have been accepted in the</font></div><div><font class="Apple-style-span" face="Courier">CONTEXTJ form.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">I would like to try out on you an idea that isn't "perfect" but that</font></div><div><font class="Apple-style-span" face="Courier">avoids the worst hazard, I think.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">My definition of worst hazard is that different entities (browsers,</font></div><div><font class="Apple-style-span" face="Courier">applications) do resolution and get conflicting results. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">An example of this would be a case where under IDNA2003, a domain name</font></div><div><font class="Apple-style-span" face="Courier">containing Sharp-S would be vectored to a domain name and associated</font></div><div><font class="Apple-style-span" face="Courier">IP address that referenced a domain name registered with "ss" in lieu</font></div><div><font class="Apple-style-span" face="Courier">of Sharp-S and under IDNA2008 would be vectored to an IP address</font></div><div><font class="Apple-style-span" face="Courier">associated with a Sharp-S registration that leads to a different IP</font></div><div><font class="Apple-style-span" face="Courier">address and a distinct registrant. I would distinguish this from the</font></div><div><font class="Apple-style-span" face="Courier">case where the same registered domain name is associated with two or</font></div><div><font class="Apple-style-span" face="Courier">more IP addresses on purpose (e.g. two A records that the registrant</font></div><div><font class="Apple-style-span" face="Courier">considers equivalent). </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> </font></div><div><font class="Apple-style-span" face="Courier">I</font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier">DNA2003 Case</font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier"><br></font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier">registered looked up</font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier">domain name domain name IP address Registrant</font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier">masse.com maße.com mapped 12.34.56.78 Mr. Foo</font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier"> to masse.com</font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier"><br></font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier"> </font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier">IDNA2008 Case</font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier"><br></font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier">registered looked up</font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier">domain name domain name IP address Registrant</font></span></font></div><div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><font class="Apple-style-span" face="Courier">maße.com maße.com 34.56.78.12 Mr. Bar</font></span></font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">The hazard is that under IDNA2003, a look up for maße.com gets the</font></div><div><font class="Apple-style-span" face="Courier">12.34.56.78 address of masse.com while under IDNA2008, the look up for</font></div><div><font class="Apple-style-span" face="Courier">maße.com gets the 34.56.78.12 address of maße.com</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">What we would like is to prevent this unexpected ambiguity.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">I would like to introduce a failsafe practice that prevents this</font></div><div><font class="Apple-style-span" face="Courier">particular ambiguity but allows for an NXDOMAIN result that may not be</font></div><div><font class="Apple-style-span" face="Courier">considered hazardous even it is annoying.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Let us imagine that the .com registry wishes to introduce IDNA2008</font></div><div><font class="Apple-style-span" face="Courier">capability into its second level domain registrations (that's all it</font></div><div><font class="Apple-style-span" face="Courier">controls).</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">We assume that it has been registering under IDNA2003 rules in the</font></div><div><font class="Apple-style-span" face="Courier">past, so that any label containing "ß" will have been mapped to "ss"</font></div><div><font class="Apple-style-span" face="Courier">prior to registration. There is a collection of registrants in the</font></div><div><font class="Apple-style-span" face="Courier">equivalence class "registered a label containing 'ss'". Let us call</font></div><div><font class="Apple-style-span" face="Courier">the set of such registrants R.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">The .com registry introduces a sunrise period in which all members of</font></div><div><font class="Apple-style-span" face="Courier">R are advised that they may register domains equivalent to the ones</font></div><div><font class="Apple-style-span" face="Courier">they did register but with the mapped "ss" form changed to the</font></div><div><font class="Apple-style-span" face="Courier">unmapped "ß" form. I am pretty sure there cannot be collisions here</font></div><div><font class="Apple-style-span" face="Courier">because all the final registrations have to have been mapped to "ss" -</font></div><div><font class="Apple-style-span" face="Courier">so if there were going to be a collision it would already have been</font></div><div><font class="Apple-style-span" face="Courier">detected at the time of original IDNA2003-compliant registration:</font></div><div><font class="Apple-style-span" face="Courier">"sorry, someone else has already registered the 'ss' form you would</font></div><div><font class="Apple-style-span" face="Courier">have gotten, can't register that." </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">After time T (determined by the registry, not by IETF or ICANN fiat),</font></div><div><font class="Apple-style-span" face="Courier">the .com registry then advises that it will accept registration of</font></div><div><font class="Apple-style-span" face="Courier">SLDs containing "ß". However, it abides by the following rules at</font></div><div><font class="Apple-style-span" face="Courier">REGISTRATION time:</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">(Failsafe Rule 1): If registration of an SLD containing "ß" would</font></div><div><font class="Apple-style-span" face="Courier">collide under IDNA2003 mapping rules with an existing registered</font></div><div><font class="Apple-style-span" face="Courier">domain name, the registration is allowed if the holder of the</font></div><div><font class="Apple-style-span" face="Courier">requested domain is the same (*) as the holder of the</font></div><div><font class="Apple-style-span" face="Courier">already-registered domain, otherwise the registration is not allowed. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">(Failsafe Rule 2): If registration of an SLD containing "ss" would</font></div><div><font class="Apple-style-span" face="Courier">collide under IDNA2003 mapping rules with an existing registered</font></div><div><font class="Apple-style-span" face="Courier">domain name containing "ß" it is allowed if the holder of the</font></div><div><font class="Apple-style-span" face="Courier">requested domain is the same (*) as the holder of the already</font></div><div><font class="Apple-style-span" face="Courier">registered domain, otherwise the registration not allowed. Note that</font></div><div><font class="Apple-style-span" face="Courier">Failsafe rule 2 only applies once a registry is operating under</font></div><div><font class="Apple-style-span" face="Courier">IDNA2008 rules.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">(*) Which registrants are "the same" is to be defined by the</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">registry, and match the definitions the registry applies. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">As a slightly less safe alternative, but at the option of the registry</font></div><div><font class="Apple-style-span" face="Courier">(perhaps after even more time has gone by), "not allowed" in the above</font></div><div><font class="Apple-style-span" face="Courier">two rules could be replaced by notification of the existing domain</font></div><div><font class="Apple-style-span" face="Courier">holder with an offer to again let that registrant preemptively</font></div><div><font class="Apple-style-span" face="Courier">register the name, thereby blocking its registration by someone else.</font></div><div><font class="Apple-style-span" face="Courier">If that offer were not accepted, the new registration would be</font></div><div><font class="Apple-style-span" face="Courier">permitted, of course still subject to whatever dispute resolution</font></div><div><font class="Apple-style-span" face="Courier">policies are in effect for .com or other relevant zone.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">This latter suggestion opens the door for achieving independence of</font></div><div><font class="Apple-style-span" face="Courier">formerly-mapped pairs of now PVALID characters. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">There are some nuances to the scenarios offered above. With possible</font></div><div><font class="Apple-style-span" face="Courier">exceptions for some "bundling" practices, most registrations will be</font></div><div><font class="Apple-style-span" face="Courier">sequential (ie. not "at the same time"). One typically registers one</font></div><div><font class="Apple-style-span" face="Courier">domain name and then registers others. Because of this, we will</font></div><div><font class="Apple-style-span" face="Courier">usually end up in a situation where at the time of the second (or Nth)</font></div><div><font class="Apple-style-span" face="Courier">registration someone has to check, for example, whether the requested</font></div><div><font class="Apple-style-span" face="Courier">holder of the next domain name registered is the same holder as the</font></div><div><font class="Apple-style-span" face="Courier">holder of earlier but colliding registered domain names.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">There may be different registrars involved in sequential</font></div><div><font class="Apple-style-span" face="Courier">registrations. There may be different contact representatives for</font></div><div><font class="Apple-style-span" face="Courier">respective registrations. There might be transfers being made in</font></div><div><font class="Apple-style-span" face="Courier">between related registrations. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Because of this, the important things are the failsafe rules, and that</font></div><div><font class="Apple-style-span" face="Courier">they (in an ICANN context) are formulated by the registries so that</font></div><div><font class="Apple-style-span" face="Courier">details like "same" actually have some specific meaning in the</font></div><div><font class="Apple-style-span" face="Courier">specific registry context. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">If we go back to the example given above and assume that Mr. Foo has</font></div><div><font class="Apple-style-span" face="Courier">registered masse.com before Mr. Bar has entered the picture, Mr. Foo</font></div><div><font class="Apple-style-span" face="Courier">will get to register maße.com during the sunrise period. Mr. Bar will</font></div><div><font class="Apple-style-span" face="Courier">not be allowed to register either maße.com or masse.com because both</font></div><div><font class="Apple-style-span" face="Courier">of these collide with previously registered domain names.</font></div><div><font class="Apple-style-span" face="Courier"> </font></div><div><font class="Apple-style-span" face="Courier">Let us now suppose that after the sunrise period, the registry is</font></div><div><font class="Apple-style-span" face="Courier">operating under IDNA2008 rules. Let us suppose that someone, Mr. Baz,</font></div><div><font class="Apple-style-span" face="Courier">has registered "strasse.com" prior to the adoption of the IDNA2008</font></div><div><font class="Apple-style-span" face="Courier">rules. Let us also assume that he did not bother to register</font></div><div><font class="Apple-style-span" face="Courier">"straße.com" during the sunrise period (if he had, he would presumably</font></div><div><font class="Apple-style-span" face="Courier">have that registration too). </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Now let Mr. Frotz try to register "straße.com" - under Failsafe Rule</font></div><div><font class="Apple-style-span" face="Courier">1, he would be denied this registration. Mr. Baz still has the</font></div><div><font class="Apple-style-span" face="Courier">possibility of registering it. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">If someone looks up "straße.com" under IDNA2003-compliant rules, he</font></div><div><font class="Apple-style-span" face="Courier">will get "strasse.com" unambiguously.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">If someone looks up "straße.com" under IDNA2008-compliant rules, he</font></div><div><font class="Apple-style-span" face="Courier">will get NXDOMAIN. This is a kind of brokenness but perhaps this is</font></div><div><font class="Apple-style-span" face="Courier">tolerable if it does not steer the party to the "wrong" site - and it</font></div><div><font class="Apple-style-span" face="Courier">potentially allows Mr. Baz to recover from his earlier choice not to</font></div><div><font class="Apple-style-span" face="Courier">register the "ß" version of his SLD earlier.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Now let us suppose that "strasse.com" has NOT been registered at all,</font></div><div><font class="Apple-style-span" face="Courier">the sunrise happens, and we are now operating under IDNA2008 rules.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Mr. Frotz registers "straße.com". Since there is no collision with a</font></div><div><font class="Apple-style-span" face="Courier">previously registered "strasse.com" there is no problem. Let us</font></div><div><font class="Apple-style-span" face="Courier">suppose that Mr. Frotz does not bother to register "strasse.com". </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">If someone looks up "straße.com" under IDNA2003-compliant rules, he</font></div><div><font class="Apple-style-span" face="Courier">will get NXDOMAIN because "strasse.com" does not exist.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">If someone looks up "straße.com" under IDNA2008-compliant rules, he</font></div><div><font class="Apple-style-span" face="Courier">will get the corresponding IP address.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">If someone looks up "strasse.com" under IDNA2008-compliant rules, he</font></div><div><font class="Apple-style-span" face="Courier">will get NXDOMAIN because it has not been registered.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Because the registry is operating under IDNA2008-rules, "ß" and "ss"</font></div><div><font class="Apple-style-span" face="Courier">are considered distinct and the party using IDNA2003-rules to look up</font></div><div><font class="Apple-style-span" face="Courier">a domain name registered under IDNA2008 rules is getting a "correct"</font></div><div><font class="Apple-style-span" face="Courier">response in some sense (in this case, NXDOMAIN). At least the lookup</font></div><div><font class="Apple-style-span" face="Courier">does not lead to the "wrong IP address".</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">If Mr. Frotz registers both "strasse.com" and "straße.com" (assuming</font></div><div><font class="Apple-style-span" face="Courier">neither of these violates Failsafe Rules (1) and (2) at registration</font></div><div><font class="Apple-style-span" face="Courier">time), his registrations will work for both IDNA2003-compliant and</font></div><div><font class="Apple-style-span" face="Courier">IDNA2008-compliant lookups. Whether queries using the two strings</font></div><div><font class="Apple-style-span" face="Courier">will produce the same results or not will still be up to him and not</font></div><div><font class="Apple-style-span" face="Courier">the registry: there is no practical way to avoid that.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Let us suppose, again, that Mr. Frotz successfully registers</font></div><div><font class="Apple-style-span" face="Courier">"straße.com" under IDNA2008 rules but does not bother to register</font></div><div><font class="Apple-style-span" face="Courier">"strasse.com"</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">Now let us suppose that Mr. FUBAR tries to register "strasse.com"</font></div><div><font class="Apple-style-span" face="Courier">subsequent to Mr. Frotz's registration of "straße.com". When he tries</font></div><div><font class="Apple-style-span" face="Courier">to do this, he would be blocked from that registration under Failsafe</font></div><div><font class="Apple-style-span" face="Courier">Rule (2). Or, under the more permissive variation, Mr. Frotz would</font></div><div><font class="Apple-style-span" face="Courier">have an additional opportunity to block Mr. FUBAR's registration by</font></div><div><font class="Apple-style-span" face="Courier">registering "strasse.com" himself. </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">I believe that adoption of Failsafe Rules (1) and (2) would permit</font></div><div><font class="Apple-style-span" face="Courier">each registry (in the general sense - all levels) to introduce</font></div><div><font class="Apple-style-span" face="Courier">IDNA2008 rules whenever they wish, and to provide for sunrise time</font></div><div><font class="Apple-style-span" face="Courier">periods of their choosing. The failures that occur (NXDOMAIN) are not</font></div><div><font class="Apple-style-span" face="Courier">harmful in the same way that "wrong IP address" would be harmful and</font></div><div><font class="Apple-style-span" face="Courier">perhaps this form of "failure" would be an acceptable price to pay for</font></div><div><font class="Apple-style-span" face="Courier">some period of time when IDNA2003-compliant and IDNA2008-compliant</font></div><div><font class="Apple-style-span" face="Courier">systems were in concurrent operation.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">I hope this isn't completely nuts.</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> vint</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">from John Klensin:</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier">The suggested process could be used to create a five-stage process:</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> (1) No registrations that actually involve Sharp-S (the status quo)</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> (2) Sunrise -- priority registrations for Sharp-S those who already</font></div><div><font class="Apple-style-span" face="Courier"> have labels containing "ss".</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> (3) No possibly-conflicting registrations, using Failsafe Rules 1</font></div><div><font class="Apple-style-span" face="Courier"> and 2 as written; starting time to be determined by registry </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> (4) Possibly-conflicting registrations permitted only after the</font></div><div><font class="Apple-style-span" face="Courier"> original registrant gets notification and an additional</font></div><div><font class="Apple-style-span" face="Courier"> opportunity to register the name herself; starting date again</font></div><div><font class="Apple-style-span" face="Courier"> determined by the registry</font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> (5) Sharp-S is just another character with no special treatment;</font></div><div><font class="Apple-style-span" face="Courier"> starting date again determined by the registry. </font></div><div><font class="Apple-style-span" face="Courier"> </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> </font></div><div><font class="Apple-style-span" face="Courier"><br></font></div><div><font class="Apple-style-span" face="Courier"> </font></div><div><br></div></div>_______________________________________________<br>Idna-update mailing list<br><a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br><a href="http://www.alvestrand.no/mailman/listinfo/idna-update">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br></blockquote></div><br></div></body></html>