On 29/11/2010, at 10:17 AM, James Mitchell wrote: > 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
+1 Chris > >> -----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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
