Re: "resolution mechanism"

Keith Moore wrote:
> 
> > Can you identify anything that doesn't have at least one possible
> > representation of its current state?
> 
> an email address has no state. 

An email *address* has no state. An email address is an address of a
mailbox which has state. For instance it either does or does not still
exist. That's state. There may be alternate addresses for the mailbox.
It would be useful to be able to query them. The mailbox may support
multiple access protocols. The mailbox may represent a human being with
a name, picture and other metadata. etc.

> ...  if you send mail to that address it
> might or might not end up in a mailbox that has state, but the
> name of the mailbox and the email address may have nothing in common,
> and be subject to change on a per-message basis.  so it's unreasonable
> to expect that the state of any mailbox to be associated with the
> email address.

It's merely a question of definition. If the powers tha be say that
every email address maps to a logical (not physical) mailbox then that
becomes the case.

> even if you consider the email address to have some state that dictates
> the actions by which messages are processed, often that state can only be
> evaluated within some narrow context - you can't expect to be able to
> do anything useful with it outside of that context.  so while a GET
> on mailbox A might dump some state, you couldn't expect to meaningfully
> compare it with a GET on mailbox B.

So what? Does a GET on foobar.com necessarily give you something useful?
It depends on foobar.com and what you define as useful!

> a host has state, but GET is not a useful operation for a host either.

WHY NOT??? If it has state then GET is a useful operation for
bootstrapping your way into that state.

> an IP address has no state, but it's useful as a resource name.

I disagree. You might want to ask an IP address what ports are exposed
upon it. (of course you also might want to be very careful who you give
that information to!)

The point is that new URIs should always be dereferencerable because you
MAY DECIDE LATER that you want to associate state with them and turning
a non-derferencerable URI into a dereferencerable one is incredibly
difficult. It's short-sighted design to cut yourself off from being able
to deliver a representation of state later.

>...
> also, GET in HTTP quite often doesn't return the 'current state' of the
> resource; rather, it creates a new resource for you or your device.

That isn't true by virtue of HTTP's definition of GET.

> so defining GET to return "a possible representation of the current
> state" would conflict with widely deployed reality.

I disagree. The *implementation* is to create a new data object. The
logical web-model is that you are retrieving a pre-existing resource.
Thanks to the encapuslation provided by HTTP there is really no way for
someone using the protocol to divine the implementation. I guess that
Google results are automatically genreated web pages but I don't know
for sure that that's true of any particular one.

 Paul Prescod

Received on Friday, 12 April 2002 13:12:23 UTC