<html><body 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></body></html>