IPP Mail Archive: RE: IPP> Comments on snmpnotify version 2

IPP Mail Archive: RE: IPP> Comments on snmpnotify version 2

RE: IPP> Comments on snmpnotify version 2

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Apr 12 2000 - 13:01:56 EDT

  • Next message: Hastings, Tom N: "RE: IPP> ADM - Telecon this Wednesday ??? [No, next Wednesday]"

    Hi Ron,

    Should we take this spec out of the context of the
    IPP WG entirely and work it as a separate (related)
    issue in JMP?

    I agree with you about jmJobState and xxxProcessed.
    Obviously, it's much more compact to sent the
    values for jmGeneralJobSetIndex and jmJobIndex as
    part of the instance qualifier of jmJobState -
    I got carried away.

    Also, as I mentioned to Dennis Carney in a recent
    note on Tuesday (4 April), two other attributes in
    the Job table (xxxPerCopyRequested) should also be
    directly referenced (not recreated in Event Bindings

    And by including all of the bindings from the
    IPP Notifications spec for each of the four different
    varieties of traps (device, job-state, job-completed,
    and job-progress) we get (to my mind) traps which
    are OBVIOUSLY not consistent with the SNMP philosophy
    of lightweight trap bindings.

    In particular, I'm thinking that we should remove from
    the mandatory bindings all the 'jmEventSubscriber...'
    objects - they're too IPP specific and useless in other
    contexts (every other job submission protocol in

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

    -----Original Message-----
    From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
    Sent: Tuesday, April 11, 2000 6:50 PM
    To: Ira McDonald
    Cc: ipp@pwg.org
    Subject: IPP> Comments on snmpnotify version 2


    Sorry for sending these comments so late, but I was unable
    to read the document prior to the Tokyo meeting.

    I believe that we have now gone to far in creating new
    objects for use in the traps. Is there a reason why we
    cannot use...

        jmJobState instead of jmEventJobState
        jmJobKOctetsProcessed instead of
        jmJobImpressionsCompleted instead of

    Use of these three existing objects also allows the
    Job Index and Job Set Index to be derived from the OIDs
    and they do not have to be separate varbind entries.
    This provides some addition space for other entries.

    You probably heard that there was an extreme lack of
    support for this method in the Tokyo meeting. As I
    look at the complexity of this approach vs the traps
    that I have currently implemented, I am begining to
    also wonder why all this is needed. In trying to do a
    complete match to the IPP Notifications specification
    we have created a very complex trap definition. Is
    all this really needed or are we trying to include
    everything just in case?

    I am still willing to provide some support for this
    method but I am not likely to implement this unless
    there is wide support by management applications.

        Ron Bergman
        Hitachi Koki Imaging Solutions

    This archive was generated by hypermail 2b29 : Wed Apr 12 2000 - 13:12:25 EDT