v11-03 COMMENT: 16.1 Semantic Transparancy

I have several big problems with the use of the term `semantic
transparancy' in the draft.

Problem 1: absence of semantic transparancy is not something a cache
---------- should be asked to detect

This problem is perhaps best illustrated by a qoute from the draft:

  16.1.3 Warnings

  Whenever a cache returns a response that is not semantically
                                              ^^^^^^^^^^^^^^^^
  transparent, it must attach a warning to that effect, using a
  ^^^^^^^^^^^     ^^^^
  Warning response header.


According to the definition of semantically transparent:

  [...] When a client makes
  a request via a semantically transparent cache, it receives exactly
  the same entity headers and entity body it would have received if it
  had made the same request to the origin server, at the same time.
  [...]

a `response that is not semantically transparent' is `a response that
does not contain exactly the same entity headers and entity body that
could be received from the origin server at the same time'.

But this means that only way for a cache to know whether its cached
response is still not semantically transparent is to contact the
origin server.  So the sentence

  Whenever a cache returns a response that is not semantically
  transparent, it must attach a warning to that effect, using a
  Warning response header.

is nonsensical, because it requires a cache to attach a warning header
to all fresh responses served without contacting the origin server.

The sentence _should_ be:

  Whenever a cache returns a response that is STALE, it must attach a
  warning to that effect, using a Warning response header.

This confusion between `not semantic transparent' and `stale' occurs
at several points in section 16.1.

Problem 2: semantic transparency is a binary property
---------

`Semantically transparent' is defined as a binary property.
Therefore, a sentence like

  Both of these options increase constraints on the behavior of
  caches, and so cannot decrease semantic transparency.
                        ^^^^^^^^

is meaningless.  What is probably meant is `cannot increase the
freshness lifetime' or `cannot lead to a loss of correctness'.

Problem 3: semantic transparency is not very relevant to HTTP/1.1
---------

The Caching section starts out with a discussion of semantic
transparency in section 16.1.  Not only does this discussion contain
many errors (see above), it also would lead a cache author to believe
that semantic transparancy is the key concept in the HTTP/1.1 caching
model.

Well, it is not.  Freshness is the key concept.  So Section 16 needs
to open with a discussion of freshness.

The specific caching mechanisms of HTTP/1.1 can only be meaningfully
discussed after the concept of freshness is introduced.  Much of the
problems in 16.1 seem to be caused by a failed attempt to explain key
features without using the freshness word.  Section 16.2.1, which
introduces freshness, should appear _before anything else_ in Section
16.


Proposed solution to these problems:
------------------------------------

1) Delete the parts of section 16.1 which discuss semantic
   transparency.

2) rewrite the rest of 16.1 in terms of freshness and staleness, and
   move it to somewhere after section 16.2.1.

3) rewrite the start of section 16 to make it clear that freshness,
staleness, and revalidation are the key concepts.

Also, I think that 16.1 is too verbose, but that is another matter.

I would be willing to supply diffs that implement the above solution
if Jim Gettys asks me to write them.

If semantic transparancy stays, I want at least want my problems 1 and
2 above to be resolved or explained away.

Koen.

Received on Friday, 17 May 1996 13:49:43 UTC