Re: no-transform

>
>To: jg@w3.org
>Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: no-transform
>In-Reply-To: Your message of "Wed, 05 Jun 1996 16:37:01 EDT."
>             <9606052037.AA13691@zorch.w3.org> 
>Date: Wed, 05 Jun 1996 22:51:57 -0700
>From: "Roy T. Fielding" <fielding@liege.ics.uci.edu>
>Message-Id:  <9606052252.aa23362@paris.ics.uci.edu>
>Content-Length: 982
>
>The messages on this thread in support of no-transform (or, I should
>say, in support of transformations) may be accurate, but they do
>not reflect what is currently specified as "no-transform".
>
>Any change in image formats is a change in media type, not content coding.
>

I've looked at the words too many times...

In any case, you are right, the words are wrong and explain things in
incorrect/misleading ways.  They must get fixed.


>In any case, I do not consider such a beast to be a cache.  If it is
>changing the content of the messages, then it is acting as an
>inter-protocol gateway.  As such, it has nothing to do with cache-control
>and should be left to a more complex negotiating apparatus like PEP.

That is your definition; others have already adopted a looser
definition, independent of what you (or maybe me) would like.  What
you or I might like, or recommend, has little to do with the reality
of what people are already doing, or likely to continue doing. 

Right now, people may get the wrong answer, and content providers are already
having much trouble.

You have a valid point that saying it is a cache control issue
may be misleading.  (And hiding it as part of cache-control may reduce
its penetration.) It is an issue that is pretty independent of caches.
Arguing that no-transform should be a separate header field makes sense, but
as in fact most of these also do caching, it makes some sense where it is.

Would you be happier if no-transform were its own header?

>
>It is clear that this thing is not ready for prime time, and therefore
>should be removed from the proposed standard.  I have many more relevant
>and better specified additions to HTTP which have been removed for the
>same reason.
>

If we did not already have the data in hand (this week's mail) that
this is already a significant problem, I'd agree with you.  As it is,
we now know it to be a real problem, and I don't think we can get up
on our high horse and ignore what is already a significant operational
problem.  Given the reality of the problem, it seems more than
relevant to me.

And according to what I understand IETF process to be, removal of features
at draft is permitted (maybe you should have pressed harder for some of your
additions) (if there are no interactions among features).
				- Jim

Received on Thursday, 6 June 1996 03:59:15 UTC