Formalizing Expires, Last-Modified, "data object"

The current HTTP spec[1] is a tremendous improvement over previous
versions. Great work!

But... :-)

It's unnecessarily informal in its use of the term "data object":

   Full-Request and Full-Response use the generic message format of 
   RFC 822 [6] for transferring data objects. 
(replace "data objects" by "body parts.")

   The data object (if any) sent with an HTTP/1.0 request or response 
   is in a format and encoding defined by the Object-Header fields, 
   the default being of type "plain/text" with "binary" encoding.
(replace "data object" by "body")

   The Last-Modified field indicates the date and time of when the 
   data object was last modified.
(what? now a data object is modifiable? i.e. it has state?)

The term has no definition in the "terminology" section, nor anywhere
else that I can find.

The document correctly borrows the term "body" from the MIME spec. In
the MIME spec, a Body Part is a bunch of headers and a body. A body is
a sequence of octets. A message is a special kind of body part that
has all the right headers, like From:, To:, and Message-Id:. An HTTP
message is a MIME body part, but it doesn't fit the definition of a
MIME message. But all that makes sense. An HTTP message is different
from a mail message, but an HTTP body is the same as a mail body, no?

I suggest the term "data object" be replaced by "entity," or "body" as
appropriate. The MIME spec uses the term "entity" synonymously with
body part. I like entity better than body part. It's shorter, less
confusing with body, and it's conveniently analagous to the term
"entity" in the SGML/HyTime specs.


Then there's this stuff about Last-Modified, Expires, and "data
objects" that change over time.

I suggest that the protocol be defined by the observable behaviour of
correct servers (and clients). For example, the critical property of
the Last-Modified and Expires information for a URI is that the server
stipulates that it will serve the same entity for that URI (given the
same Accept: headers) at all times between the Last-Modified time and
the Expires time.

For a formal treatment of HTTP expires, last-modified, and proxy
caching, please see:

http://www.hal.com/%7Econnolly/drafts/formalism.html


Dan

[1] HTTP Working Group, INTERNET-DRAFT, <draft-ietf-http-spec-00.txt>,
Expires May 23, 1995
http://info.cern.ch/hypertext/WWW/Protocols/HTTP1.0/HTTPDraft.html

Received on Monday, 12 December 1994 19:15:57 UTC