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