Re: URI registries and schemes

getting right to the point...

Mike Schinkel wrote:
>> personally, i would find such a "magic domain" concept 
>> becoming an essential part of the web architecture a bit 
>> weird, but i seem to be the minority.
>     Would be be willing to explore why you find it weird? I find the concept
> beautifully elegant, but like a programming language with a few core
> concepts where everything is built out of those core concepts and almost
> nothing is "special" (maybe that is why I like Python and dislike PHP...) In
> reading your emails I've been trying to figure out what fundamentally makes
> you so adverse to the concept on top of HTTP?  I really would appreciate
> understanding your point of view on this. Thanks in advance.

several reasons, hopefully one of looks at least plausible. the obvious one:

"nothing is special"? you introduce the concept of magic domains and 
don't even say how i can find out about which magic domains exist and 
that means "nothing is special"? to me this is much more like "nothing 
looks special even though it is special" (the magic domains look like 
normal dns names, but they are heavily loaded with semantics and rules 
and organizational structures backing them and maybe even some registry 
listing all of them), but that just pushes complexity into me needing to 
detect (dynamically, maybe?) which domains are magic.

reason 1:

i would have to call back all students which i taught about web 
architecture and uri schemes in the last years and now tell them that 
no, uri schemes are not used for new resources. they only exist for 
legacy stuff and http, and that's it. all new schemes go through 
http://{magicdomain.org}. and there is a registry of magic domains 
somewhere, because how else would i know what magic domains are out 
there? and the registration process would look suspiciously similar to 
the process of uri scheme registration. and the magic domain owners 
would not be required to actually run a server at 
http://{magicdomain.org}, because, over time, everybody knows the magic 
domains. why don't we invent a new gtld .magic for these domains, or why 
not just make that .uri? then we could push magic domain detection and 
registration completely into the dns...

reason 2:

the argument that some informational page provided by the magic domain 
foundation (which is the one thing that seems to be the most important 
thing in that debate) is better than an error message and so much better 
that it is worth to undermine one of the fundamental web architecture 
principles just does not convince me. you are attributing that to my 
lack of pragmatics, and that might be it, but i would rather call it my 
preference to stick to a design that works. and btw, i am still waiting 
for an example where this foundation idea did work out. and that does 
not even get to the point who is keeping track of the foundations and 
the schemes they define for their uris.

reason 3:

errors occur. it is no big deal when some client says "i don't know what 
to do with that". it happens with unsupported content types. it happens 
with broken links. so what? get the plugin. use the waybackmachine. or 
in case of an unsupported uri scheme: get a client that supports it. we 
should not base the design of the web based on our wish to prevent 
things from breaking. maybe firefox could do better than popping up a 
window with a pretty stupid error message text, but that is really not a 
good starting point for a pretty important decision. and usually, it is 
just the other way around, systems that try to prevent everything from 
breaking end up colliding under their own load of safeguarding and 
backup and fallback mechanisms.

reason 4:

if there is some need to get rid of things in the uri space, get rid of 
urns. they serve no purpose at all. the urn: prefix has absolutely no 
semantics other than pointing to a different registry than the one for 
uris. retire urns, merge http://www.iana.org/assignments/urn-namespaces 
with http://www.iana.org/assignments/uri-schemes.html, and simply say 
that the "urn scheme" "isbn" henceforth is the "uri scheme" "urn:isbn" 
and so on. nothing breaks, and a really unnecessary part of web 
architecture has been safely removed. or has anybody ever seen a generic 
urn processor that processes various urn schemes based on some parsing 
of the urn, and then dynamically selecting the resolver for a variety of 
urn schemes? it would still work, btw, but it would not adapt well to 
the new web of urn-less uris... (the one thing i am ignoring here is the 
fact that "urn:isbn" cannot be a uri scheme because of the colon, so i 
am a bit too optimistic how easily urns could be retired).

cheers,

dret.

Received on Thursday, 13 December 2007 23:50:43 UTC