W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1999

Re: IPP>MOD Should IPP notification use http as transport?

From: Keith Moore <moore@cs.utk.edu>
Date: Sat, 14 Aug 1999 09:24:44 -0400
Message-Id: <199908141324.JAA20680@astro.cs.utk.edu>
To: Larry Masinter <masinter@parc.xerox.com>
cc: Keith Moore <moore@cs.utk.edu>, "Herriot,\ Robert" <Robert.Herriot@pahv.xerox.com>, ipp <ipp@pwg.org>, HTTP Working Group <http-wg@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/515
> I don't like this example (of using GET for printer status)
> without any cache-control headers, and with the presumption
> that the entity body is streamed with indefinite pauses. 

understood.  I realized that such headers would be needed when
I wrote the example, but am not so intimately familiar with
HTTP that I could cite them off the top of my head; and I didn't
want to take the time to look them up on a Friday night.  sorry.

I suspect that few present-day proxies will want to buffer the entire 
response before relaying it to the client, because buffreing the
entire response is now known to a significant and very annoying affect 
on response time.  

at any rate, to the extent that we believe that this technique won't 
work, then to me that is a good reason to abandon the idea of using 
HTTP for printer notifications.

> Also, the URI has a problem:
> /printer/status/job#2343
> Since '#' is a reserved character for fragment delimiter, and
> HTTP URIs don't de-encode the data, this is not a good example.

right you are.

Received on Saturday, 14 August 1999 06:31:25 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:06 UTC