Subject: RE: IPP>MOD Should IPP notification use http as transport?

From: "Larry Masinter" <[email-masked]>
Date: Fri, 13 Aug 1999 23:42:02 PDT

> (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
body.

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.

---

From: Keith Moore <[email-masked]>
Date: Sat, 14 Aug 1999 09:24:44 -0400

> 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.

> HTTP URIs don't de-encode the data, this is not a good example.

right you are.

Keith