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: 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