INTERNET DRAFT Roger K deBry Utah Valley State College Harry Lewis IBM Corporation Tom Hastings Xerox Corporation June 24, 1999 Internet Printing Protocol/1.1: Requirements for IPP Notifications Copyright (C) The Internet Society (1999). All Rights Reserved. STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ''work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed as http://www.ietf.org/shadow.html. ABSTRACT This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol and an interface to Directory Services. This document provides a statement of the requirements for notifications as part of an IPP Service. Some ISSUES are indicated in the text. deBry, Lewis, Hastings Expires December 24, 1999 [Page 1] INTERNET DRAFT IPP/1.1: Notification Requirements June 23, 1999 The full set of IPP documents include: Design Goals for an Internet Printing Protocol [RFC2567] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568] Internet Printing Protocol/1.0: Model and Semantics [RFC2566] Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569] The 'Design Goals for an Internet Printing Protocol' document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. The 'Rationale for the Structure and Model and Protocol for the Internet Printing Protocol' document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. The 'Internet Printing Protocol/1.0: Encoding and Transport' document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called 'application/ipp'. The 'Internet Printing Protocol/1.0: Implementer's Guide' document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included. The 'Mapping between LPD and IPP Protocols' document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations. Table of Contents 1 Scope..............................................................3 2 Terminology........................................................3 3 Requirements.......................................................7 4 Scenarios..........................................................8 deBry, Lewis, Hastings Expires December 24, 1999 [Page 2] INTERNET DRAFT IPP/1.1: Notification Requirements June 23, 1999 1 Scope The scope of this requirements statement is for end users, print administrators and operators. 2 Terminology It is necessary to define a set of terms in order to be able to clearly express the requirements for notification services in an IPP System. 2.1 Job Submitting End User A human end user who submits a print job to an IPP Printer. This person may or may not be within the same security domain as the Printer. This person may or may not be geographically near the printer. 2.2 Administrator A human user who established policy for and configures the print system 2.3 Operator A human user who carries out the policy established by the Administrator and controls the day to day running of the print system. 2.4 Job Submitting Application An application (for example a batch application), acting on behalf of an end user, which submits a print job to an IPP Printer. The application may or may not be within the same security domain as the Printer. This application may or may not be geographically near the printer. 2.5 Security Domain For the purposes of this discussion, the set of network components which can communicate without going through a proxy or firewall. A security domain may be geographically very large, for example - anyplace within IBM.COM. 2.6 IPP Client The software component on the client system which implements the IPP protocol. 2.7 Job Recipient A human who is the ultimate consumer of the print job. In many cases this will be the same person as the Job Submitting End User, but this need not always be the case. For example, if I use IPP to print a document on a printer in a business partner's office, I am the Job Submitting End User, while the person I intend the document for in my business partner's office is the Job Recipient. Since one of the goals of IPP is to be able to print near the ultimate recipient of the printed output, we would normally expect the Job Recipient to be in the same deBry, Lewis, Hastings Expires December 24, 1999 [Page 3] INTERNET DRAFT IPP/1.1: Notification Requirements June 23, 1999 security domain as, and geographically near the Printer. However, this may not always be the case. For example, I submit a print job across the Internet to a Kinko's print shop. I am both the Submitting end User and the Job Recipient, but I am neither near nor in the same security domain as the Printer. 2.8 Job Recipient Proxy A person acting on behalf of the Job Recipient. In particular, the Job Recipient Proxy physically picks up the printed document from the Printer, if the Job Recipient cannot perform that function. The Proxy is by definition geographically near and in the same security domain as the printer. For example, I submit a print job from home to be printed on a printer at work. I'd like my secretary to pick up the print job and put it on my desk. In this case, I am acting as both Job Submitting End User and Job Recipient. My secretary is acting as a Job Recipient Proxy. 2.9 Notification Subscriber A client that requests the IPP Printer to send event reports to one or more Notification Recipients. A Notification Subscriber may be a Job Submitting End User or an End User, an Operator, or an Administrator that is not submitting a job. 2.10 Notification Source The entity that sends notification events 2.11 Notification Recipient Any of: Job Submitting End User, Job Submitting Application, Job Recipient, or Job Recipient Proxy or admin etc folks and their representatives or log file or accounting/audit application or other active or passive entities or President Clinton. Or Monica. 2.12 Notification Recipient Agent A program which receives events on behalf of the notification recipient. The agent may take some action on behalf of the recipient, forward the notification to the recipient via some alternative means (for example, page the recipient), or queue the notification for later retrieval by the recipient. 2.13 Event A event is some occurrence (either expected or unexpected) within the printing system. Any of the following constitute events that a Job Submitting End User can specify notifications be sent for: @ Any standard Printer MIB alert (i.e. device alerts) (critical and warning?) (state change notifications)? @ Job Received (transition from Unknown to Pending) @ Job Started (Transition from Pending to Processing) @ Page Complete (Page is stacked) deBry, Lewis, Hastings Expires December 24, 1999 [Page 4] INTERNET DRAFT IPP/1.1: Notification Requirements June 23, 1999 @ Collated Copy Complete (last sheet of collated copy is stacked) @ Job Complete (transition from Processing or Processing-stopped to Completed) @ Job aborted (transition from Pending, Pending-held, Processing, or Processing-stopped to Aborted) @ Job canceled (transition from Pending, Pending-held, Processing, or Processing-held to Canceled) @ Other job state changes like 'paused', purged? @ Device problems on which the job is destine for @ Job (interpreter) issues 2.14 Event report When an event occurs, an event report is generated that fully describes the event (what the event was, where it occurred, when it occurred, etc.). Event reports are delivered to all the notification recipients that are subscribed to that event, if any. The event report is delivered to the address of the notification recipient using the notification delivery method defined in the subscription. However, an Event Report is sent ONLY if there is a corresponding subscription. 2.15 Notification Subscription It should be possible for end users and operators to 'subscribe' for notifications of certain types of events, independent of Job Submission. An end user or operator may subscribe for @ All Job Traps @ All Traps (Job and Printer) @ None (Reserves a slot in some limited stable of 'notification hosts') ISSUE: Need to discuss granularity and categorization in the context of anticipated event frequency 2.16 Notification Attributes IPP Objects (for example, a print job) from which notification are being sent may have attributes associated with them. A user may want to have one or more of these associated attributes returned along with a particular notification. In general, these may include any attribute associated with the object emitting the notification. Examples include: number-of-intervening jobs job-k-octets job-k-octets processed job impressions job-impressions-interpreted job-impressions-completed impressionsCompletedCurrentCopy (job MIB) sheetCompletedCopyNumber (job MIB) sheetsCompletedDocumentNumber (job MIB) Copies-requested Copy-type Output-destination Job-state-reasons deBry, Lewis, Hastings Expires December 24, 1999 [Page 5] INTERNET DRAFT IPP/1.1: Notification Requirements June 23, 1999 Job ID Printer URI Subscription ID (for job independent subscription) 2.17 Notification Delivery Method (or Delivery Method for short) Event reports are delivered using a method, such as email, TCP/IP, etc. 2.18 Immediate Notification Notifications sent to the notification recipient or the notification recipient's agent in such a way that the notification arrives immediately , within the limits of common addressing, routing, network congestion and quality of service. 2.19 Queued Notification Notifications which are not necessarily sent immediately, but are queued for delivery by some intermediate network application, or for later retrieval. Email with store and forward is an example of queued notification. 2.20 Notification over Reliable Transport Notifications which are delivered by a reliable, sequenced delivery of packets or character stream, with acknowledgment and retry, such that delivery of the notification is guaranteed within some reasonable time limits. For example, if the notification recipient has logged off and gone home for the day, an immediate notification cannot be guaranteed to be delivered, even when sent over a reliable transport, because there is nothing there to catch it. Guaranteed delivery requires both queued notification and a reliable transport. If delivery of the notification requires process to process communications, each session is managed in a reliable manner, assuring fully ordered, end-to-end delivery. 2.21 Notification over Unreliable Transport Notifications are delivered via the fundamental transport address and routing framework, but no acknowledgment or retry is required. Process to process communications, if involved, are unconstrained. 2.22 Human Consumable Notification Notifications which are intended to be consumed by human end users only. They contain no machine readable encoding of the event. Email would be an example of a Human consumable notification. ISSUE: Do we need both human and machine or is machine sufficient? There is no intent to attempt to standardize human readable strings. Human readable is intended for certain protocols, like e-mail, though email can also convey machine readable MIME types as well using multipart/report. deBry, Lewis, Hastings Expires December 24, 1999 [Page 6] INTERNET DRAFT IPP/1.1: Notification Requirements June 23, 1999 ISSUE: Is e-mail the only, or most likely, means of conveying the notification through the firewall (which would drive a requirement for mixed text, binary content). 2.23 Machine Consumable Notification Notifications which are intended for consumption by a program only, such as an IPP Client. Machine Consumable notifications may not contain human readable information. Do we need both human and machine? Machine readable is intended for application to application only. The Notification Recipient could process the machine readable report into human readable format. 2.24 Mixed Notification A mixed notification may contain both human readable and human readable information. ISSUE: Do we need mixed? Mail Services, DNS, Instant Messaging, Distributions lists etc.? 3 Requirements The following requirements are intended to be met by the IPP Notification specification. 1.The specification must indicate which of these requirements are MANDATORY and which are OPTIONAL for a conforming implementation. 2.It must be possible to support the IPP Notification interface using third party notification services that exist today or that may be standardized in the future. 3.A Job Submitting End User must be able to specify zero or more notification recipients when submitting a print job. But don't expect a submitter to be able to circumvent out of band subscriptions. 4.When specifying a notification recipient, a Notification Subscriber must be able to specify one or more notification events for that notification recipient. 5.When specifying a notification recipient, the Notification Subscriber must be able to specify either immediate or queued notification for that notification recipient. This may be explicit, or implied by the method of delivery chosen by the Job Submitting End User. 6.When specifying a notification event, a Notification Subscriber must be able to specify that zero or more notification attributes (or attribute categories) be sent along with the notification, when that event occurs. 7.Common delivery methods, e.g. email, must be supported. deBry, Lewis, Hastings Expires December 24, 1999 [Page 7] INTERNET DRAFT IPP/1.1: Notification Requirements June 23, 1999 8.There is no requirement for the IPP Printer receiving the print request to validate the identity of an event recipient, nor the ability of the system to deliver an event to that recipient as requested (for example, if the event recipient is not at work today). 9.However, an IPP Printer must validate its ability to deliver an event using the specified delivery scheme. If it does not support the specified scheme, or the specified scheme is invalid for some reason, then it should respond to the print request with an error condition. 10. There must be a class of IPP event notification schemes or methods which can flow through corporate firewalls. However, an IPP printer need not test to guarantee delivery of the notification through a firewall before accepting a print job. 11. A mechanism must be provided for delivering a notification to the submitting client when the delivery of an event notification to a specified Notification Recipient fails. (Optional? Or not necessary?) Fall back means of subscribers determining if notifications have failed. I.e. polling? 12. There must be a mechanism for localizing human consumable notifications by the Notification Source. 13. There must be a way to specify whether or not event delivery requires acknowledgement back to the Event Source. 14. There must be a mechanism to indicate the quality of service for delivery of event reports. The policy must include stopping the Printer and allowing the Printer to continue, when delivery of the event report is not acknowledged. ISSUE: Should that policy be specified by the Notification Subscriber (and authorized by the Printer) or by the administrator in configuring the Printer? 15. There must be a mechanism so that job independent subscriptions do not become stale and do not require human intervention to remove stale subscriptions. However, stale must not be the inability to deliver a notification report, since temporary event delivery problems must be tolerated. 4 Scenarios 1.I am sitting in my office and submit a print job to the printer down the hall. I am in the same security domain as the printer and of course, geographically near. I want to know immediately when my print job will be completed (or if there is a problem) because the document I am working on is urgent. I submit the print job with the following attributes: @ Notification Recipient - me @ Notification Events - all @ Notification Attributes - job-state-reason @ Notification Type - immediate deBry, Lewis, Hastings Expires December 24, 1999 [Page 8] INTERNET DRAFT IPP/1.1: Notification Requirements June 23, 1999 2.I am working from home and submit a print job to the same printer as in the previous example. However, since I am not at work, I cannot physically get the print file or do anything with it. It can wait until I get to work this afternoon. However, I'd like my secretary to pick up the output and put it on my desk so it doesn't get lost or miss-filed. I'd also like a queued notification sent to my email so that when I get to work I can tell if there was a problem with the print job. I submit a print job with the following attributes: @ Notification Recipient - my secretary @ Notification Events - print complete @ Notification Type - immediate @ Notification Recipient - me @ Notification Events - print complete @ Notification Attributes - impressions completed @ Notification Type - queued 3.I am sitting in my office and submit a print job to a client at an engineering firm we work with on a daily basis. The engineering form is in Belgium. I would like my client to know when the print job is complete, so that she can pick it up from the printer in her building. It is important that she review it right away and get her comments back to me. I submit the print job with the following attributes: @ Notification Recipient - client at engineering firm @ Notification Events - print complete @ Notification Type - immediate @ Notification Language - French 4.I am in a hotel room and send a print job to a Kinko's store in the town I am working in, in order to get a printed report for the meeting I am attending in the morning. Since I'm going out to dinner after I get this job submitted, an immediate notification won't do me much good. However, I'd like to check in the morning before I drive to the Kinko's store to see if the file has been printed. An email notification is sufficient for this purpose. I submit the print job with the following attributes: @ Notification Recipient - me @ Notification Events - print complete @ Notification Type - email 5.I am printing a large, complex print file. I want to have some immediate feedback on the progress of the print job as it prints. I submit the print job with the following attributes: @ Notification Recipient - me @ Notification Type - immediate @ Notification Events - all state transitions @ Notification Attributes - impression completed deBry, Lewis, Hastings Expires December 24, 1999 [Page 9] INTERNET DRAFT IPP/1.1: Notification Requirements June 23, 1999 6.I am an operator and my duties is to keep the printer running. I subscribe independently from a job submission so that my subscription outlasts any particular job. I subscribe with the following attributes: @ Notification Recipient - me @ Notification Type - immediate @ Notification Events - all Printer state transitions @ Notification Attributes - Printer state, printer state reasons, device powering up, device powering down. 7.I am an accounting or audit application. I subscribe independently from a job submission so that my subscription outlasts any particular job. My subscription may persists across power cycles. I subscribe with the following attributes: @ Notification Recipient - me @ Notification Type - immediate @ Notification Events - job completion @ Notification Attributes - impression completed, sheets completed, time submitted, time started, time completed, job owner, job size in octets, etc. deBry, Lewis, Hastings Expires December 24, 1999 [Page 10]