At 14:48 07-03-2009, Peter Koch wrote:
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:
This is an opportunity to look at Section 2.1 of RFC 1123 as the
distinction is unclear within the IETF community and in other communities.
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.
Relaxing or clarifying the ambiguity of the "alphabetic rule" takes
us into the "do no harm" arena. That "rule" allows us to sidestep
some possible issues if we are looking at ASCII-only TLDs only.
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.
Agreed. The text provides an explanation of the "requirements
text". If we want to be conservative, we can read it as clarifying
the intent when that specification was written, i.e. "we can avoid
the problem altogether by doing this".
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.
If we remove the alphabetic constraint on the first character, we
then have to list the exceptions (e.g. 0xe) or craft rules to cover them.
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.
As the issue affects application-layer protocols, it would be better
to address it as part of some 1123 or 1123-related effort.
{ceterum censeo, 1912 needs an update ...}
Agreed. That entails a text rewrite or some creativity as it is
pre-2026 material.
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).
The guidelines for the IANA considerations Section is covered in RFC
5226. I share your opinion that the IANA considerations in the draft
may fit under RFC 2860. As this is a version -00 draft, the question
could be left open for now.
Regards,
-sm
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
