- From: Reto Bachmann-Gmür <reto@gmuer.ch>
- Date: Tue, 15 Jan 2008 22:15:51 +0100
- To: public-sweo-ig@w3.org
- Message-ID: <478D2287.8060703@gmuer.ch>
From http://www.w3.org/TR/2007/WD-cooluris-20071217/ > Given only a URI, machines and people should be able to retrieve a > description about the resource identified by the URI from the Web. > Such a look-up mechanism is important to establish shared > understanding of what a URI identifies. Machines should get RDF data > and humans should get a readable representation, such as HTML. The > standard Web transfer protocol, HTTP, should be used. I think there are reasons to deprecate use of HTTP URIs for real-world object as promoting the assumption that dereferencing such a URI yields to an authoritative definition is dangerous. * DNS is centralistic o I don't know if control has passed from the US DoC to UN WSIS or to someone else. The root servers are controlled by a more or or less democratic central authority and so are the different top-level domains. Relaying on HTTP URIs is relying on the DNS system which means trusting all authorities of the different levels of the domain name. This seems incompatible with the design principle of decentralization [1]. * HTTP is insecure o One cannot know if an HTTP response comes from where its supposed to come from, or whether it has been modified or read on the way to my computer. Even if I can still encrypt all my actual communication, having to look up the definitions of the used terms over an unencrypted connection compromises my privacy. * Uncool URIs happen o In an ideal world Alice will always control the response for http://www.example.com/id/alice. In the real world however: + Alice's server might by cracked + Alice might have forgotten to renew the domain name + Alice might be unable to pay for the hosting or for the domain + The revolutionary guard might have taken control over 7 root servers redirecting all imperialistic domains to educational content :) + ... Cheers, Reto 1. http://www.w3.org/2003/01/Consortium.pdf
Received on Tuesday, 15 January 2008 21:16:06 UTC