W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: 13.1.2 Warnings

From: Koen Holtman <koen@win.tue.nl>
Date: Fri, 18 Oct 1996 12:20:06 +0200 (MET DST)
Message-Id: <199610181020.MAA07109@wsooti12.win.tue.nl>
To: Daniel DuBois <dan@spyglass.com>
Cc: ben@algroup.co.uk, dan@rafiki.spyglass.com, luotonen@netscape.com, masinter@parc.xerox.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1813
Daniel DuBois:
>>Perhaps we have different ideas of what "transparency" means, but it seems to
>>me that receiving an entity with an erroneous header is not transparent. It
>OK, you are right.  I was thinking about transparancy of the entity body.
>But in the HTTP spec, semantic transparency is defined as 'exactly the same
>response (except for hop-by-hop headers)'.  Warning, although added in a
>middle hop, I dont believe can be considered a hop-by-hop header.

I don't think there is a wording problem here: the spec talks about
_weakening_ the transparency.  I read 

 Warnings are always cachable, because they never weaken the transparency
 of a response.

to mean `.., because they never cause a stale response to be
interpreted as fresh'.

Aside: though I don't think that the sentence is _wrong_, I do think
it is potentially confusing.  I have argued repeatedly in the past
that the term `semantic transparency' is useless for describing HTTP,
and that it should therefore not be used in the draft.  Like
`idempotence', the term `semantic transparency' will haunt us for
years to come.

>Daniel DuBois

Received on Friday, 18 October 1996 03:26:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:21 UTC