Subject: RE: IPP> MOD> A New View of Notification Requirements

From: "Turner, Randy" <[email-masked]>
Date: Tue, 10 Feb 1998 21:55:11 -0800

These requirements are a perfect example of taking a simple idea like an
email address to notify on job completion, and turning into an
"architecture". Do we really need this complexity? I think just a simple
email address to notify when a job completes would be sufficient to meet
the needs of the majority of people that use this facility. I'm assuming
that job completion notification is in addition to a separate method for
general IPP async notification.

Also, the last requirement about a URI to notify regarding printer
problems is device management, and we (and the rest of the networking
community) already have a solution for device management. I would like
to see IPP remain a job submission, and later, a job management
protocol. I'm hoping I didn't spend the last 3 - 4 years of my life
developing the Printer MIB for no reason...

Randy

	-----Original Message-----
	From:	Jay Martin [SMTP:[email-masked]]
	Sent:	Tuesday, February 10, 1998 3:11 PM
	To:	Ron Bergman
	Cc:	[email-masked]
	Subject:	Re: IPP> MOD> A New View of Notification
Requirements

	Ron,

	> The model document should include the following attributes to
support
	> these requirements.
	> 
	>   1. remote-notification-uri  (Job Template Attribute)  No job
	>       completion notification is returned to the remote user
if this
	>       attribute is not included in the job submission request.
	>
	>   2. local-notification-uri  (Job Template Attribute)  No job
	>       notifications are returned to the local user if this
attribute is
	>       not included in the job submission request.
	>
	>   3. Local-notification-types-requested  (Job Template
Attribute)  An
	>       enum or bit map which defines the types of notifications
	>       requested.  Includes job completion, job progress, job
errors,
	>       printer errors, printer warnings, etc.
	>
	>   4. local-notification-types-default  (Printer Description
Attribute)
	>
	>   5. printer-service-notification-uri  (Printer Description
Attribute)
	>       All printer problems are reported to this URI.

	Can (should?) the URI attributes be multi-valued?

	In particular, I'm thinking the
"printer-service-notification-uri"
	attribute would greatly benefit from having multiple URI
targets,
	so as to support delivery of printer device problems to multiple
	operations personnel.

	Or is the "printer-service-notification-uri" attribute to be
used
	for other reasons?

		...jay

----------------------------------------------------------------------
	--  JK Martin               |  Email:   [email-masked]
--
	--  Underscore, Inc.        |  Voice:   (603) 889-7000
--
	--  41C Sagamore Park Road  |  Fax:     (603) 889-2699
--
	--  Hudson, NH 03051-4915   |  Web:
http://www.underscore.com   --

----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Wed, 11 Feb 1998 11:40:06 -0500

Randy,

> general IPP async notification.

It feels kinda funny to be placed on the "complex" side of the
fence after espousing "simple,simple,simple" for so long...  ;-)

Actually, I didn't view the notion of multiple target URIs as
being complex.  However, if you get the feeling it is, perhaps
you can offer some insights as to why you think it is complex?

Part of the complexity that might arise has to do with notifications
destined for human readability (ie, natural language email msgs),
versus machine-processable notifications for programmatic use.

> developing the Printer MIB for no reason...

Sorry, but I feel compelled to toss in my 2cents worth here...

The Printer MIB came into being because customers were (literally)
clammering for SNMP support in all network devices.  IMHO, most
(if not nearly all) of those customers didn't really know what
they were getting into.  SNMP had become the ultimate network
management buzzword of the early '90s.

Customers (and, to a very large extent, printer vendors) expected
printers to be managed via Network Management System (NMS) platforms,
such as OpenView, Spectrum, Solstice, etc.  The premise was quite
simple:

  "We have invested mucho cash to acquire NMS capabilities, so
   now we want to leverage that investment to monitor/manage
   network printers in the same vein."

What printer vendors didn't realize--and customers didn't admit
unless pushed right up against the wall--is this simple fact:

  The primary roles for NMS platforms is to manage "network
  elements" (routers, hubs, gateways, etc).  Operations personnel
  responsible for managing such network elements indeed use
  the high-powered NMS products to achieve that objective.
  However, those very same personnel almost NEVER are responsible
  for network printer management (and, in fact, really hate
  network printers altogether).

NMS products are very costly (for very good reasons), and as a
result, the personnel actually responsible for managing network
printers could never justify the cost to acquire their own NMS
capabilities just for network printer management.  Suffice to
say, network management personnel really didn't want the network
printer personnel using their tools (and asking them to configure
things for them, etc).

The picture I have just painted can be seen anywhere, at least
within the continental USA.  Interestingly, Chris Wellens admitted
this situation after she personally went out and polled a number
of her NMS friends a while back.  And we see it in virtually
every customer site we step into.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Dan Wing <[email-masked]>
Date: Tue, 24 Feb 1998 18:45:32 -0800

The thread on email-based notification has been interesting, but as
Larry has pointed out, the problems of internationalization have been
solved with DSNs (RFCs 1891-1894, especially 1894) and MDNs
(draft-ietf-receipt-mdn-08.txt).

The purposes of MDNs, from the Internet Draft:

  (a)  Inform human beings of the disposition of messages after
       succcessful delivery, in a manner which is largely independent
       of human language;
 
  (b)  Allow mail user agents to keep track of the disposition of
       messages sent, by associating returned MDNs with earlier
       message transmissions;
 
  (c)  Convey disposition notification requests and disposition
       notifications between Internet Mail and "foreign" mail systems
       via a gateway;
 
  (d)  Allow "foreign" notifications to be tunneled through a MIME-
       capable message system and back into the original messaging
       system that issued the original notification, or even to a
       third messaging system;
 
  (e)  Allow language-independent, yet reasonably precise, indications
       of the disposition of a message to be delivered.

RFC1894 or draft-ietf-receipt-mdn-08.txt would both be reasonable
starting points to create a notification format that is useful for IPP
and follows the requirements of draft-ietf-ipp-not-00.txt.

-Dan Wing

---

From: James Walker <[email-masked]>
Date: Wed, 25 Feb 1998 16:31:36 -0600

Dan Wing wrote:
> ...

I may be a bit dense, but I am having a hard time seeing how MDNs
solve the notification problems that we have been discussing.  If
the answer is simply to use the same idea of a multipart/report
MIME type, where one part is human readable, and the other part is
machine readable, that is fine.  However, if the suggestion is to
use the message/disposition-notification MIME type, it just does
not work for me.

curious...
...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX