IPP Mail Archive: IPP> NOT - 6 Notification ISSUES: Telecon

IPP Mail Archive: IPP> NOT - 6 Notification ISSUES: Telecon

IPP> NOT - 6 Notification ISSUES: Telecon Wed 7/18, 10-11 PDT (1-2 EDT )

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Jul 17 2001 - 16:31:19 EDT

  • Next message: Manros, Carl-Uno B: "RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs [polling any kind of URL]"

    There have been 6 issues (some changes and some clarifications) of the IPP
    Notification Specification and the three Delivery Methods (ippget, indp, and
    mailto). Some of these issues have come up as folks implement IPP FAX which
    REQUIRES the ippget Delivery Method. We are close to consensus on the
    mailing list and my calling those who have sent email. However, I want to
    make sure and each time I talk to someone they bring up some more good
    points. So I'd like to have a quick telecon tomorrow to make sure we agree.
    I'll send out the specific text changes later today for the following 6

    Time: Wednesday, 7/18/01, 10-11 PDT (1-2 EDT)
    Phone: 1(712)884-1555 (Xerox folks: 8*596-5170
    Passcode: 654970

    If you can't make the telecon, please send email. We don't want to impact
    any implementations underway, unless you participate. I want to update
    these specifications before the next Internet-Draft deadline which is this

    The summary of the 6 issues are:

    1. Clarify that the Printer MAY send Event Notifications in any order.

    2. IPPGET spec: Get-Notification matching "notify-recipients-uri" with
    Subscription objects: octet-by-octet versus URI matching rules. (IPPGET
    currently says both).

    3. IPPGET spec: In a Get-Notifications response when the client has
    requested the wait mode (persistent operation), allow a Printer to return
    the unexpired Notification Events, but also indicate to the client to please
    disconnect and try again at the indicate interval
    ("suggested-ask-again-time-interval"). (IPPGET currently only allows the
    interval to be returned if the client didn't ask for wait mode or if the
    Printer is too busy to return any Notification Events).

    4a. IPPGET spec: Clarify that the Get-Notifications operation is for
    querying any kind of unexpired Events, not just ippget Events. Thus the
    "notify-recipients-uri" operation attribute can match any Subscription
    object including the scheme. Also all Events have a life time, not just
    ippget Events, if the Printer supports Get-Notifications (which requires
    ippget scheme at least).

    4b. Same as 4a, but make it OPTIONAL for a Printer to support other schemes
    with Get-Notifications.

    5. Change the sense of the Get-Notifications "notify-no-wait" (boolean)
    operation attribute to a positive "persistent-operation" (boolean), so that
    omitted and 'false' mean the easier non-persistent operation.

    6. IPPGET spec: Rename some attributes but keep the same semantics:
                    "notify-ippget-redirect" (uri) to "notify-redirect-uri"
                    "suggested-ask-again-time-interval" (integer(0:MAX)) to
    "notify-get-interval", and
                    "begin-to-expire-time-internal" (integer(0:MAX)) to
    "event-life-time" (integer(0:MAX)).

    This archive was generated by hypermail 2b29 : Tue Jul 17 2001 - 16:33:15 EDT