IPP Mail Archive: RE: IPP> Notifiaction spec

IPP Mail Archive: RE: IPP> Notifiaction spec

RE: IPP> Notifiaction spec

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jul 21 2000 - 13:38:16 EDT

  • Next message: Norbert Schade: "IPP> port specific printing"


    Here are some replies to your comments, preceded by TH>.


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

    I apologize if a) this is too late or b) if this is the wrong list.
    TH> This is the right list. The spec has changed in the direction of your
    comments during the past year.

    I would like to propose a significant simplification of the notifications
    TH> See below, since your simplification boils down to remove 3 values from
    Job events and 3 other values from Printer events and send only the 10
    REQUIRED pieces of data.

    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
    TH> Section 5.3.3 says "notify-attributes" MAY be supported by the Printer
    and only for Machine Consumable. It is NOT required by [ipp-ntfy] and
    neither 'indp' nor 'mailto' Delivery Method REQUIRES it.

    The subscription objects are variable in size
    TH> Yes, there is some variation depending on whether the event is a Job or
    Printer event (and for Job events whether it is
    'job-completed'/'job-progress' add another item).
    The comparison for Machine Consumable can best by seen in
    'ipp-not-spec-for-IIG-000714-rev.* (in .zip and new_NOT):

    10 always REQUIRED (SNMP has 6 which are supplied by SNMP headers or are

    3 extra for all job events (job-id, job-state, job-state-reasons)
    plus "job-impressions-completed" for 'job-competed' (REQUIRE event) and
    'job-progress' (OPTIONAL event)
    (SNMP has a lot more for the OPTIONAL 'job-progress' event)

    3 extra for all printer events (printer-state, printer-state-reasons, and

    The validation of the subscription request is more complex
    TH> The validation is the same for all Subscription Creation Operations and
    for all Delivery Methods. It was a goal that the validation could be
    independent of the Delivery Method, so that Delivery Methods could be
    plug-in modules.


    The generated messgaes have a varying structure
    TH> True, but we reduced the variability considerably and made it OPTIONAL
    for the Printer to support "notify-attributes" which causes greater
    variability (if supported).

    The size of events varies significatnly (for some notifiaction methods based
    UDP this may be important)
    TH> True, but the SNMP Delivery Method fits with the shortest UPD packets of
    487(?) octets.

    We have to define the behavior of the system in the case where the requested
    attribute(s) dont exist on the printer
    TH> They are returned in the response as Unsupported attributes, like all
    other IPP operations.

    For human readable messages it is not clear what this means exactly
    TH> Section 5.3.3 says that "notify-attributes" is only for Machine
    Consumable, so mailto will ignore it.

    Just thing of the 400 extra test cases that Tom is going to dream up :-)
    TH> I won't, but Quality Logic should.

    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
    TH> You are saying always send the 10 REQUIRED ones, but not the 3 extra
    ones (4 for 'job-progress' and 'job-completed'. Is this really a big enough

    This archive was generated by hypermail 2b29 : Fri Jul 21 2000 - 13:46:37 EDT