[
Lists Home |
Date Index |
Thread Index
]
[Didier PH Martin]
>
> I personally think that using URLs for everything is a kind of reasoning
> that could receive the same kind of counter-argument as using HTTP to
> tunnel SOAP requests. It's using something indented for a certain usage
> for an other one.
Many people have said that an HTTP url is specifically for retrieving a
resource via HTTP. But the RFCs do not exactly say this. Here are some
quotes from RFC 2396 that bear on the point:
(1) "An identifier is an object that can act as a reference to something
that has identity"
(2) "Having identified a resource, a system may perform a variety of
operations on the resource, as might be characterized by such words as
`access', `update', `replace', or `find attributes'."
(3) "A URI can be further classified as a locator, a name, or both."
(4) "Although many URL schemes are named after protocols, this does not
imply that the only way to access the URL's resource is via the named
protocol. Gateways, proxies, caches, and name resolution services might be
used to access some resources, independent of the protocol of their
origin..."
(5) "A resource can be anything that has identity. Familiar examples
include an electronic document, an image, a service (e.g., "today's weather
report for Los Angeles"), and a collection of other resources. Not all
resources are network "retrievable"; e.g., human beings, corporations, and
bound books in a library can also be considered resources."
(1) says that a URI is a reference to something that "has an identity". (5)
clarifies that a thing with an identity need not be retrievable over a
network. (2) says that the identification function is primary, and actual
operations on the identified resource are secondary so far as the function
of a URI is concerned.
(3) says that some URIs can be both an identifier and a locator. This seems
to make an http: URL a candidate for (3)-hood (i.e., "both"). (4) tells us
that it an http: resource can be accessed some other way than by using HTTP,
which decouples the http: scheme from HTTP, at least to a degree.
When I put these all together, I think the least that we can say is that the
RFC is compatible with using the http: scheme to identify
non-network-retrievable resources. This puts the question squarely into the
social or psychological domain - is it a good idea, given some people's
expectations?
I realize that all of these points have been made earlier in these threads,
one way or another. I am just looking at what support the RFC(s) have for
them.
Cheers,
Tom P
|
