TAG Issue HTTPRange-14 proposed resolution 2004-05-13 http://www.w3.org/2001/tag/issues.html#httpRange-14 Text for the document: The HTTP specification does not constrain the objects which are identified by HTTP URIs, except that they be objects which could potentially support an HTTP interface. There is a class of objects which have an information state -- a state which can be represented as an octet sequence. In HTTP, these are objects which (potentially) support GET. Other protocols have equivalent methods. HTTP also has HEAD, PUT and DELETE methods in support of these objects. Much of this document describes architecture specific to this type of resource. We call this an "Information Resource". The techniques of caching and content negotiation, and the social processes of publishing, apply to information resources. An Information Resource may have secondary resources identified by the same URI followed by a hash and local identifier. The Information Resource is the buiding block of the "information space" -- the familiar hypertext web and also of the Semantic Web. Some HTTP resources support POST. These include the targets of some HTML form actions, and some Web Service ports. The SMTP and NNTP protocols also provide POST methods, providing peer-peer flooding and store-and-forward architectures respectively. The systems which use POST are not, in general, using the information space architecture. New issue: If an HTTP resource supports both GET and POST, then are there any constraints on the relationship between the state of the information in the @@? Response to comment This change is made partially to address Pay Hayes' comment http://lists.w3.org/Archives/Public/public-webarch-comments/2004JanMar/1057.html The comment complains at an ambiguity in the use of vocabulary. Specifically, this change addresses the complaint that "resource": is used with two meanings C and D. This change uses the term "Information Resource" for meaning "C". We still use "Resource" for the meaning "D" (Thing) and apologize for the history which has lead to this strange term. We can't use "Entity" as it has special meanings in XML and HTTP specs. We could conceivably use "Thing" although it has some conotation of concreteness. ____________________