IPP Mail Archive: RE: IPP> machine readable etc. - why Harry

IPP Mail Archive: RE: IPP> machine readable etc. - why Harry

RE: IPP> machine readable etc. - why Harry is right

From: Harry Lewis/Boulder/IBM (harryl@us.ibm.com)
Date: Tue Aug 22 2000 - 18:22:03 EDT

  • Next message: chris@collegewafer.com: "IPP> Si, Ultra-Thin Si (MEMS), GaAs, InP, GaN, PtSi, SOI, Equipment & More..."

    I was actually shooting for something simpler in the original proposal
    (... why Harry must be insane?)... characterized by

    1. Subscription by default (by virtue of job submission)
    2. Server "directed" (when and/or where) polling (optimization)
       - In the scenario, below, the client polls "immediately". What if there
    is a large queue in front of the job?
       - Server "directed" polling provides the opportunity for indirection
    which could branch the notification process off to an INDP or other
    notification service.
       - This form of polling was intended to minimize the duration of the
    "dribbling" of backchannel information to, exactly, the duration of a
    print job (which didn't seem too "unnatural").
    3. Fixed content (simple subset to represent job progress, completion and
    associated device "distress").

    Nonetheless, I think ippgetw may represent a viable convergence of INDP
    and the quest for leveraging native (to IPP) infrastructure which was one
    of our key goals. Simply stated, if IPP makes it through the firewall,
    (native) notifications will make it through the firewall.
     
    Harry Lewis
    IBM Printing Systems

    "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>
    08/22/2000 02:39 PM

     
            To: pmoore@peerless.com, "McDonald, Ira" <imcdonald@sharplabs.com>
            cc: Harry Lewis/Boulder/IBM@IBMUS, bwagner@digprod.com, ipp@pwg.org, "Herriot,
    Robert" <Robert.Herriot@pahv.xerox.com>, Carl Kugler/Boulder/IBM@IBMUS
            Subject: RE: IPP> machine readable etc. - why Harry is right

    There is a simple extension to "ippget" that does what Harry wants. I'll
    call the solution "ippgetw" for "ipp get and wait"

    1. The user subscribes for this Delivery Method in the same way as for
    "ippget" but instead uses the "ippgetw" scheme in the
    "notify-recipient-uri".

    2. The Subscription tells the Printer what Events the listener is
    interested
    in.

    3. The client obtains the Event Notifications by performing the
    Get-Notifications operation with the same URL as in the
    "notify-recipient-uri". This is just like "ippget" except that Event
    Notifications keep coming in the response.

    4. The Printer performs the Get-Notifications operation as follows
        a) it finds all Subscriptions associated with the specified
           "notify-recipient-uri" (like "ippget").
        b) it returns all Event Notifications that it is holding for the
           specified Subscription objects (like "ippget"). This means that
           the client doesn't miss any events between the time of Subscription
           and the Get-Notifications operation. This step could be omitted
           if it is OK to lose Event Notifications when the client is not
           performing the Get-Notifications operation.
        c) it returns Event Notifications as they occur (unlike "ipp-get").

    5. The Get-Notifications operation terminates in the following ways:
        a) the client closes the connection. The Printer continues to save
           Event Notifications as specified in step 4b) until all
    Subscriptions
           associated with the "notify-recipient-uri" are canceled.
        b) the Printer closes the connection when there are no longer any
           Subscription Objects for the specified URL (in
           "notify-recipient-uri"), e.g. when a Job completes and associated
           Subscription Objects are removed.
        c) a time-out or failure occurs. The actions are the same as step 5a.

    Note: unlike "ippget", the Printer doesn't need to return
    "suggested-ask-again-time-interval" or "begin-to-expire-time-interval"
    because the client performs the Get-Notification operation as soon as
    possible. But according to step b), the Printer does keep Event
    Notifications for a short period of time, at least when there is no
    connection open. The Printer need not keep Event Notifications after it
    sends them if there is no requirement for two clients to use the same
    value
    of "notify-recipient-uri" and no requirement for a client to get lost
    Event
    Notification by reopening the connection.



    This archive was generated by hypermail 2b29 : Tue Aug 22 2000 - 18:31:03 EDT