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.com/, http://foo.ietf/, http://foo.microsoft/, etc.
will resolve correctly on all versions of Windows, with no changes
needed.
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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf