- From: Keith Moore <moore@cs.utk.edu>
- Date: Fri, 12 Apr 2002 14:05:01 -0400
- To: Paul Prescod <paul@prescod.net>
- cc: www-tag@w3.org, "Ian B. Jacobs" <ij@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. > > An email *address* has no state. An email address is an address of a > mailbox which has state. not necessarily - or at least that mailbox may be (and often is) no more than a vague abstraction. 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. > 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. RFC 821 does say something like this. But that doesn't mean that the mailbox is meaningful as a source. > 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. "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". 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. Keith
Received on Friday, 12 April 2002 14:05:08 UTC