[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Prior Use - Experimental registries
- Date: Fri, 22 Nov 1996 20:41:08 -0500
- From: "Perry E. Metzger" <perry@piermont.com>
- Subject: Re: Prior Use - Experimental registries
[Speaking as always for myself, and not for the IAHC in an official capacity.]
Simon Higgs writes:
> > I believe that the ISO TLDs and the US Government TLDs have never been
> > in the same class as the iTLDs. The fact that applications for ISO
> > TLDs have been processed over the last year and likely will continue
> > to be processed is unrelated to the question of how non ISO two letter
> > TLDs such as the iTLDs are being handled.
> Can you, as an IAHC committee member, point me to the relevent
> documentation that supports that statement?
> (If you can't do this as a committe member, then please do it as an
> ordinary iahc-discuss list member)
I can't do ANYTHING as an IAHC committee member unless the bulk of the
commitee authorizes it. We do not operate in an official capacity
except collectively.
However, anyone on earth can read RFC 1591, which makes it fairly
clear that at the time of the writing of that document, it was
expected that the only applications that would be processed would be
for ISO two letter TLDs.
Quoting:
It is extremely unlikely that any other TLDs [other than ISO-3166
TLDs -- pm] will be created.
I'm sure other interpretations of the line in question are possible --
my insertion there could be disputed by some particularly partisan
individual -- but this is the only interpretation that is is at all
consistant with what almost the entire community knew at the
time. Indeed, I will state that for my part, I consider any other
interpretation to be on its face absurd. Prior to NSI beginning
charges for registration in .COM and .NET, there was no expectation in
the community that any new TLDs were going to be allocated at all
other than ISO TLDs. Everyone knew that as national authorities and
similar organizations requested ISO TLDs they were allocated them, and
that other than that the top level of the DNS was closed.
After NSI began charging, people started talking about opening up the
DNS space for a variety of reasons -- but in the absense of a new
official policy we would fully expect the IANA to have continued in
its activity of registering ISO TLDs on an ongoing basis regardless of
the formation of policy about other TLDs. ISO TLDs are a different
animal. Always have been.
> I'm sure this mysterious documentation will solve most of the current
> questions.
RFC 1591 is hardly mysterious.
I've reprinted (below) Jon Postel's comment of today on how country
code TLDs are allocated, which essentially matches, even today, the
RFC1591 description.
Perry
----------------------------------------------------------------------
From: postel@ISI.EDU (Jon Postel)
Message-Id: <199611220445.AA17295@zephyr.isi.edu>
To: iahc-discuss@iahc.org
Subject: Country Code TLDs
Cc: postel@ISI.EDU, iana@ISI.EDU
Hello:
As a point of clarification, here is the IANA's statement about country
code top level domain names.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The codes we use are those from the ISO 3166 standard.
A country must recognised as such by the ISO (or by the UPU);
the code used must be the ISO-3166 code (or if there is no code
in the Standard, then the code used should be that which is
reserved in the ISO-3166 Reserved Code Elements list as a UPU
code).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The effect of the extra stuff about allowing as a TLD something that is
both a ISO-3166 Reserved Code Element and a UPU code is to add 4
possibilities:
AC = Ascension Island
GG = Guernsey
IM = Isle of Man
JE = Jersey
This small extension of the rules by the IANA seemed to greatly offend
a very few people, and seemed to be no big deal to many others. A key
point to keep in mind is that the IANA did not choose the codes or make
up the list, it extended the set of allowed codes to another list
provided by the ISO 3166 maintenance agency.
--jon.