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: pmoore@peerless.com
Date: Fri Jul 21 2000 - 11:29:44 EDT

  • Next message: Hugo Parra: "RE: IPP> ADM - Examples"

    I dont think we will have many to bake off anyway given then complexity of what
    we have ended up with.

    Maybe I am being naive but it doesnt seem to hard to come up with a set of event
    paramters for all events

    printer events:-

    name,date time, printer state, printer state reason

    Job events:-

    jobid, job state, job state reason, current page number

    I dontunderstand how making the paranter set variable helps UDP messages - I
    would have though it made it worse. The client can request a huge number of
    attributes that will overflow the packet. With fixed format events at least the
    is a good chance of fitting them into one message.

    "McDonald, Ira" <imcdonald@sharplabs.com> on 07/21/2000 08:14:12 AM

    To: "'pmoore@peerless.com'" <pmoore@peerless.com>, ipp@pwg.org
    cc: (bcc: Paul Moore/AUCO/US)

    Subject: RE: IPP> Notifiaction spec [fixed contents]

    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:40:09 EDT