-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
To amplify my agreement with Stephane, we have already added LDH labels
to the top level, and the sky did not fall. Therefore the only valid
clarification from a _technical_ perspective is that the aside in 1123
was never a protocol restriction. Anything else is layer 9, and
specifically not our problem.
I also agree with Stephane and Andrew that there are poorly written
programs in the world that will have problems with TLD names that start
with a non-alphabetic. We already lived through the drama that new TLDs
caused 10 years ago (been there, done that), and I agree with Stephane
that whatever drama ensues from a TLD that starts with a digit is
unlikely to cause the network to melt down tomorrow.
Doug
- --
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBCAAGBQJM6elBAAoJEFzGhvEaGryEvggH/jSdN63R0n3bqoDbtXtViYKW
BkiPKyoIoltG4n8lbTB0CClqqsije1ZMoUmuYpXfhMxv2P+qerlg2WmnEcnrzsJL
lomuU7Lwkb6jeff1KkuQXaVYrTCOlkdMghWyPJFsm6nCDE0cx0WFshVCMHiImkGn
mkXcYoE20ae7Sj6uAyHowIxW3r0aJlpNJgAPNf5EtQfHWDdLEsyNJDp+oEGlh/4e
dtAU7d2Sdy0erXX6PLK3OpJVBrG/9G1QUdd4+zPamC+dNXHu5OfGqysA6QVswfwK
O7FtIA/QYkLW+aTgXIxxc33xK5ZpK74GQcL9nIJq/VIa1vQ+ujJJEWI64kFumsI=
=QprP
-----END PGP SIGNATURE-----
--- draft-liman-tld-names-04-orig.txt 2010-11-21 18:51:33.000000000 -0800
+++ draft-liman-tld-names-04.txt 2010-11-21 19:30:48.000000000 -0800
@@ -255,24 +255,24 @@
#.#.#.#, since at least the highest-level component label will be
alphabetic.' [Section 2.1]
- Some implementers may have understood the above phrase 'will be
+ Some implementers may have incorrectly understood the above phrase 'will be
alphabetic' to be a protocol restriction.
Neither [RFC0952] nor [RFC1123] explicitly states the reasons for
these restrictions. It might be supposed that human factors were a
consideration; [RFC1123] appears to suggest that one of the reasons
was to prevent confusion between dotted-decimal IPv4 addresses and
- host domain names. In any case, it is reasonable to believe that the
- restrictions have been assumed in some deployed software, and that
- changes to the rules should be undertaken with caution.
+ host domain names.
The Internationalised Domain Names in Applications 2008 specification
(IDNA2008) [RFC5891] [RFC5892] provides a protocol for encoding
Unicode strings in DNS-Labels. The Unicode string used by
applications is known as a U-Label; its corresponding encoding in the
- DNS is known as an A-Label. The terms A-Label and U-Label are used
- in this document as defined in [RFC5890]. Valid A-Labels always
- contain non-alphabetic characters.
+ DNS is known as an A-Label.
+ In addition to alphabetics valid A-Labels may contain
+ digits and always contain the minus sign. For example at the time
+ of this writing XN--P1AI is the Country-code top-level domain
+ designated for Russian Federation.
@@ -454,7 +454,7 @@
While this document makes no requests of the IANA, management of the
root zone is an IANA function. This document expands the set of
strings permitted for delegation from the root zone, and hence
- establishes new limits for the corresponding IANA policy.
+ establishes new limits for the corresponding IANA procedures.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
