- From: Dan Brickley <danbri@w3.org>
- Date: Fri, 16 Nov 2001 09:14:28 -0500 (EST)
- To: <Patrick.Stickler@nokia.com>
- cc: <fielding@eBuilt.com>, <a.powell@ukoln.ac.uk>, <www-talk@w3.org>, <uri@w3.org>
On Fri, 16 Nov 2001 Patrick.Stickler@nokia.com wrote: > > > The HTTP > > specification > > can only talk about those aspects of the protocol that are relevant to > > HTTP. > > You've just summed up, IMO, the whole issue in a nutshell. The > HTTP URI is relevant only to the semantics of the HTTP protocol. > And the HTTP protocol is for *access* of concrete web resources. > Thus HTTP URIs are only intended to be meaningful to processes > based on the HTTP protocol, which expect to *return* something. > Therefore HTTP URIs are not intended to denote abstract concepts. SOAP Web Service endpoints can be named with http:* URIs, and communicated with via XML representations shipped over HTTP. But you can't download the service itself; that wouldn't make sense. When you think of HTTP as a way of talking to some (possibly authoritative) service about URI-named resources, this whole URI thing makes a bit more sense. If you think of it as a glorified form of file-sharing (like NFS, Samba etc) URIs for abstractions seem odd. Dan
Received on Friday, 16 November 2001 09:14:57 UTC