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: Larry Masinter <masinter@parc.xerox.com>
Date: Fri, 13 Aug 1999 23:42:02 PDT
To: Keith Moore <moore@cs.utk.edu>, "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>
Cc: ipp <ipp@pwg.org>, HTTP Working Group <http-wg@hplb.hpl.hp.com>
Message-ID: <000201bee620$1d812f20$15d0000d@copper.parc.xerox.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/513
> (connection opened)
> >>> GET /printer/status/job#2343 HTTP/1.1
> >>>
> <<< Content-type: application/ipp-status-messages
> <<<
> (pause)
> <<< status: page 1 printed
> (pause)
> <<< status: page 2 printed
> (pause)
> <<< status: page 3 printed
> (pause)
> <<< status: out of paper
> (pause)
> <<< status: resumed
> (pause)
> <<< status: page 4 printed
> <<< status: job complete
> (connection closed)

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. I know
people do this, but I'd be reluctant to recommend it, because
it interacts badly with caches and will the recommended semantics
of HTTP as a request/response protocol.

If one of the (pause)s is, say, a minute, some intermediary
might just break off the connection as stalled. And then there's
no particular guarantees of completeness. A proxy might
legitimately want to buffer the entire response, sending
back '100 continue' messages, and then batch the entire message

Also, the URI has a problem:


Since '#' is a reserved character for fragment delimiter, and
HTTP URIs don't de-encode the data, this is not a good example.
Received on Friday, 13 August 1999 23:45:54 UTC

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