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: rdebry@us.ibm.com
phone: 1-303-924-4080
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/09/=
98 10:41
AM ---------------------------
ipp-owner@pwg.org on 02/09/98 10:13:19 AM
Please respond to ipp-owner@pwg.org @ internet
To: ipp@pwg.org @ 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. M=
y
only intent is to minimize the discussion regarding firewalls. (This
discussion (firewalls) appears to be making very little progress.) The=
re
is still a significant amount of work remaining to complete the IPP
notification effort.
Comments invited!
Ron Bergman
Dataproducts Corp.
=