Message-Id: <9412130307.AA05660@ulua.hal.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: Formalizing Expires, Last-Modified, "data object"
Date: Mon, 12 Dec 1994 21:07:34 -0600
From: "Daniel W. Connolly" <connolly@hal.com>
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