- From: Paul Prescod <paul@prescod.net>
- Date: Sun, 14 Apr 2002 10:51:01 -0700
- To: Keith Moore <moore@cs.utk.edu>, www-tag@w3.org
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 be. > 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 contexts. > ... 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