>Date: Tue, 27 Jul 1999 04:19:35 -0700 (PDT)
>From: d3nnis <[EMAIL PROTECTED]>
>Subject: Re: [IDNO-DISCUSS] Re: [IFWP] What I would have said...
>In-reply-to: <[EMAIL PROTECTED]>
>To: Martin Burack <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
>Message-id: <[EMAIL PROTECTED]>
>MIME-version: 1.0
>Content-type: text/plain; charset="ISO-8859-1"; X-MAPIextension=".TXT"
>Content-transfer-encoding: quoted-printable
>Priority: Normal
>X-Priority: 3
>X-MSMail-priority: Normal
>References: Conversation
> <[EMAIL PROTECTED]> with last message
> <[EMAIL PROTECTED]>
>
>There is an international agreement governing telephone numbers,
> and a large body of case law governing TM issues with respect
>to 'vanity' numbers.
>
>The absence of an international agreement relative to domain names, and
>the existence of global IP wars foils the comparison ... but suggests how
>domain names should evolve.
>
>Dennis
>
>----------
>> If analogies are going to be made to the telephony industry,
>> directories are not the right comparison.  People should
>> take a look at the toll-free segment.  There are the
>> equivalents of TLDs (800, 888, and other area codes).  And
>> (although I haven't looked recently, I think) there is a single
>> registry.  However, that registry is a contractor who does not
>> have intellectual property rights to the data.  Rather, the
>> contractor is employed by the industry to maintain the data
>> base.
>>
>> Marty
>>
>> Speaking for myself.
>>
>>
>>
>>
>> At 05:26 PM 7/23/99 +0200, [EMAIL PROTECTED] wrote:
>> >Karl,
>> >
>> >Very good document, indeed.
>> >
>> >Let me state my POV on subject #2 (I have objections also on #1, but =
>as this
>> >has been discussed several times, all readers know where our positions
>> >differ, and there's no need to bore them with another thread).
>> >
>> >I have nothing in principle against multiple roots, I just fail to
>> >understand how this could be a better system than a common root under =
>public
>> >trust.
>> >I find the analogy with the phone system (as you present it) not fully
>> >applicable, as the phone number is a "key" in the system, and therefor=
>e
>> >unique due to the way that the system is built, while the domain name =
>is an
>> >"attribute" of the unique key (the IP address), and therefore could =
>be
>> >duplicated.
>> >The problem comes from the fact that while you use the "key" in the =
>former
>> >system (you call the phone number) you currently use the "attribute" =
>in the
>> >latter (you type in the domain name, not the address).
>> >
>> >The way I see it, either you enforce uniqueness of the TLD across the =
>roots
>> >(and therefore you have a logically unique root which is the logical =
>union
>> >of the roots), or you may well have the TLD resolving differently in =
>two
>> >different roots. In other words, if you have two systems serving .web =
>(IOD
>> >and CORE ?), you may have two different instances of
>> >"i_am_the_best_on_the.web", if one belongs to a registrant with IOD, =
>the
>> >other with CORE.
>> >If I understand your position, you claim that the market will sort out=
> who
>> >will survive, in the sense that service providers will point to the =
>one that
>> >will offer more added value (BTW: to them, not necessarily to the end =
>user).
>> >
>> >This means that you will find the one or the other according to how =
>your
>> >system is set.
>> >It is like saying (in the telephone system analogy) that by calling =
>+1 831
>> >423 8585 you may reach "cavebear" or a subscriber to a different provi=
>der,
>> >according to how your telephone is set. This is far worse that being =
>listed
>> >in one or the other directory. For instance, end users could get diffe=
>rent
>> >two directories, and call numbers referenced in both without any chang=
>e in
>> >the setting of the telephone. This is not true in the ISP-chosen root =
>system
>> >(unless you don't manipulate your own computer, which very few people =
>will
>> >do).
>> >
>> >Of course, as E-Commerce grows, companies are investing more and more =
>in
>> >this new tool, and the last thing that they want is to have their effo=
>rts
>> >jeopardized by the dependency from a setup. And this will be independe=
>nt
>> >from their performance, but the risk factor is related to the performa=
>nce
>> >(as perceived by the service providers) of the Registry they belong =
>to. Up
>> >to the point that they may need to change Registry, and therefore ofte=
>n even
>> >domain name, if their first choice is already taken in the other Regis=
>try.
>> >I believe that commercial organizations see this as a nightmare.
>> >BTW, this is the reason why commercial interests are supporting ICANN:=
> they
>> >have nothing to do with CORE, to whom they are completely incorrelated=
>, but
>> >just feel that between the ethics of holding closed meetings and the
>> >financial risk involved with limited visibility on the Net they consis=
>tenly
>> >choose the lesser evil.
>> >
>> >All what we need, as a first step, is more competition (i.e. new TLDs,
>> >allocated to different players), not to rethink the whole thing over =
>again,
>> >or go into unexplored territory (where what is unexplored is not the
>> >technical feasibility of the multiple roots, which is proven, but its
>> >effectiveness on large scale numbers).
>> >
>> >I will be glad to stand corrected if I missed something of the point =
>you
>> >make and/or if you find a hole in my argumentation, as not only I am =
>not a
>> >lawyer, but I'm not a guru of the IP addressing either ;>).
>> >
>> >Best regards
>> >Roberto
>> >
>> >P.S.: I agree with you on point #3
>> >
>> >
>> >
>> -
>> This message was sent via the IDNO-DISCUSS mailing list. To unsubscribe=
>,
>> send a message containing the line "unsubscribe idno-discuss" to
>> [EMAIL PROTECTED] For more information, see http://www.idno.org/
>
>
>
>
--
Richard Sexton  |  [EMAIL PROTECTED]  | http://dns.vrx.net/tech/rootzone
http://killifish.vrx.net    http://www.mbz.org    http://lists.aquaria.net
Bannockburn, Ontario, Canada,  70 & 72 280SE, 83 300SD   +1 (613) 473-1719

Reply via email to