It looks like we all agree to disagree. I agree on having a draft that spells out the facts, and as Tony said, leave the decision of allocation policy to ICANN? My thoughts on what such a draft may look like are below..
======= 1. Requirements on composition of TLDs no requirements over and above normal host names i.e. can be 1*63 [a-z] [0-9] and hyphen, cannot start or end with hypen etc.. [I think we can all agree that the internet will not break if ".8-ball" was added to the root, as to whether it works...] For IDNs, must be valid a-label and u-label 2. Potential Issues The internet will not break with allocation of new TLDs, however the following considerations should be noted. 2.1 RFC1123 application developers may have made assumptions about composition of domain names; applications may not recognise new TLD. this has been seen with .museum.. 2.2 Confusion with IP Addresses TLDs that begin with a digit may be confused with IP addresses TLDs that begin with 0x may be confused with IP addresses TLDs that are 0-255 may be confused with IP addresses and thus never looked up in DNS as suggested in RFCxxx [perhaps some of these points become restrictions on the composition of TLDs] 2.3 BIDI domain names Left-to-right domain names that do not start with a character having BIDI property L will contradict the IDNA BIDI protocol when it is applied. The BIDI protocol should be applied on lookup when the domain name contains a character with [R, AL, AN] BIDI properties... Additionally RTL labels ending with a digit, that are immediately before LTR labels beginning with a digit, will cause name to be re-ordered and displayed incorrectly. 2.4 Reserved labels Labels containing hyphens in third and fourth positions should be reserved for future use in protocols as with IDNs. Allocation of such names may cause future stability issues.. 3. Validation of TLDs Application developers should not make assumptions about the composition of TLDs, or the frequency in which they are allocated. if validation is required then looking up the entry in the DNS is a foolproof way to know if a TLD has been allocated. Consideration should be made to reduce queries to the root. Static lists should be avoided. ======= With the above we will have equipped ICANN and others about what issues can be expected with new TLDs. ICANN can now, with respect to the BIDI issue for example, choose to disallow TLDs beginning with a digit, or have an agreement with the registry operator that RTL or RTL<digit> names are not allowed below the TLD. James > -----Original Message----- > From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of Tony > Finch > Sent: Monday, 29 November 2010 8:42 AM > To: Suzanne Woolf > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] draft-liman-tld-names-04 > > On 27 Nov 2010, at 18:50, Suzanne Woolf <wo...@isc.org> wrote: > > > > I think the fact that this discussion has gone on so long and > > encumbered so many electrons supports the contention underlying the > > draft that there is an ambiguity, based exactly as Joe suggests here. > > I agree that the point needs clarifying. I disagree with the form of the > proposed clarification. It unnecessarily muddles the protocol and policy > layers. > > The question of which TLDs are allocated and what restrictions are necessary > for the stability of the DNS is a policy matter under ICANN's responsibility. > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
