Re: URL semantics

At 05:45 pm 09-01-97 -0800, Gregory J. Woodhouse wrote:
>Actually, it seems that the real issue here is whether resources are just
>data objects or whether they also include network services such as Telnet,
>SMTP and News. URLs in the mailto: and telnet: namespaces do not retrieve
>data objects but do invoke services. URLs in the news: or nntp: namespaces
>can have semantics of either type, depending on whether the namespace
>specific string is a newsgroup name or a message ID.


What is an object and what is a service?  What is a television channel?
It can be represented by a window on the screen.  It is useful to be able
to link to it.  It has a time component.   An email address is something
you can only post to.  But I am happy for an object to have a conceptual
identity, some interaction with the outside world, and some way of being
represented to a user (or program).  So for example, I would like my
mail reader to represent 

	mailto:gjw@wnetc.com

with any address book information I have about this email address,
plus a list of all messages I have to/from it, plus the ability to
drag and drop messages onto it. 

This doesn't mean that the representation I have will be the
same as anyone else's, but that is the semantics of the object.  
It is still a very well defined object.  An object does not have to
support HTTP "GET" to be a URI. A gateway could of course
provide a sort of GET along the lines above.  What Netscape does
is assume you want to POST to the object, and assume you want
to post a new message.  It's the best they could do for now, and
it's more use than nothing.  But it should not be taken as defining
the effect of GET on a mailto: URL.

A "service" is a resource. If you call resources objects, that would make
it an object -- but if you expect objects to have a public accessible finite
state that would make it not an object.

Tim


>gjw@wnetc.com    /    http://www.wnetc.com/home.html
>If you're going to reinvent the wheel, at least try to come
>to come up with a better one.
>
>

Received on Friday, 10 January 1997 11:07:48 UTC