IPP Mail Archive: RE: IPP> Notifiaction spec [fixed contents]

IPP Mail Archive: RE: IPP> Notifiaction spec [fixed contents]

RE: IPP> Notifiaction spec [fixed contents]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Fri Jul 21 2000 - 11:14:12 EDT

  • Next message: pmoore@peerless.com: "Re: IPP> notification methods"

    Hi Paul,

    A fixed set of notification contents is what we DID have
    until recently - the set grew larger and larger by the
    usual committee process - it became impossible to send
    machine-readable conformant notifications in many existing
    notification protocols (eg, SNMP) which typically operate
    over connectionless transports.

    So we threw OUT all the fixed bindings and let the client
    request attributes. The IPP Printer always explicitly
    advertises which attributes may be requested in the
    notifications, so there is no ambiguity.

    If we go back to fixed notification content, we'll take
    another six months to agree on the list (if ever...) and
    we won't have ANY notification delivery methods to test
    at the IPP/1.1 Bakeoff in October 2000. That would be bad!

    - Ira

    -----Original Message-----
    From: pmoore@peerless.com [mailto:pmoore@peerless.com]
    Sent: Thursday, July 20, 2000 9:01 AM
    To: ipp@pwg.org
    Subject: IPP> Notifiaction spec

    I apologize if a) this is too late or b) if this is the wrong list.

    I would like to propose a significant simplification of the notifications

    In the current spec it is possible for the subscriber to say what info they
    in the notification. The adds many layers of complexity that are I beleive
    The subscription objects are variable in size
    The validation of the subscription request is more complex
    The generated messgaes have a varying structure
    The size of events varies significatnly (for some notifiaction methods based
    UDP this may be important)
    We have to define the behavior of the system in the case where the requested
    attribute(s) dont exist on the printer
    For human readable messages it is not clear what this means exactly

    Just thing of the 400 extra test cases that Tom is going to dream up :-)

    My proposal is to simplify by defining the attributes (a minimal set) that
    event always sends. In many cases I expect this to me nothing extra beyond
    set that are always required (printer name , subscription id, job id, etc.)
    the client wants more it can query

    This archive was generated by hypermail 2b29 : Fri Jul 21 2000 - 11:22:35 EDT