RE: Opinion on Notify Request Header

1. The problem with automatically sending update information is that it
will break many clients. HTTP 1.1 clients do not handle unsolicited
responses very well. HTTP 1.0 clients would probably go insane. So we
need a way for a client to indicate that they can handle unsolicited
responses. Hence the header.
2. As for building into OS's, Sockets come to mine.

				Yaron

>-----Original Message-----
>From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
>Sent:	Sunday, November 03, 1996 11:06 PM
>To:	Yaron Goland
>Cc:	ejw@ics.uci.edu; w3c-dist-auth@w3.org
>Subject:	Re: Opinion on Notify Request Header
>
>I'm not questioning the need for asynchronous progress
>notification. I'm questioning the need for a request header to ask for
>it.
>
>A simpler approach would be to say that servers should always send
>back progress indications for long-running requests with whatever
>frequency they deem reasonable to implement, and that clients should
>accept progress indications and ignore them if they want.
>
>If 100 Continue isn't adequate for what you want (and I suppose it
>isn't), propose a different response.
>
># This sort of asynchronous notification solves a problem so fundamental
># it has been built into just about every OS known to humanity.
>
>While I know of lots of progress-reporting mechanisms, I don't know
>any that are built into operating systems, and I thought that most
>distributed systems wind up inventing their own. Many networking
>protocols don't contain any such mechanisms even when they're needed.
>
>What is the asynchronous notification mechanism built into any of:
>Multics, MS DOS, Unix, Tenex, the Alto OS, MacOS, Windows?
>
>I don't remember anything like this in ONC/SunRPC, Grapevine, XNS
>Courier, SMTP, HTTP. FTP has a progress header, but its application is
>limited. Unless you're thinking of something else?
>
>Could you explain what you mean by 'built into just about every OS
>known to humanity'?
>
>Larry
>

Received on Monday, 4 November 1996 03:20:40 UTC