IPP Mail Archive: IPP> IPP Native Notifications

IPP Mail Archive: IPP> IPP Native Notifications

IPP> IPP Native Notifications

From: harryl@us.ibm.com
Date: Thu Feb 17 2000 - 19:29:30 EST

  • Next message: Farrell, Lee: "IPP> IPP Minutes -- Feb '00"

    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

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

    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