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 - 14:36:42 EDT

  • Next message: Hastings, Tom N: "IPP> ADM - Issue Resolutions from IPP WG meeting on 13 IPP documents"

    Hi Ron,

    Right - we agree that as many as possible of the IPP
    Notifications attributes should be DELETED from the
    OBJECTS clause (mandatory bindings) and (possibly)
    referenced with SHOULD (recommendation) or MAY (option)
    in the DESCRIPTION clause of each of the four traps.

    SNMP-capable clients can always do an SNMP Get on the
    appropriate additional job objects or job attributes
    when they receive the trap. The IPP Notifications
    are too heavyweight for many event protocols.

    Email, instant messaging, and other alternate bindings
    are going to run afoul of the large number of IPP
    Notifications requirements - we have a real opportunity
    to have wide incoherence among the various IPP event
    delivery methods - this is not good!

    - Ira

    -----Original Message-----
    From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
    Sent: Wednesday, April 12, 2000 11:38 AM
    To: McDonald, Ira
    Cc: 'harryl@us.ibm.com'; 'dcarney@us.ibm.com'; ipp@pwg.org
    Subject: Re: IPP> Comments on snmpnotify version 2


    See my comments below.


    "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:43:38 EDT