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

From: Roger K Debry <[email-masked]>
Date: Mon, 9 Feb 1998 12:47:28 -0500

Ron,

I think this is a good analysis. I agree that since remote users
can't do much about a job, an email notification that the job is
complete is sufficient.  Perhaps to save confusion on the terms
local and remote, we could use the term email-notification-uri,
with the description that this is intended for users who are remote
from the printer, who only need notification that print is complete,
that they do not need this immediately, i.e. they are satisfied to
have the notification handled by email and delivered at whenever
they happen to open their email. Local users could use this
scheme as well if this is the level of notification they wanted.

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/09/98 10:41
AM ---------------------------

[email-masked] on 02/09/98 10:13:19 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc:
Subject: IPP> MOD> A New View of Notification Requirements

A major point missing from the previously posted notification
requirements concerns the location or intent of the user.  I believe
this to be the most important factor to be considered, and should
minimize much of the discussion concerning firewalls.  This analysis
assumes, as in the previously posted requirements, that submission
problems such as transmission errors and acceptance of the job are
handled by the job submission protocol.

REMOTE USER:

 - The remote user is always the submitter of the job.
 - A firewall may or may not exist between the remote user and the
   printer.
 - The document will not be directly retrieved by the remote user.
 - The remote user does not require any notifications other than an
   indication that the job has completed.  The remote user may desire
   additional notifications, but since he is remote from the printer,
   he will be unable to perform any required actions.  For simplicity,
   I propose that we restrict notification to a remote user to job
   completion.
 - The submitter does not require immediate notification of job
   completion.  Again he may desire immediate notification but, since
   he is not the person that will retrieve the job, this should not be
   a high priority.

LOCAL USER:

 - The local user will never encounter a firewall in the path to the
   printer.
 - The local user may or may not be the submitter of the document to be
   printed.  He is always the recipient of the document.
 - The local user should have the option of receiving all possible
   notifications regarding the progress of the job and any problems or
   errors encountered.  Maintenance or support personnel may also
   receive problem and error notifications in addition to or instead
   of the local user.
 - The local user requires prompt notification of job completion and
   possibly problems and error conditions.

Since only the remote user must deal with a firewall and he does not
require any notification other than job completion, the protocol
requirements are greatly simplified.  For the remote user, email
notifications should be a perfect match.  I have not seen any other
methods proposed that everyone agrees are firewall *safe*.

Notification for the local user are open to any reasonable protocol, no
firewall is ever encountered in this case.  The is the area that will
require the most effort to resolve the notification issue.

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.

This is not intended to be a complete notification solution for IPP.  My
only intent is to minimize the discussion regarding firewalls.  (This
discussion (firewalls) appears to be making very little progress.)  There
is still a significant amount of work remaining to complete the IPP
notification effort.

Comments invited!

 Ron Bergman
 Dataproducts Corp.

---

From: Ron Bergman <[email-masked]>
Date: Tue, 10 Feb 1998 08:26:40 -0800 (Pacific Standard Time)

Roger,

Your term "email-notification-uri" certainly is better.  I like the fact
that the same attribute can then be used by both a remote and local user.

	Ron Bergman
	Dataproducts Corp.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 10 Feb 1998 10:26:50 PST

> scheme as well if this is the level of notification they wanted.

I think it's confusing the layering to have an 'email-notification-uri',
since the point of using a uri is to be able to specify a resource and
have the resource identifier include the mechanism by which the resource
is to be contacted (email if 'mailto' and http post if 'http', as examples.)

For interoperability with Internet Fax, using Message Disposition Notifications
as a kind of disposition notification for printing seems perfectly reasonable.

The language and syntax is capable of conveying both a human readable
and machine sensible notification.

I suppose the only problem is trying to find the equivalent of the 'message-id'
within an IPP request.

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: Jay Martin <[email-masked]>
Date: Tue, 10 Feb 1998 17:57:19 -0500

Larry,

> and machine sensible notification.

Sorry, but "Message Disposition Notifications" is a new term to me.
Can you post any pointers to this?  Is this a (separately defined)
communications standard, or part-and-parcel of Internet Fax?

> I suppose the only problem is trying to find the equivalent of the 'message-id'

I would think Harry Lewis' oft-mentioned "Job Submission Id"
would be the logical choice here.  Perhaps Harry can comment.

	...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: Larry Masinter <[email-masked]>
Date: Tue, 10 Feb 1998 18:03:00 PST

draft-ietf-receipt-mdn-08.txt (I think it's 08), 
"An Extensible Message Format for Message Disposition Notifications".

> This memo defines a MIME content-type [5] for message disposition
> notifications (MDNs).  An MDN can be used to notify the sender of a
> message of any of several conditions that may occur after successful
> delivery, such as display of the message contents, printing of the
> message, deletion (without display) of the message, or the
> recipient's refusal to provide MDNs.  The
> "message/disposition-notification" content-type defined herein is
> intended for use within the framework of the "multipart/report"
> content type defined in RFC 1892 [7].

A "print disposition notification" could be returned as a multipart/report
containing a message/disposition-notification
or possibly you could invent a new notification, e.g.,
message/print-notification.

---

From: Jay Martin <[email-masked]>
Date: Wed, 11 Feb 1998 10:19:01 -0500

Thanks for the additional info, Larry.

For the record, here's the URL for the document Larry had cited:

http://ds.internic.net/internet-drafts/draft-ietf-receipt-mdn-08.txt

	...jay