Re: URL semantics

Dave Lewis writes:
 > If one GETs the resource 'telnet: invoked session' it results in a 
 > session - no problem.  If one 'GETs a 'mailto: invoked interaction' one
 > achieves the result that an interaction occurs (one gets an interaction) -
 > no problem.

I could live with this use of GET, but I'm afraid we might be GETting
in trouble because of the strong association to getting an object
rather than invoking an interaction.  "DO" might be better.

 > I fully agree.  The URL (or URI) identifies a resource onto which
 > application of a certain set of methods will make sense.

Right.  And some of the applicable methods might not do anything at
all with the identified resource or its associated server.  For
example, to get a content rating for a resource, you would probably go
somewhere else.  (Note: In an important sense, the URL identifies the
content rating when you use it to interact with a service that
provides content ratings.)

 > GET works for me if we view identified resources as such.  In this
 > fashion it currently acts as a sort of universally applicable method.
 > Should there be a set of universally applicable methods?  Yes, if only
 > to retrieve info on the set of methods applicable to an identified 
 > resource.  That is, as we increasingly see a unique set of methods 
 > applicable for any given URI identified resource, we should introduce 
 > means of learning the nature of these sets.

We will probably never have a universal set of methods across all
URI schemes.  Maybe we will for all resources identified within
some particular scheme.  

But the universal methods you are suggesting for discovering the other
methods are really at a meta-level, and it is questionable whether
these are methods on the resource itself or on some meta-resource,
such as a collection or server.  Maybe this distinction doesn't really
matter, but then where *is* the resource if we can interact with many
different services to get partial information about the resource?

 > [...]  In certain context the semantics are extended, overloaded,
 > or (yuk) overridden.   This doesn't appear to me to warrant throwing out
 > the notion of universal method but does suggest documenting both the
 > intended semantics as well as nature of process by which they may be 
 > modified in context.

I'm fine with defining *intended* semantics, but I think it is
important to realize that there *can be no limit* to the alternative
semantics that clients might impose on a URI.  Clients can do whatever
they want as long as they can find some server that will talk with them.
And there will be several reasonable alternative semantics and associated
services created and used widely, such as content rating services.

dan

Received on Thursday, 9 January 1997 17:04:20 UTC