|
> > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf