When someone orders a Cable speciality channel or
a direct-TV purchase they do not get read lights but
they WILL be aware and they WILL pay the bill.
At 03:50 PM 3/26/2001 -0800, Ian Cooper wrote:
At 15:17 3/26/2001 -0700, Hilarie Orman wrote:
Adding the headers as protocol elements seems like an
obvious answer for the consumer, but it's only one direction.
And, I'm loathe to add something meant for consumption
by the browser unless the enduser really wants to see
the information.
OK, then I'd suggest changing "will" to "may" in the charter text "...the
content requestor... will be aware that a transformation has been performed".
(And my speel chekker suggests requestor -> requester.)
I'm not sure how folks would be able to debug problems if there wasn't
something obvious in the response/request with which to debug.
I for one would prefer a "MUST".
I keep getting stuck on what the browser (or other consuming
of warning headers) is supposed to do with the warnings. Will
people really add banners or red warning lines around the
modified content (assuming that it really is geometrically
possible)? Keep a log of the modification events in the
same place as all other useless log files that the system
faithfully maintains?
Not exactly our problem, but as someone with some training in UI design I
fully understand your point.
The reverse direction, to the content publisher, noting what
transformations have taken place, well, the only reason
I've ever heard of for notification is if money is involved,
i.e., accounting. I don't think the publisher would want
to know that "the proxy inserted a photo of the consumer's
pet aardvark in place of gif 2239 on page /mumble/foo/baz.htm."
There's also the case where the request itself has been modified.
Michael W. Condry
Director, Network Edge Technology