Re: "resolution mechanism"

Keith Moore wrote:
> not necessarily - or at least that mailbox may be (and often is) no
> more than a vague abstraction.

Anything on the other side of the wire starts out as a vague
abstraction. You send messages, you get responses, it becomes concrete.
An HTTP-referenceable web resource is no more or less vague an
abstraction. It only seems concrete because the protocol allows it to

> the point is that an email address is fundamentally and by design
> a *sink*, not a *source*. trying to model an email address as a
> source for which a GET operation is somehow generally meaningful
> is just refusing to recognize this fundamental aspect.

That is not true. The VERIFY and EXPAND commands makes it an information
source. The only change I would make is that if I were inventing SMTP
today I would make it return XML so that the return values for these
commands could be easily extensible.

> "dereferencing" a resource name and GETting a resource name are different
> things.  And there's no point in overloading GET to mean so many different
> things - it just invites confusion.  Right now GET means in practice
> "what the resource wants to return when someone clicks on this link or
> types in this URI to a web browser".  

That's incorrect. GET is used in non-browser situations every day. RPM,
XSLT, XML Schema, XInclude, XBase, they all use GET in non-browser

> ... This is useful.  But if you try to
> make GET do arbitrary things, or you try to make all resources support
> some kind of GET, then you dilute the value of GET that exists now.

How so? GET means "get me information associated with this URI". Nothing
more, nothing less. That's what I mean by dereferencing a URI.

 Paul Prescod

Received on Sunday, 14 April 2002 13:55:02 UTC