IPP Mail Archive: RE: IPP> NOT - IPPGET Issue 11: idea to al

IPP Mail Archive: RE: IPP> NOT - IPPGET Issue 11: idea to al

RE: IPP> NOT - IPPGET Issue 11: idea to allow Printer to increase server-directed polling time (on a Subscription object basis)

From: Bergman, Ron (Ron.Bergman@Hitachi-hkis.com)
Date: Mon Aug 13 2001 - 19:07:07 EDT

  • Next message: Marty Joel: "IPP> ippget and Lost Events"


    It seems that this is too complex to be very useful. I would prefer to keep
    it simple and just use the Event Life time. A better solution to reduce
    traffic is to make the Event Life time be longer.

    I will not be able to attend to conference call tomorrow.


    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Sunday, August 12, 2001 11:35 PM
    To: ipp (E-mail)
    Subject: RE: IPP> NOT - IPPGET Issue 11: idea to allow Printer to
    increase server-directed polling time (on a Subscription object basis)

    My original proposal sent Friday, has the problem that once the Printer had
    increased the Subscription Object's "notify-event-life" value, it couldn't
    reduce it, since some client might be still using the older larger value and
    not perform a Get-Notifications soon enough before an Event's (new lower)
    life expired. However, this problem can be fixed by introducing two new
    Subscription Object Description attributes, instead of just one:

    Subscription Object attribute as before:

      "notify-event-life" - the event life for Events associated with this
    Subscription Object - the Printer can increase its value from the Printer's
    "notify-event-life" value, but can never reduce it (because the Printer has
    no concept of which clients are "listening" to a particular Subscription
    Object's events.

    New Subscription Object attribute:

      "notify-get-interval" - the current interval in seconds between successive
    events that clients should use. It can never be lower than the Printer's
    "notify-event-life" which is the minimum for all Subscription Objects, but
    can be lower than its Subscription Object's "notify-event-life", which the
    Printer MAY have increased due to the expectation that events are unlikely
    to happen any sooner than that. Thus the Printer can raise both the
    Subscription Object's "notify-event-life" and "notify-get-interval", but
    then subsequently lower the latter, as events start to happen again.

    For example, a Subscription Object's "notify-events" have 'job-completed'
    and 'job-progress' events, but the job is submitted when there was a long
    job queue, say a 10 minute queue (600 second) queue. Suppose that the
    administrator has configured the Printer's "notify-event-life" to the
    recommended 60 seconds. The Printer would return the Subscription Object's
    "notify-event-life" and "notify-get-interval" as 600 in the Job Creation
    operation, instead of just 60. Then when the job starts processing, (which
    could be before or after 10 minutes), the Printer reduces the Subscription
    Object's "notify-get-interval" down to, say, the minimum of 15 seconds,
    since page completion events are wanted.

    However, the Printer still has to keep the events around for the 600
    seconds, since, some hapless client might have just polled the Subscription
    Object moments before the Job started processing and got the Subscription
    Object's "notify-get-interval" value of 600, and so won't know to poll back
    any time sooner. However, the client that sent the job would poll back
    around the time that the job started processing and would get the page
    completes as they occur.

    Probably, a Printer that increases the Subscription Object's
    "notify-get-interval" wouldn't increase it to the full amount when the Job
    is likely to start, but would increase it to, say, 60%, and reduce it
    further has the time arrives for the job to start, down to the minimum of

    A Printer that didn't want to bother with any of this complication, would
    simply copy the Printer's configured "notify-event-life" to the Subscription
    Object's "notify-event-life" and "notify-get-interval" and leave them


    So here is the complete updated proposal:

    1. Rename the Printer's "ippget-event-life" (integer(15:MAX)) to
    "notify-event-life" to be parallel (and possibly used in the future with
    some other Delivery Method).

    2. Add "notify-event-life" (integer(15:MAX)) and "notify-get-interval"
    (integer(15:MAX)) Subscription Description attributes to the Subscription
    Object for use with IPPGET Delivery method (and possibly used in the future
    with some other Delivery Method).

    3. Make these Printer Description attribute and Subscription Description
    attributes REQUIRED for a Printer to support, if it support the 'ippget'
    Delivery Method.

    4. By default, the Printer MUST set both of the Subscription Object's
    "notify-event-life" and "notify-get-interval" Subscription Description
    attributes from the configured value of the Printer's "notify-event-life"
    attribute. However, at any time the Printer MAY set the
    Subscription object's "notify-event-life" and "notify-get-interval"
    Subscription Description to a higher value, if it suspects
    that the events that the Subscription object are waiting for are unlikely to
    happen soon. Once set to a higher value, the Printer can further increase,
    but can never reduce, the Subscription Object's "notify-event-life"
    attribute, but can lower the Subscription Object's "notify-get-interval"
    attribute as the Event liklihood of occurring comes closer.

    5. The Printer MUST return Event Notifications until the Subscription
    object's "notify-event-life" expires for each Event. So if the Printer has
    increased the Subscription object's "notify-event-life", then the Printer is
    promising to return Event Notifications for Events for that Subscription
    object for that longer life time (and can never reduce the promise, since
    some client may be counting the Events not to expire for that time period).

    6. As suggested by Marty, instead of returning the "notify-event-life" as an
    operation attribute, return an "event-wait" (boolean) Operation attribute to
    the Get-Notification (and Job Creation) Response, which indicates whether or
    not the Printer is continuing Event Wait Mode. This would mirror the
    "event-wait" (boolean) Operation attribute that the client supplies in the
    Get-Notifications (and Job Creation) request. If the client supplies
    'false' (or omits), the Printer MUST respond with 'false'. If
    the client supplies 'true', the Printer MUST respond with 'true' or 'false',
    depending on whether it is continuing Event Wait Mode or not, respectively.

    7. For Get-Notifications response, whether or not the Printer is continuing
    Event Wait Mode, the Printer always returns each Subscription object's
    current "notify-event-life" and "notify-get-interval" Subscription
    Description attribute values in each Event Notification Attributes Group.
    The client then tries the Get-Notifications for the shortest value returned
    for the "notify-get-interval" attribute and can regroup future
    Get-Notifications requests, if the values returned are different for
    different Subscription Objects in the same response.

    8. For Job Creation responses, the Subscription Attribute Group(s) are
    returned, so the Printer includes the Subscription object's current
    "notify-event-life" and "notify-get-interval" Subscription Description
    attributes in each group.


    Here is the ISSUE 11 and notes from the telecon:

    ISSUE 11: Should the Printer return a "end-wait" (boolean) attribute,
    rather than a "notify-get-interval" (integer) with the number of seconds to
    try again later?

    <MJ> Regarding the whole try-again time issue, I don't think the Receiver
         should be sending that, and should indicate the desire to stop or not
         start wait mode with a boolean or a status code. The Sender can do a
         Get-Printer-Attributes to learn how long events are retained. The
         Sender knows by when it must issue another Get-Notifications to avoid
         the risk of losing events. If it isn't in keep-alive mode, the Sender
         must take into account how long it might take to connect, so the
         returning of the number of seconds to wait before trying again is

    <TH> Or we could clarify the "notify-get-interval" attribute that the
    Printer is returning to be the value of the Printer's
    "ippget-event-life" Printer Description attribute and the client needs to
    take into the account the time to make the connection.

    AGREED> That the "notify-get-interval" operation attribute returned in the
    response MUST be at least as long as the value of the "ippget-event-life"
    Printer Description attribute.

    NOT AGREED> However, if the value is greater than the Printer's
    "ippget-event-life" value, then a Notification Recipient could miss an event
    if it didn't poll at the "ippget-event-life" rate. What to do?

    We are still debating whether it is possible for the Printer to return a
    time to next poll that is ever larger than the Event Life time? If the
    Printer ever returns a larger value, the client could miss an event, unless
    the Printer magically increases its Life for that (those) Subscription

    So is returning a boolean the best the Printer can ever do?

    This archive was generated by hypermail 2b29 : Mon Aug 13 2001 - 19:01:34 EDT