IPP Mail Archive: IPP> NOT - Simple IPP Notifications / Subs

IPP> NOT - Simple IPP Notifications / Subscriptions - no collections

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Apr 19 2000 - 19:10:02 EDT

  • Next message: Carl-Uno Manros: "RE: IPP> IPP over other transports"

    Hi folks,

    This is an informal summary of part of the discussion at the IPP Telecon
    earlier today (19 April 2000), with the following people attending:

    - Carl-Uno Manros (Xerox, chair IETF IPP WG)
    - Tom Hastings (Xerox, editor IPP Model)
    - Bob Herriot (Xerox, editor IPP Protocol)
    - Mike Shepherd (Xerox)
    - Harry Lewis (IBM)
    - Ron Bergman (Hitachi)
    - Ira McDonald (High North)

    Discussion of my recent proposed simplified SNMP traps for job monitoring
    led to the following tentative conclusions:

    1) Reduce the number of REQUIRED attributes for all IPP Notifications to
        a much smaller list (ACTION - Tom H, Bob H, and Ira McD to propose)

    2) Remove all discussion of all OPTIONAL attributes for IPP Notifications
        and replace with Subscription object and Create-xxx-Subscription
        operation attribute 'requested-attributes' (which may specify any
        Printer, Job, or Subscription object attribute accessible via
        Get-xxx-Attributes operations).

    3) Remove use of 'collection' syntax for Print-Job/Create-Job and
        Create-xxx-Subscription operations for notification info and
        replace with the simple flat attributes that actually go into
        the Subscription object.

    4) If an IPP Client wants to have more than one subscription for
        a given job, then that IPP Client MUST use Create-Job, followed
        by one or more Create-Job-Subscription operations, followed by
        one or more Send-Document or Send-URI operations - no race
        condition is introduced (like Print-Job) and no dummy Hold-Job
        and Release-Job operations are required.

    5) CONTROVERSIAL - Move 'collection' syntax into production printing
        spec where it offers significant utility - Tom Hastings and Bob
        Herriot would rather keep 'collection' on the IETF 'standards
        track', even if there are no attribute applications immediately -
        the IETF will NOT accept a protocol option which is not implemented
        and will NOT accept a protocol option which has no current usage.

    The intent of these simplifications is to foster widespread implementation
    of IPP Notifications and to improve interoperability. The intent is NOT to
    abandon 'collection' syntax - just to use it where we get the most bang
    for the buck - and to decouple the progress of the IPP Notifications spec
    from the finalization of (and acceptance by IETF of) 'collection'.

    Comments?

    Cheers,
    - Ira McDonald, consulting architect at Xerox and Sharp
      High North Inc



    This archive was generated by hypermail 2b29 : Wed Apr 19 2000 - 19:16:54 EDT