- From: Larry Masinter <LMM@acm.org>
- Date: Mon, 05 Dec 2005 12:02:08 -0800
- To: "'Dan Connolly'" <connolly@w3.org>
- Cc: www-tag@w3.org, noah_mendelsohn@us.ibm.com
> I think that's a little too strong. Here's a rule that I think I > subscribe to: > > If you can access a resource via HTTP, then it has a name > that starts with http: Well, this isn't completely true; there are more things that you can do with the HTTP protocol than you can describe using "http:" URIs. There are lots of ways in which you might have resources that can only be accessed using POST with specific data that have no way of describing using a URI. URIs are not "Universal" (there isn't a URI for everything). Some resources that are accessible via HTTP have URIs (not "names", just "URIs") starting with "http:". > and > > If it has a name that starts with http://..., then you may > use HTTP to access it. > > but not > > If it has a name that starts with http://..., then you must > use HTTP to access it. If there is a resource that is only accessible using the HTTP protocol, then anyone wishing to access it must, in fact, ultimately use the HTTP protocol to access it, unless there's some agent willing to provide access using some other protocol, and the URI interpreter knows about that agent and trusts it. I'm not sure of the point of providing normative language here, though. If an agent is given a name that starts with "http:", the agent should use whatever means are available to access the resource. That access might be directly, using the HTTP protocol, or through some other agent or service. But it makes no sense to encourage the use of "http:" URIs for resources that are not accessible using the HTTP protocol, nor to limit the variety of proxies or whatever that also might provide access. Larry -- http://larry.masinter.net
Received on Monday, 5 December 2005 20:02:06 UTC