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