IPP Mail Archive: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications?

IPP Mail Archive: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications?

RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications?

Paul Moore (paulmo@microsoft.com)
Mon, 23 Mar 1998 13:29:20 -0800

If this is the case

"As far as I am aware, we seem to have agreements on most of the
points in
your message. The area in which there is still debate is for a
delivery
mechanism, that can send out notifications more quickly than with
email."

Then why is there a discussion? I can use anything I like for
notifications. I cannot see why SNMP appears in this discussion. If a system
wants to use SNMP to get events from a device then this is already possible
- it has nothing to do with IPP. What IPP needs is end user focussed stuff
(pagers, email, etc.). Faster than email would be the network native
messenger service (SMB Net Send for example).

> -----Original Message-----
> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com]
> Sent: Monday, March 23, 1998 1:10 PM
> To: Paul Moore; ipp@pwg.org
> Cc: jmp@pwg.org; sense@pwg.org
> Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications?
>
> Paul,
>
> As far as I am aware, we seem to have agreements on most of the points in
> your message. The area in which there is still debate is for a delivery
> mechanism, that can send out notifications more quickly than with email.
>
> There has been some interesting discussion lately in the IFAX group about
> their intended use of MDNs for notifications over email. Those seem to
> indicate that implementation and actual use of MDNs in email is likely to
> be a very slow process...
>
> Carl-Uno
>
>
> At 11:42 AM 3/23/98 PST, Paul Moore wrote:
> >Some time since I aired my views on this.
> >
> >I think we should make IPP notifications a mechanism whereby a client can
> >request that a notification be sent to it via any mechanism.
> >
> >That is to say - the notification itself is sent any way you like and is
> not
> >part of IPP. IPP merely provides the means for the client to request that
> >this be done.
> >
> >We might want to define some standard optional mechanisms (email being
> the
> >obvious one). All notifications are optional.
> >
> >The IPP Model also needs to define what events are notification
> candidates
> >and what they mean.
> >
> >The IPP request indicates which events it wants notification on, what
> >mechanism to use, any parameters associated with that mechanism (email
> >address) and maybe message content.
> >
> >The mechanisms available should be something that is queryable (get
> printer
> >attributes).
> >
> >There is a separate thing that deals with device level alerts and events
> -
> >along with robust data transmission, etc. etc. My thoughts on that topic
> >have already been aired!
> >
> >> -----Original Message-----
> >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com]
> >> Sent: Monday, March 23, 1998 10:38 AM
> >> To: ipp@pwg.org
> >> Cc: jmp@pwg.org; sense@pwg.org
> >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications?
> >>
> >> All,
> >>
> >> We have had a rather intensive debate between Randy, who first
> >> proposed that we might want to use SNMPv3 traps or informs for
> >> IPP notifications, and Ira, who thinks that the whole idea is
> >> wrong.
> >>
> >> With the exception of Jay's comments earlier today, it has been
> >> very quiet from the rest of the group on this subject. Are there
> >> any other views on the subject? Do you support one or the other
> >> combattants' views?
> >>
> >> If all we will be hearing is arguments between mainly two people
> >> with diametrically opposite views, we are not going to archieve
> >> anything.
> >>
> >> We are supposed to discuss this next week in the IETF in LA and
> >> it would be nice to have a little better understanding of where
> >> the group stands in this debate by then. Should we abandon SNMPv3
> >> as a candidate for IPP notifications and concentrate our efforts
> >> on a new or different solution?
> >>
> >> Please give more feedback to the DL.
> >>
> >> Carl-Uno
> >>
> >>
> >> Carl-Uno Manros
> >> Principal Engineer - Advanced Printing Standards - Xerox Corporation
> >> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> >> Phone +1-310-333 8273, Fax +1-310-333 5514
> >> Email: manros@cp10.es.xerox.com
> >
> >
> Carl-Uno Manros
> Principal Engineer - Advanced Printing Standards - Xerox Corporation
> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> Phone +1-310-333 8273, Fax +1-310-333 5514
> Email: manros@cp10.es.xerox.com