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: Ron Bergman (rbergma@hitachi-hkis.com)
Date: Wed Apr 12 2000 - 14:37:55 EDT

  • Next message: McDonald, Ira: "RE: IPP> Comments on snmpnotify version 2"

    Ira,

    See my comments below.

        Ron

    "McDonald, Ira" wrote:

    > 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?

    ron> I don't see any advantage to removing this from the
         IPP effort. We only need to add a justification if
         we decided not to support the full IPP requirements.
         I beleive that it is best to keep this within IPP.

    >
    >
    > 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
    > group).
    >
    > 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.
    >

    ron> This is the basis of my concern! If we can get back
         to a "reasonable weight" trap I would feel much better.

    >
    > 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
    > existence).
    >

    ron> Good! These two objects are strings, which could be
         very long. I will review the remainder and try to
         generate a list of any additional ones that could
         be candidates for removal.

    >
    > Cheers,
    > - 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
    >
    > Ira,
    >
    > 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
    > jmEventJobKOctetsProcessed
    > jmJobImpressionsCompleted instead of
    > jmEventJobImpressionsCompleted
    >
    > 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 - 14:32:45 EDT