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

From: Harry Lewis <[email-masked]>
Date: Mon, 9 Feb 1998 17:02:10 -0500

Ron, I agree with your qualifications of the notification
requirements. I'm not sure I understand  this one, however:

> The local user may or may not be the submitter of the document
> to be printed.  He is always the recipient of the document.

Can you please elaborate? Unless (and perhaps even if) the submitter
is capable of directing notification to a specific recipient, as suggested
by Charles Gordon in another thread (Three Types of Notification).

>2.  Notifying the intended receiver of the job that he has a new job at
>the printer.

I would always think of the submitter as wanting notification.

Harry Lewis - IBM Printing Systems

[email-masked] on 02/09/98 10:12:51 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:44:09 -0800 (Pacific Standard Time)

Harry,

In my analysis, the submitter would always have the ability to request a
notification of job completion.  He also could elect to not receive
notification.  

The local user is always the recipient of the printed document and also
should always receive notification of, at least, job completion.

(After thinking about your question and my response, did you interpret "He
is always the recipient of the document." to mean "...the notification."?)

	Ron Bergman
	Dataproducts Corp.