Carl and I still feel that a native form of IPP notification is desirable.
One example is requesting a printer to pause and responding that the
operation was accepted vs. asking a printer to pause and responding with
the accept, an interim state change (moving to paused) and the final
condition (paused). Another example is a print job that is aborted and
subsequently (rapidly) removed from the IPP printer. With polling (only)
the job may seem to have just disappeared. With native notification (even
IF events were concatenated by a proxy) there would at least be an event
"trail".
Carl had proposed a persistent connection with MIME Multipart/Mixed in the
response. The criticisms were
1. Persistent connections... how many and how long? Certainly not one per
job (with queued jobs) and certainly not for the duration of a (queued)
job?
2. But what if a proxy were to concatenate the chunked responses into one
response with known content length?
3. Even if the proxy doesn't buffer the response, and "Server Directed
Polling" reduces the time for a persistent connection, how long do proxies
typically allow the connection to remain open before they time out?
I wrote a proposal with "Server Directed Polling" to address the first
issue. Server directed polling is a more efficient method than arbitrary
periodic polling and would be used, appropriately, while a print job is
making it's way through the queue or when the job had been placed on hold
or any time during the process where actual processing of the job is not
imminent.
When job processing was imminent (within an anticipated time frame
determined by the IPP printer... not some hard specified time... a
persistent connection with a MIME Multipart/Mixed response would be
appropriate for "real time" events (like page stacking or device errors).
But (issue 2) if a proxy is behaving such that all the responses (which
are inevitably CHUNKED) are buffered into one concatenated response...
then the notification recipient learns all the information at one time,
anyway, which defeats the purpose.
Our question (which needs to be posed to the HTTP community, perhaps at
the March meeting) is... will proxies actually do this? We find it hard to
imagine a proxy designed to buffer arbitrary lengths of data!
Also, we need an answer to (3). What can we expect in terms of a proxy
allowing persistent connection. Is 4 minutes out of the question (for
example). Does it depend on whether or not responses are flowing?
Harry Lewis
IBM Printing Systems
This archive was generated by hypermail 2b29 : Thu Feb 17 2000 - 19:36:40 EST