IPP> Comments on snmpnotify version 2

IPP> Comments on snmpnotify version 2

IPP> Comments on snmpnotify version 2

Ron Bergman rbergma at hitachi-hkis.com
Wed Apr 12 14:37:55 EDT 2000


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 at hitachi-hkis.com]
> Sent: Tuesday, April 11, 2000 6:50 PM
> To: Ira  McDonald
> Cc: ipp at 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




More information about the Ipp mailing list