internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Top Level Domain Name Specification
Author(s) : L. Liman
Filename : draft-liman-tld-names-00.txt
Pages : 9
Date : 2009-03-03
RFC 1123 is ambiguous regarding the specification for top level
domain (TLD) labels used in the domain name system. This document
clarifies the specification, and aligns it with current praxis,
including the use of Internationalized Domain Name (IDN) Labels in
TLD names.
Lars-Johan,
Updating 1123, and 1122, is a good idea, and a lot of work went into
them, not just by the editor, Bob Braden, but by dozens of people.
So my
first comment is a meta-comment to the effect that 1123 is not
"ambiguous regarding the specification for top level domain (TLD)
labels
used in the domain name system". We didn't attempt to rigorously
specify
rlogin, telnet, ftp, smtp, or the dns, see the language in section 7
"This section lists the primary references with which every
implementer
must be thoroughly familiar", the absence of "this obsoletes"
language,
and the stated purpose -- "incorporates by reference, amends,
corrects,
and supplements the primary protocol standards documents relating to
hosts". What we attempted was to make some corrections, known to
some of
us, circa 1989. We did not exhaust the space of possible ambiguities
in
existing specifications, though none known were omitted to my
knowledge
by intent (and I don't have notes from that period anyway, so this is
all personal memory), nor did we consider the possibility that the dns
would ever cease to be policied by some public trust body, or that
names
would become trademarks (though we were all fond of memorable
landmarks
like sri-arpa), and many other fine, and not so fine things that would
emerge in the next 20 years.
So either the text in section 2.1 of 1123 is low hanging fruit which
is
opportunistically picked in the momentary context of the third round
of
new gTLD activities by the Current New Entity (ICANN), or 1123 is
perfect except for this one little bit which needs a little bit of
editorial review and as a mater of convenience, is intended to be
published as a separate RFC rather than as a revised version of 1123.
Restated more briefly, I suggest that rather than assert 1123 is
ambiguous and you're going to fix it, a technically neutral act, you
simply state what it is you're advocating, possibly in a disinterested
fashion.
Next, it is a convention, which Donald, Bill, and I observed in 2929,
that "[t]ext labels can, in fact, include any octet value including
zero
octets but most current uses involve only [US-ASCII]." The nuances I
recall that Donald and I exchanged notes over during the drafting was
that labels could indeed be one octet, or more, and could be any
value,
though the practice at the time was the printable range of 7-bit
ASCII,
and the LDH subset of that range. So the statement in your section 2
would be that you'd like to assert a policy for a registry, the IANA
root as it happens, and there's nothing wrong with writing registry
policy, its something of a cottage industry in the ICANN g- and
cc-playpens, but it isn't a protocol specification.
So you'd like two (or more) ASCII alphas, which the iso3166-1 MA may
be
comforted by, with the possibility of an infix digit or hyphen or
sequence of infix digits (but not a sequence of infix hyphens) as the
number of octets in the label increases to three or more.
That's fine registry policy. As reasonable, as registry policy, as the
Arab League's insistence that domain names be real words, or the .cn
registry's policy (circa 2001, it may have changed) not to allow the
names of current or former prominent persons in the Chinese Communist
Party to be allocated, or the .us registry's policy that authoritative
nameservers be located in the United States. But it isn't a protocol
specification.
There is no technical necessity to use only 7-bit ASCII. We (IDN-pre-
A)
could have chosen to make the lives of the 7-bit mailers, and others,
harder. Whether the better possible choice was made was opinion then,
and now, of a community of engineers with differing skills, and
agendas,
but the ASCII encoding form initially (and unilaterally deployed) by
Verisign is what was chosen, but not because of any constraint
integral
to the DNS.
My suggestion is that you re-write this as a proposed registry
policy to
bind on the United States, and its contractors, in particular,
Verisign
and ICANN, and their subcontractors, the current and potential TLD
operators, and of course, the root server operators. I don't think
it is
particularly good policy, but it is policy and if its what you want,
write it as proposed policy and then sell the hell out of it.
At last I see why Andrew has been asking if anything when punycoded
can
end with a digit, but there is a policy consideration to entertain
also
when asserting a two-octet label may not contain a digit,
independent of
any encoding issue, which I've communicated privately to Tina Dam, and
eventually I'll post to this, or the IDNAbis, or both, lists.
Section 3 is not useful, because whether you use BNF or not, there
is no
technical content to Section 2, just a policy statement.
Section 4 should be re-written using MUST and MUST NOT terms. You are
proposing a policy that the IANA be required to implement, to the
exclusion of all other policies. This is why we have the language from
2119 and all those ugly upper-case ASCII characters shouting for
attention.
Section 5 is simply wrong. Not because no implementations exist which
are broken, but because we flat don't care. If we did care, we would
have pulled back the .museum TLD because its length was greater than 3
and the string wasn't "arpa".
Please don't take this hard, when I proposed that rfc954 be "historic"
Bob Braden commented that the world would end (slight exaggeration) if
whois wasn't around and running on port 43, and I'll buy you a beer in
San Francisco.
Best,
Eric
_______________________________________________
Idna-update mailing list
idna-upd...@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
