RE: Update of RFC 2606 based on the recent ICANN changes ?

Bernard Aboba <> Wed, 02 July 2008 22:47 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 460913A6A50; Wed, 2 Jul 2008 15:47:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B77943A6A50 for <>; Wed, 2 Jul 2008 15:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.131
X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id azXqAs2oOfBx for <>; Wed, 2 Jul 2008 15:47:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4D5C03A63D3 for <>; Wed, 2 Jul 2008 15:47:42 -0700 (PDT)
Received: from BLU137-W5 ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jul 2008 15:47:48 -0700
Message-ID: <BLU137-W58CFC85451C5BF25F294D93990@phx.gbl>
X-Originating-IP: []
From: Bernard Aboba <>
To: John C Klensin <>
Subject: RE: Update of RFC 2606 based on the recent ICANN changes ?
Date: Wed, 2 Jul 2008 15:47:48 -0700
Importance: Normal
In-Reply-To: <1351DF4C8872F74C5F8D4744@p3.JCK.COM>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <1351DF4C8872F74C5F8D4744@p3.JCK.COM>
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Jul 2008 22:47:48.0783 (UTC) FILETIME=[A6DD7BF0:01C8DC95]
Cc: IETF Discussion <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1373765052=="

> > Another like restriction that might be investigated is whether> > http://microsoft/ or other similar corporate TLDs would work> > as intended with deployed legacy browsers. 
I think there are two orthogonal issues which are being conflated here. 
One issue is the ability of existing implementations to support services 
hosted within a TLD (e.g. http://com/).  A separate issue relates to 
the creation of new TLDs.  Creating new TLDs does not necessarily
imply hosting of services within a TLD, although this could be an
(unintended) consequence. 
> > I suspect (but have not tried) that if you simply type> > 'Microsoft' into the address bar of some browsers you might> > have the keyword immediately interpreted as a search term, not> > an address to visit.
While I can't speak for the behavior of any browser, no application 
relying on the Windows resolver will behave in this way,
including IE or Mozilla. 
> I suspect that, if Microsoft spent a hundred thousand dollars or> more to secure "microsoft." as a TLD, at least one of those> browsers would be swiftly corrected in a way that they would> find satisfactory.
Again, several issues are being conflated here., http://foo.ietf/,, etc. 
will resolve correctly on all versions of Windows, with no changes
 > But none of that counts. There have been more than enough> actors who have wanted TLDs that violate one rule or another,> assuming that applications authors will sort things out as> needed, maybe even with IETF help. And there have been more> than enough who believe that, if some construction they want> works with the world's most popular browser, then it is> sufficient (non-web protocols be d**ned).
As noted above, the issue is not just the interaction of new TLDs
with one or more implementations.  There is also the issue of
the usage of the new TLDs, specifically the hosting of services
within them. 
Ietf mailing list