W3C home > Mailing lists > Public > www-tag@w3.org > April 2002

Re: "resolution mechanism"

From: Keith Moore <moore@cs.utk.edu>
Date: Fri, 12 Apr 2002 11:26:08 -0400
Message-Id: <200204121526.g3CFQ8l09364@astro.cs.utk.edu>
To: Mark Baker <distobj@acm.org>
cc: Keith Moore <moore@cs.utk.edu>, "Ian B. Jacobs" <ij@w3.org>, "Simon St.Laurent" <simonstl@simonstl.com>, www-tag@w3.org
> Can you identify anything that doesn't have at least one possible
> representation of its current state?

an email address has no state.  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.

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.

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

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

bottom line: not all resources have a meaningful notion of "state"
that is useful outside of the context of that resource, and it's not
always possible to export or translate that context.  even for resources
that do have state, it's unreasonable to expect that exporting such
state is useful or desirable.


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.
so defining GET to return "a possible representation of the current
state" would conflict with widely deployed reality.
Received on Friday, 12 April 2002 11:26:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:31 UTC