On 2010-11-21, at 22:53, Doug Barton wrote: > On 11/17/2010 01:19, Stephane Bortzmeyer wrote: > | On Thu, Nov 11, 2010 at 01:42:24PM -0500, > | Joe Abley<jab...@hopcount.ca> wrote > | a message of 15 lines which said: > | > |> http://www.ietf.org/id/draft-liman-tld-names-04.txt > |> > |> is the latest iteration of an effort started quite some time ago to > |> clarify the somewhat vague inference in RFC 1123 and create a more > |> precise specification for the syntax of TLD labels in the DNS. > | > | Nice attempt but, as I have already said > | <http://www.ietf.org/mail-archive/web/dnsop/current/msg07058.html>, > | there is zero technical reason to limit the TLD to alphabetic > | characters and therefore, the rule: > | > | traditional-tld-label = 1*63(ALPHA) > | > | is both a new rule (it was not in RFC 1034 or 1035) and a bad one. > | > | I object to the creation of new rules disguised as clarifications. > > Fully agree with Stephane on this. That bit needs to be changed to the > ABNF equivalent of the same LDH rules we use for hostnames. I've also > attached a diff with some related edits. More importantly it's worth > correcting the IANA section to make it clear that the IANA does not > create policy.
Thanks for your review (Stéphane and Doug), and sorry for not replying to your comments earlier, Stéphane. I also know of no protocol (1034/1035) restriction for labels in the root zone. However, as the document describes in citations from 1123 there is some degree of expectation that top-level domain labels have additional technical policy restrictions. I don't know that we have the institutional knowledge to fully understand the "alphabetic" reference in 1123, and to my knowledge we don't have any consolidated, rigourous field experience of what software exists that might assume that a label which is not "alphabetic" is something other than a component of a domain name. I'll note (a) that there has never existed a US-ASCII (i.e. non-IDNA2008) TLD label that has *not* been "alphabetic", so we have no deployed examples in the namespace from which to infer stability, and (b) the software we might be concerned about is application-layer stuff, really anything that might ever need to process a domain name, and hence there's a lot of it and it's hard to catalogue. The conservative path seems to be to assume that there is deployed software that relies on the same expectation expressed loosely in 1123. In that context, the goal of this document really is to clarify the situation and eliminate the ambiguity. I am carefully not expressing a personal opinion about whether the technical policy restrictions on TLD labels should change from the conservative interpretation of what they are today (per above). No doubt a future document, citing a wealth of research and experimental data, could successfully update this document and relax the restriction. I'll offer an opinion that doing that work now is the wrong thing, however. Clarifying the existing technical policy is something that I think we ought to be able to do quickly and easily now; changing it is likely to be far more contentious and hence if it succeeds at all will take far more time. The community is best served by the existence of clear, unambiguous specifications. Clarify then extend will result in a near-immediate clear specification; extend alone will take much longer, and may never produce anything at all. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
