1. Notifying the sender of the job whether or not the job is printed
and if so when.
2. Notifying the intended receiver of the job that he has a new job at
the printer.
3. Notifying MIS when and if problems occur printing the job.
I would suggest that IPP not concern itself with case 3. I think this
is best left to the implementer of the IPP print server to define for
their own environment.
As suggested in the previous messages, case 1 is probably best done via
email. However, I think IPP should provide the flexibility for other
mechanisms. Perhaps sender notification can be a job attribute which
includes notification method and address as part of the job.
Notification methods might include:
1. Human readable email which is sent directly to the person who sent
the job. In this case, the address would be the sender's email address.
The message would be sent in English.
2. Machine readable email which is sent to a mailbox accessible by
software on the sender's PC. The address would be a special email
address which the PC software could check periodically in the
background. When the software finds a notification message, it pops up
a Window saying so. The advantage in this method is that the software
on the local PC can provide the notification in the sender's native
language. This is difficult to do on the IPP server. However, the
sender's PC is (obviously) already setup with the correct character sets
and should have a localized version of the IPP software. The method
also allows the IPP software to give faster notification since it can
continuously poll the mailbox in the background rather than waiting for
the user to check his email.
3. Some other notification method to be developed later.
I haven't read any email on the IPP mailing list about case 2 yet.
Maybe no one is planning to support receiver notification, or maybe no
one has thought of it yet. I think it is important. If I send a print
job to Sam in Portland, I would like Sam to be told when the job is
printed and what printer it's on.
Receiver notification may be difficult. First of all, the receiver
should notified quickly when his job is printed. Some people may
consider email too slow for this. Secondly, the receive may not be
using IP protocol, or may not be networked at all (as unlikely as this
may be). I think IPP should start by supporting email notification of
the job receipient using the methods I described above for the sender.
________________________________________________________________________
________________________________
Charles Gordon
Osicom Technologies, Inc.
cgordon@osicom.com
http://www.digprod.com
> -----Original Message-----
> From: Ron Bergman [SMTP:rbergma@dpc.com]
> Sent: Monday, February 09, 1998 11:40 AM
> To: ipp@pwg.org
> 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.
>