IPP Mail Archive: IPP> NOT - "The 'ipp' Notification Po

IPP Mail Archive: IPP> NOT - "The 'ipp' Notification Po

IPP> NOT - "The 'ipp' Notification Polling Method" is down loaded (inc luding I-D .txt file)

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Mar 09 2000 - 05:14:07 EST

  • Next message: Ron Bergman: "IPP> Re: Comments on the SNMP Notifications Document"

    I've down loaded the files for the "Internet Printing Protocol (IPP): The
    'ipp' Notification Polling Method", including the first I-D .txt file which
    Carl-Uno will send to the IETF.

    It is only 14 page long, so please read it. It is the most likely event
    notification delivery method candidate to be the REQUIRED method for IPP
    Notification. Therefore, it needs careful review by everyone (and


    Here is the Abstract:

    The IPP notification specification [ipp-ntfy] is an OPTIONAL extension to
    IPP/1.0 and IPP/1.1 that requires the definition of one or more delivery
    methods for dispatching Event Notification reports to Notification
    Recipients. This document describes the semantics and syntax of the 'ipp'
    event Notification delivery method. For this delivery method, the client
    uses an explicit IPP Get-Notifications Printer operation in order to request
    (pull) Event Notifications from the IPP Printer.
    When a Printer supports the 'ipp' delivery method, it holds each Event
    Notification for a certain length of time. The amount of time is called the
    "event-lease time".. A Printer may assign the same event-lease time to each
    Event Notification or different times. If a Notification Recipient does not
    want to miss Event Notifications, the time between consecutive pollings of
    Subscription objects must be less than the event-lease time of the events
    that occur between pollings. The Get-Notifications request indicates
    whether the client wants to receive all pending event Notifications for (1)
    any Subscription for which the client is the owner, (2) any Subscription
    associated with a Job, (3) any Subscription with a particular
    delivery-method URL, or (4) an identified set of Subscription objects. With
    the Get-Notifications operation, the Printer returns all existing Event
    Notifications along with two time intervals. One specifies the minimum time
    at which event-leases of future events of the type returned will begin to
    expire and the other specifies the recommended interval for the client to
    wait before sending the next Get-Notifications operation. The second time
    interval is less than the first.
    The Printer may keep the channel open if the recommended interval is
    sufficiently short, but in any case the client performs a new
    Get-Notifications operation each time it wants more Event Notifications.
    Since the time interval between consecutive client requests is normally less
    than the event-lease time, consecutive responses will normally contain some
    Event Notifications that are identical. The youngest ones in the previous
    response will become the oldest in the next response. The client is
    expected to filter out these duplicates, which is easy to do because of the
    sequence number in each Event Notification.

    There are 6 issues:

    ISSUE 1: The 'ipp' is a convenient reuse of 'ipp', but does it imply the
    existence of a print service at each client that is not a reality?

    Issue 2: Now that the Get-Notification operation does not affect the Event
    Notifications in the Printer, it should not require write access to access

    Issue 3: Is it possible for this operation to have an option that causes it
    to delay completing its response? It would initially returns all existing
    Event Notifications. Then it would return additional notifications as they
    occur for some period of time. The client would receive these Event
    Notifications as they occur. The question is whether http servers or
    proxies would behave in this manner so that the client would get the Event
    Notifications without delay after they are sent by the http server? It has
    been suggested that the Printer send each burst of Event Notifications be in
    a separate message body where each message body is part of a multipart MIME

    ISSUE 4: The "notification-recipient" option allows a client to group
    multiple Subscription-ids with a single URL. A client might decide to use
    the same URL for all subscriptions for a user, or it might have a separate
    URL for each client program. In addition a client might use an URL
    belonging to some other known user and let that user access Event
    Notifications using that URL. Is the above option useful?

    ISSUE 5: Does the mechanism described in the above paragraph describe a
    useful option that "notification-recipient" alone cannot do? Should this
    case be an error instead?

    ISSUE 6: Is it better if "notification-recipient" is the only way to request
    Event Notification? If so, this behaves more like other notification
    delivery methods where a recipient receives those and only those events with
    its delivery URL. Furthermore, if there is a single mechanism of
    "notification-recipient" for a client to specify Event Notifications, a
    Printer can better optimize event-leases because it knows which events will
    be accessed together. If client can specify subscription-ids, each request
    can contain a different mix of subscription-ids.

    Please send comments to the mailing list. We're going to forward ISSUE 03
    to the HTTP WG mailing list now and hope to engages them in Australia.

    Tom and Bob

    P.S. the .doc file has been updated some with some editorial fixes since Bob
    posted it below:

    -----Original Message-----
    From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.com]
    Sent: Wednesday, March 08, 2000 23:33
    To: ipp@pwg.org
    Subject: IPP>NOT latest notify poll document

    The latest document has updates based on feedback at the Wednesday
    teleconference. It also has 6 issues, some new.

    The URL is


    Bob Herriot

    This archive was generated by hypermail 2b29 : Thu Mar 09 2000 - 05:20:15 EST