IPP Mail Archive: Re: RE: IPP>MOD Should IPP notification use http as t

Re: RE: IPP>MOD Should IPP notification use http as t

kugler@us.ibm.com
Tue, 17 Aug 1999 10:28:44 -0600

original article:http://www.egroups.com/group/ipp/?start=6172
> > (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

If we use multipart responses to send notifications following up an IPP
Operation like Print-Job, we don't have to worry about caches, since all
existing IPP operations use the POST method, and POST responses are NEVER
cacheable.

> and will the recommended semantics
> of HTTP as a request/response protocol.
>
We might as well ask "Should IPP use HTTP as its transfer protocol?" (In fact,
several people did ask that, in 1997.) I think we've already blown the
recommended semantics of the Hypertext Transfer 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.

In general, IPP won't work over proxies anyway. This is because HTTP/1.1
applications MAY refuse to accept the chunked transfer-coding in requests, and
most (by far) DO reject chunked POST requests. In any case, the client always
knows if it's connecting through a proxy, so we can fix this issue by adding a
rule saying that clients SHOULDN'T request notifications via multi-part
responses when communicating through proxies.

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