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

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 23 Mar 1998 10:38:27 PST

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: [email-masked]

---

From: Paul Moore <[email-masked]>
Date: Mon, 23 Mar 1998 11:42:56 -0800

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:[email-masked]]
> Sent:	Monday, March 23, 1998 10:38 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	IPP> NOT - Is SNMPv3 suitable for IPP Notifications?
> 
> All,
>

---

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 23 Mar 1998 13:10:02 PST

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

Carl-Uno Manros

---

From: Paul Moore <[email-masked]>
Date: 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).

> Sent:	Monday, March 23, 1998 1:10 PM
> To:	Paul Moore; [email-masked]
> Subject:	RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications?
> 
> Paul,
>