Network Working Group T. Hastings, Ed. Request for Comments: 3997 Xerox Corporation Category: Informational R. K. deBry Utah Valley State College H. Lewis IBM Corporation March 2005 Internet Printing Protocol (IPP): Requirements for IPP Notifications Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThis document is one of a set of documents that together describe all aspects of the 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 an optional part of an IPP Service. 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations for IPP Notifications Requirements. . 12 6. Internationalization Considerations . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References. . . . . . . . . . . . . . . . . . 14 8.2. Informative References. . . . . . . . . . . . . . . . . 14 9. Appendix A: Description of the Base IPP Documents . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
section 10 for a description of the base IPP documents. The scope of this requirements document covers functionality used by the following kinds of IPP Users: End Users, Print Administrators, and Operators. See [RFC3995] for the extensions to the Internet Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911], [RFC2910], and future versions.
- Notification Recipient: Me - Notification Events: All - Notification Attributes: Job-state-reason - Notification Type: Immediate 2. Working from home, I submit a print job to the same printer as in the previous example. However, 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 that it doesn't get lost or misfiled. I'd also like a store-and-forward notification sent to my email so that when I get to work I can tell whether 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: Store and forward 3. Sitting in my office, I submit a print job to a client at an engineering firm my company works with on a daily basis. The engineering firm 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 send 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. From a hotel room, I 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. As 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 whether 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: Store and forward 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 6. I am an operator and one of 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 a usage statistics gathering application. I subscribe independently from a job submission so that my subscription outlasts any particular job. My subscription may persist 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. 8. I am a client application program that displays a list of jobs currently queued for printing on a printer. I display the "job-name", "job-state", "job-state-reasons", "page-count", and "intervening-jobs", either for the user's jobs or for all jobs. The window displaying the job list remains open for an independent amount of time, and it is desired that it represent the current state of the queue. It is desired that the application only perform a slow poll in order to recover from any missed notifications. So the event delivery mechanism provides the means to update the screen on all needed changes, including querying for some attributes that may not be delivered in the Notification.
9. I am a client application program that displays a list of printers. For each Printer, I display the current state and configuration. The window displaying the printer list remains open for an independent amount of time, and it is desired that it represent the current state of each printer. It is desired that the application only need to perform a slow poll in order to recover from any missed notifications. So the event delivery mechanism provides the means to update the screen on all needed changes, including querying for some attributes that may not be delivered in the Notification. 10. I am an IPP Server that controls one or more devices and that implements an IPP Printer object to represent each device. I want to support IPP Notification for each of the IPP Printer objects that I implement. Many of these devices do not support notification (or IPP). So I need to support the IPP Notification semantics specified for each IPP Printer object myself on behalf of each of the devices that each of the IPP Printer objects represents. When I accept an IPP job creation requests, I convert it to what the device will accept. In some cases, I must poll the devices in order to be informed of their job and device state and state changes to be able to send IPP Notifications to subscribed Notification Recipients. 11. I am an IPP Server that controls one or more devices and that implements an IPP Printer object to represent each device. I want to support IPP Notification for each of the IPP Printer objects that I implement. These devices all support IPP, including IPP Notification. I would like the design choice for supporting IPP Notification for these objects either (1) by forwarding the notification to the IPP Printers that I, alone, control and have them send the notifications to the intended Notification Recipients without my involvement, or (2) by replacing the notification submitted with the Job to indicate me as the Notification Recipient; in turn I will forward Notifications to the Notification Recipients requested by my clients. Most of the rest of the contents of the IPP Job I send to the IPP Printers I control will be the same as those that I receive from my IPP clients. 12. I am an IPP Server that controls one or more devices and that implements an IPP Printer object to represent each device. I want to support IPP Notification for each of the IPP Printer objects that I implement. These devices all support IPP, including IPP Notification. Because these IPP Printers MAY also be controlled by other servers (using IPP or other protocols), I only want job events for the jobs that I send, but I do want Printer events all the time, so that I can show proper Printer
state to my clients. So I subscribe to these IPP Printers for Printer events with a long-standing subscription, with myself as the Notification Recipient. When I get a Job Creation request, I decide to which IPP Printer to send the job. When I do so, I also add a job subscription for Job events, with me as the Notification Recipient to the job's job subscriptions supplied by my clients (this usage is called "piggybacking"). These IPP Printers automatically remove their job subscriptions when the job finishes, as for all job subscriptions, so that I no longer get Job events when my jobs are completed. RFC2911], section 12.1, for the definition of these important conformance terms. 2. It must be designed so that an IPP Printer can transparently support the IPP Notification semantics by using third-party notification services that exist today or that may be standardized in the future. 3. It must define a means for a Job-Submitting End User to specify zero or more Notification Recipients when submitting a print job. A Submitter will not be able to prevent out-of-band subscriptions from authorized persons, such as Operators. 4. It must define a means, when specifying a Notification Recipient, for a Notification Subscriber to specify one or more notification events for that Notification Recipient, subject to administrative and security policy restrictions. Any of the following constitute Job or Printer Events for which a Job Submitting End User can specify that notifications be sent: - Any standard Printer MIB alert - Job Received (transition from Unknown to Pending) - Job Started (transition from Pending to Processing) - Page Complete (page is stacked) - 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, such as paused, purged - Device problems for which the job is destined - Job (interpreter) issues 5. It must define how an End User or Operator subscribes for - any set of Job Events for a specific job, or - any set of Printer Events while a specific job is not complete. 6. It must define how an End User or Operator subscribes for the following without having to submit a Job: - Any set of Printer Events for a defined period. - Any set of Job Events for all jobs, with no control over which jobs. 7. It must define how the Notification Subscriber is able to specify either immediate or store-and-forward notification independently for each Notification Recipient. The means may be explicit, or implied by the method of delivery chosen by the Job Submitting End User. 8. It must define common delivery methods: e.g., email. 9. It must define how an IPP Printer validates its ability to deliver an Event by using the specified delivery scheme. If it does not support the specified scheme, or if the specified scheme is invalid for some reason, then the IPP Printer accepts and performs the request anyway and indicates the unsupported attribute values. There is no requirement for the IPP Printer receiving the print request to validate the identity of a Notification Recipient, or the ability of the system to deliver an event to that recipient as requested (for example, if the Notification Recipient is not at work today). 10. It must define a class of IPP event notification delivery methods that 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. It may define a means to deliver a notification to the submitting client when the delivery of an event notification to a specified Notification Recipient fails. A fallback means of subscribers to determine whether notifications have failed (i.e., polling) may be provided. 12. It must define a mechanism for localizing Human-Consumable Notifications by the Notification Source. 13. It may define a way to specify whether event delivery requires acknowledgement back to the Notification Source. 14. There must be a mechanism defined so that job-independent subscriptions do not become stale and do not require human intervention to be removed. However, a subscription must not be deemed stale only if it is unable to deliver an Event Notification, as temporary Notification delivery problems must be tolerated. 15. A mechanism must be defined so that an Event Subscriber is able to add an Event Subscription to a Job after the Job has been submitted. 16. A mechanism must be defined so that a client is able to cancel an Event Subscription on a job or printer after the job has been submitted. 17. A mechanism must be defined so that a client can obtain the set of current Subscriptions.
by the client notification submission. Operations that require authentication can use the HTTP authentication. Operations that require privacy can use the HTTP/TLS privacy. The notification access control model should be similar to the IPP access control model. Creating a notification subscription is associated with a user. Only the creator or an operator can cancel the subscription. The system may limit the listing of items to items owned by the user. Some subscriptions (e.g., those that have a lifetime longer than a job) can be done only by privileged users (operators and/or administrators), if that is the authorization policy. The standard security concerns (delivery to the right user, privacy of content, tamper-proof content) apply to the notification delivery. IPP should use the security mechanism of the delivery method used. Some delivery mechanisms are more secure than others. Therefore, sensitive notifications should use the delivery method that has the strongest security. RFC2566].
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000. [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", RFC 3995, March 2005. [RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999. [RFC2567] Wright, F., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999. [RFC2568] Zilles, S., "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999. [RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999. [RFC2639] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, "Internet Printing Protocol/1.1: Implementor's Guide", RFC 3196, November 2001.
RFC2567] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568] Internet Printing Protocol/1.1: Model and Semantics [RFC2911] Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] Internet Printing Protocol/1.1: Implementer's Guide [RFC3196] Mapping between LPD and IPP Protocols [RFC2569] "Design Goals for an Internet Printing Protocol" takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help 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 [RFC2566], [RFC2565]. A few OPTIONAL operator operations have been added to IPP/1.1 [RFC2911], [RFC2910]. "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" describes IPP from a high-level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF IPP working group's major decisions. "Internet Printing Protocol/1.1: Model and Semantics" describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses security, internationalization, and directory issues. "Internet Printing Protocol/1.1: Encoding and Transport" is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It also defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines the "ipp" scheme for identifying IPP printers and jobs. "Internet Printing Protocol/1.1: Implementer's Guide" gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 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.
"Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon ) implementations.
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.