SM <s...@resistor.net> wrote:
> The topic discussed in draft-liman-tld-names-00 has two angles, the
> application angle and the DNS angle. The "requirements" can be
> different depending on which angle we are looking at. From Section
> 11 of RFC 2181:
I'd like to support this distinction and would suggest we keep in mind the
important IDNAbis issues, but also look at the original text in RFC 1123
that prompted Liman's suggestion:
> There are some clarifications about the syntax of an Internet host
> name in Section 2 of RFC 1123. The "Discussion" part of that section
> mentions:
>
> "However, a valid host name can never have the dotted-decimal
> form #.#.#.#, since at least the highest-level component label
> will be alphabetic."
This is probably the ambiguity that draft-liman-tld-names-00 mentions.
"will be alphabetic" would not only exclude digits in the TLD, let alone
"numeric TLDs", but also IDN TLDs in the first place, since "alphabetic"
might not include the "-" character.
It is also unclear to me whether this text was meant (or, probably more
importantly: was subsequently read) as descriptive or normative
and the lack of 'normative language' doesn't help because we're in
pre-2026 times.
> According to Section 2 of draft-liman-tld-names-00, the top level
> domain label can be numeric only. This can lead to confusion if we
> cannot determine whether the string is a FQDN or an IP address.
The draft says:
! A TLD label] MUST consist of only ASCII characters from the groups
! "letters" (A-Z), "digits" (0-9) and "hyphen" (-), and it MUST start
! with an ASCII "letter", and it MUST NOT end with a "hyphen".
This would clearly suggest against 'numeric' TLD labels. However, it
also opens the question why the relaxation of the first character wouldn't
apply to the TLD itself.
> From Section 2.1 of RFC 1912 (Informational):
>
> "You should also be careful to not have addresses which are valid
> alternate syntaxes to the inet_ntoa() library call. For example 0xe
> is a valid name, but if you were to type "telnet 0xe", it would try
> to connect to IP address 0.0.0.14. It is also rumored that there
> exists some broken inet_ntoa() routines that treat an address like
> x400 as an IP address."
This is a known effect and something that truly belongs into any caveats
like section. Unless this behavior (or other creative forms of writing
an IPv4 address) is specified in any kind of standard, it's probably
more an issue of the user interface.
{ceterum censeo, 1912 needs an update ...}
{quoted text moved down here:}
> The title of the document is "Top Level Domain Name
> Specification". If it is about gTLDs, some may see this as a matter
> for some other organization instead of the IETF. Section 4 of the
> draft requests IANA to change its registration process to use the
> specification. Is the registration process set by the IETF or an
> other organization?
It's a version -00 draft, so this needs more thought and discussion.
My personal opinion is that the request goes to the "wrong IANA", since
the IANA considerations section is bound by RFC 2860. There might be
other ways to achieve the same goal, if and when the draft becomes
a technical clarification within the DNS (as opposed to IDN).
-Peter
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
