- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 18 Oct 1996 12:20:06 +0200 (MET DST)
- 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
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 Koen.
Received on Friday, 18 October 1996 03:26:43 UTC