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.
On Mon, 9 Feb 1998, Roger K Debry wrote:
> 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: 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. 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.
>
>
>
>
>
>