- 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