[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [wg-c] S/K principles [Was: Working Group C agenda]
Sorry for not having more time to contribute to this very intersting debate,
but I would like here to put my 2cts.
I fully support the terminology gTLD = Generic Top Level Domain (chartered
or not) this makes the distinction between the ccTLDs (attached to a country
at least by its 2 letter code, the policy and usage of it is something else)
and the gTLDs which don't have any links to any particular country.
I have a little worry about the S/K principles and in particular with the
5. The selection of a gTLD string should not confuse net users, and so
gTLDs should be clearly differentiated by the string and/or by the
marketing and functionality associated with the string.
The problem will be the string, for example .union has a complete different
meaning in France (so in french) than in English !!!!!!! and may be it's an
insult in some other language...so Do we have the goal to invent a global
I take the opportunity to say something: We try or people want us here we
fix all the problems which don't have an answer in the real world (vs
virtual world = Internet), I mean people from IP community want us we fix
their problem of trademarks on the net but this problem exists on the real
world and they don't have any idea how to fix it. For example we have 3
differents trademarks for Mont Blanc in France, which one has a right in
.com !!!!!!! And now S/K try to fix the problem of universal language !!!!!
Just my thoughs.
From: Jonathan Weinberg [mailto:email@example.com]
Sent: Thursday, April 06, 2000 5:24 PM
Subject: Re: [wg-c] S/K principles [Was: Working Group C agenda]
A bunch of thoughts in response to Rick, Andrew D, Javier and Jamie:
1. In seeking to tweak the S/K principles, I have the great luxury
didn't write them, so I have no pride of authorship. I don't want to get
too far away, though, from the initial *goal* of the S/K principles, which
was to see if we could find a point of accommodation that would satisfy
both folks like Kathy, who is committed to substantial namespace expansion
and market competition, and folks like Philip, who believes that expansion
will be safe only if the namespace is structured in an appropriate manner.
(As Eric has pointed out, there's an obvious tension between getting the
principles general enough so that they can win consensus, and specific
enough so that they actually have bite.)
2. We turn out to be operating under a really tight timeframe. I
mentioned in an earlier message that the NC is going to be transmitting its
recommendations to the ICANN Board on April 20, and that we likely need to
get our own recommendations to them before that date if they were to be
useful. Well, the NC has now scheduled a meeting and vote for April 18.
So if we're to get our recommendations to them by (say) April 17, and we
allow a week for a formal consensus call, that means we need to settle on
the text of our proposed rough consensus points by April 10, which is . . .
well . . . this Monday. So we need to work fast if we're to accomplish
3. I think it's valuable that we include language directing that
and restricted TLDs be included in the original set. This isn't a new
issue: There was a strong majority in favor of this proposition in the
straw poll we took back in February. I announced at the time that I wanted
to issue a formal consensus call on the issue, but I pulled back because I
didn't want to tread on Philip's toes (that is, I wanted to give S/K a fair
chance to succeed before calling for a vote on a related point).
4. On the "gTLD" terminology: Our charter calls on us to make
recommendations concerning "gTLDs." The term "gTLD," *as used in the WG
charter*, encompasses both open and chartered gTLDs. (For example, the WG
charter treats the question as open whether "each new gTLD [should] have a
specific charter." This isn't so crazy as some folks think; it's
consistent with RFC 1591, in which Jon Postel referred to EDU, GOV, MIL and
INT as all falling within the category of "generic TLDs.")
Several people have urged that we'd do better to adopt the IAHC
terminology, under which restricted TLDs and gTLDs are different classes of
beasts. I've got no objection to that in principle, but I don't want to
set up a terminology that leaves us open to the (incorrect) objection that
recommendations concerning chartered TLDs are beyond our authority. My
inclination, at this point, is just to avoid using the term "gTLD" at all,
to the extent we can -- but I'm open to other ideas.
5. I've revised the last draft of the principles (guidelines,
address the rest of the points people have made. One of my goals was to
make clear that though we are requiring applicants to think about
enforcement issues, and to discuss them in the application, we are *not*
requiring applicants to adopt any particular enforcement mechanism, and in
particular we are not requiring them to control registrations: An applicant
might simply explain that it will be relying on registrants to choose the
particular TLD only if they feel they belong there. As Jamie points out,
this will depend on the nature of the TLD.
So here's my most recent attempt. Bouquets and brickbats welcomed.
- - - -
1. The initial rollout of six to ten new gTLDs, followed by an evaluation
period, should include both open, unrestricted TLDs and chartered TLDs with
more limited scope.
2. An application for a chartered TLD should explain what meaning will be
imputed to the proposed TLD string, and how the applicant contemplates that
the new TLD will be perceived by the relevant population of net users.
3. An application for a chartered TLD should explain the mechanism(s) for
charter enforcement. The simplest possible enforcement mechanisms is
registrant self-selection: that is, if .AUTOMOBILES is set up for entities
in some way associated with the automobile world, the applicant might
simply rely on its understanding that other entities will have no interest
in registering in that TLD. Alternatively, an applicant might choose a
more elaborate, registry-driven enforcement mechanism.
4. The selection of a TLD string should not confuse net users, and so TLDs
should be clearly differentiated by the string and/or by the marketing and
functionality associated with the string.
5. New TLDs are important to meet the needs of an expanding Internet
community. They should serve both commercial and noncommercial goals.
The authorization process for new TLDs should not be used as a means of
protecting existing service providers from competition.