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

From: Ron Bergman <[email-masked]>
Date: Mon, 9 Feb 1998 08:39:39 -0800 (Pacific Standard Time)

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 16:22:26 -0800 (Pacific Standard Time)

Jay,

I would agree that several of these attributes could be multi-valued.
Your example for "printer_service-notifcation-uri" is good.  Also, the
"local-notification-uri" could be multi-valued.  For example, if you send
a document to a printer at Dataproducts in Simi Valley, you could include 
my uri as well as a secretary.  If the secretary knows that I am not in the
office today, she will retrieve the document and place it in my mail box.
If I am in, she will just ignore the message.  A corresponding
"local-notification-types-requested" should also be included.

Another approach would be to have an "alternate...notification-uri", but
this would always result in some limitations.  The multi-valued approach
is much cleaner.

As we develop the scenarios, additional attributes may also be determined
to be multi-valued.

Tomorrows phone conference should be interesting.  Unfortunately, I will
not be able to participate.

	Ron Bergman
	Dataproducts Corp.

On Tue, 10 Feb 1998, Jay Martin wrote:

> Ron,
> 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: Tue, 10 Feb 1998 18:10:34 -0500

Ron,

	...jay