- From: Yaron Goland <yarong@microsoft.com>
- Date: Mon, 4 Nov 1996 16:53:17 -0800
- To: "'Larry Masinter'" <masinter@parc.xerox.com>
- Cc: "'fielding@liege.ics.uci.edu'" <fielding@liege.ics.uci.edu>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
I disagree. Servers have absolutely no knowledge of what a client is up to. This is especially true when that client is sitting behind a proxy. The server sees a full Internet connection but on the other side of that connection is a modem. This is not acceptable from an implementation point of view. The result will be that proxies will kill these messages and clients who do wish to pay for the information will be left in the dark. Sometimes there are no clean solutions, Yaron >-----Original Message----- >From: Larry Masinter [SMTP:masinter@parc.xerox.com] >Sent: Monday, November 04, 1996 4:42 PM >To: Yaron Goland >Cc: fielding@liege.ics.uci.edu; w3c-dist-auth@w3.org >Subject: Re: Opinion on Notify Request Header > ># Sending those headers involves overhead, a lot of overhead on slower ># links. We should have a means of indicating if we want a particular ># response stream. I know, I know, its not a proper use of a header. I ># agree and am open to suggestions. Where is the balance to be struck? > >Since there's a way that servers can send these kinds of responses >when they see fit, and the servers are just as qualified as the >clients to know when it's a good idea and when it's a waste of >bandwidth, why don't we just put in the response notification and >leave the request-for-response-notification behind. > > >Larry > > > >
Received on Monday, 4 November 1996 19:53:13 UTC