While the topic of "how Mediawiki handles URLs" is on the table, let me point out today's Slashdot piece, which notes that ICANN is about to open up the gTLD namespace...
*to everyone*, not just commercial registries.
Contemplate, if you will:
How will MW handle a FQDN with no dots in it, when that becomes legal?
Cheers, -- jra
On Fri, Jun 17, 2011 at 3:37 PM, Jay Ashworth jra@baylink.com wrote:
While the topic of "how Mediawiki handles URLs" is on the table, let me point out today's Slashdot piece, which notes that ICANN is about to open up the gTLD namespace...
*to everyone*, not just commercial registries.
Contemplate, if you will:
How will MW handle a FQDN with no dots in it, when that becomes legal?
Those are already perfectly legal hostnames to have in URLs, and you see single-part hostnames all the time on internal networks, either by eliding the local domain part (since local DNS will resolve it) or by only using single-part names to begin with.
For a common example: try linking to http://localhost/ -- it works just fine. :)
I suppose "in theory" having "apple" available is no worse than "apple.com" (since you *could* have an "apple.com.mylocaldomain" already and have to worry about which takes precedence), but in practice that sounds like a crappy thing to do. :)
-- brion
----- Original Message -----
From: "Brion Vibber" brion@pobox.com
On Fri, Jun 17, 2011 at 3:37 PM, Jay Ashworth jra@baylink.com wrote:
While the topic of "how Mediawiki handles URLs" is on the table, let me point out today's Slashdot piece, which notes that ICANN is about to open up the gTLD namespace...
*to everyone*, not just commercial registries.
Contemplate, if you will:
How will MW handle a FQDN with no dots in it, when that becomes legal?
Those are already perfectly legal hostnames to have in URLs, and you see single-part hostnames all the time on internal networks, either by eliding the local domain part (since local DNS will resolve it) or by only using single-part names to begin with.
For a common example: try linking to http://localhost/ -- it works just fine. :)
Sure. And http may not be the best example. There's lots of code out there -- email address verifiers, for example -- that *requires* a dot in a hostname.
I suppose "in theory" having "apple" available is no worse than "apple.com" (since you *could* have an "apple.com.mylocaldomain" already and have to worry about which takes precedence), but in practice that sounds like a crappy thing to do. :)
And you make an excellent point I hadn't gotten to yet: collisions between such dotless FQDNs and internal hostnames are *much* more likely - especially since the Usual Suspects in both namespaces are related so closely.
In practice, though, localhost and hosts on your lan -- in which case the DNS lookup is *actually* often a dotted FQDN anyway by virtue of the DNS resolver search facility -- are about the only places dotless FQDNs are generally seen... and lots of code "protects" you from them.
Cheers, -- jra
I suppose "in theory" having "apple" available is no worse than "apple.com" (since you *could* have an "apple.com.mylocaldomain" already and have to worry about which takes precedence), but in practice that sounds like a crappy thing to do. :)
Well, yes, this is exactly why you don't usually use TLDs as subdomains on top of company internal search path. I guess this makes us switch back to IP addresses, if there's a constant chance of conflict we can no longer control :-)
With IPv6 that will be even easier. And who needs DNS when we have Google.
Domas
Has anyone looked into introducing .wiki, initially for Wikimedia, but later for others (the fee could support the foundation)?
On Saturday, June 18, 2011, Domas Mituzas midom.lists@gmail.com wrote:
I suppose "in theory" having "apple" available is no worse than "apple.com" (since you *could* have an "apple.com.mylocaldomain" already and have to worry about which takes precedence), but in practice that sounds like a crappy thing to do. :)
Well, yes, this is exactly why you don't usually use TLDs as subdomains on top of company internal search path. I guess this makes us switch back to IP addresses, if there's a constant chance of conflict we can no longer control :-)
With IPv6 that will be even easier. And who needs DNS when we have Google.
Domas _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Jun 21, 2011 at 12:48 AM, Mono mium monomium@gmail.com wrote:
Has anyone looked into introducing .wiki, initially for Wikimedia, but later for others (the fee could support the foundation)?
Got $US 185,000 handy to cover the application fee?
----- Original Message -----
From: "Stephen Bain" stephen.bain@gmail.com
On Tue, Jun 21, 2011 at 12:48 AM, Mono mium monomium@gmail.com wrote:
Has anyone looked into introducing .wiki, initially for Wikimedia, but later for others (the fee could support the foundation)?
Got $US 185,000 handy to cover the application fee?
I'm sure WMF could come up with it...
but I already spend enough time trying to teach people that "I saw it on Wiki" is *not* a well-enough defined comment.
Wikipedia != MediaWiki != "Wiki".
Cheers, -- jra
wikitech-l@lists.wikimedia.org